Start with the decision
“We need a new platform” is a proposal, not a problem statement. A more useful brief describes the decision: can the current system support a second location, or does its inventory model need to change? This gives an adviser something to investigate and makes competing proposals easier to compare. Write one sentence describing who cannot complete which task and why that matters to the operation.
Describe the current workflow
List the people, systems and handoffs involved. Include the awkward parts: the spreadsheet used to reconcile orders, the export that only one employee understands, or the manual approval that prevents an incorrect invoice. These workarounds often encode business rules missing from the formal documentation. Removing them without understanding their purpose can create a new problem.
Separate constraints from preferences
A contractual integration requirement is a constraint. A preference for a familiar framework is a preference. Record both, but explain their weight. Useful constraints include a required data location, a fixed external API, the team available to operate the software and a deadline tied to a real event. Avoid treating an arbitrary feature list as immutable before feasibility has been examined.
Ask for alternatives and evidence
Request at least a realistic keep-and-improve option alongside replacement when both are plausible. Each option should explain what it changes, what it leaves unresolved, its dependencies and its maintenance implications. Ask which assumption is most likely to change the recommendation. A short investigation of that assumption can be more valuable than a detailed estimate based on an untested premise.
Worked example: a second stock location
Imagine a retailer whose store and warehouse share a spreadsheet. The requirement is not initially “build an ERP.” It is “record transfers without losing the source of truth for available stock.” Investigation might reveal that the existing commerce platform can support the workflow through an integration, or that its data model cannot represent the required states. Either conclusion needs evidence from the actual transaction path.
Finish with acceptance and ownership
Define what would make the decision usable: a diagram, a tested integration assumption, an estimate range with dependencies, or a migration sequence. Name the person who accepts the recommendation and the person who will operate the result. Keep unresolved questions visible. A decision brief succeeds when it reduces uncertainty enough to choose the next step; it does not need to pretend that every future detail is known.