1. State the decision in one sentence
Write the decision, its deadline, and the decision owner. Avoid “review our store” as the entire brief. A useful opening is: “The board must decide by 30 October whether to keep Adobe Commerce, modernize its frontend, or replatform before the next license and agency commitment.”
Deadline: [When is the decision needed?]
Owner: [Who signs the decision record?]
Implementation status: [Not funded, funded, contracted, or already underway?]
2. Define the business constraints
List conditions that the adviser cannot quietly design away. Include business model, customer types, countries, languages, catalogs, contract pricing, buying workflows, peak trading, accessibility, privacy, regulatory duties, internal skills, and the maximum acceptable disruption.
- Revenue and operational exposure. What fails if commerce is unavailable or sends incorrect orders?
- Non-negotiable workflows. Name quoting, approvals, account structures, pricing, pickup, subscriptions, returns, or marketplace rules.
- Systems of record. Name the ERP, PIM, CRM, OMS, payments, tax, search, identity, analytics, and fulfillment owners.
- People and governance. State who owns product, architecture, security, releases, content, data, and acceptance.
- Commercial boundaries. Give the planning horizon, budget range, license event, procurement rules, and contract constraints.
3. Give the adviser a controlled evidence pack
Start read-only. Provide current contracts, proposals, requirements, architecture diagrams, system inventory, extension list, release history, incidents, support tickets, performance baselines, analytics, hosting and cloud details, license costs, and roadmap. Remove secrets and personal data unless the approved scope needs them.
Record what is missing. An adviser should label an assumption instead of silently treating missing evidence as fact.
4. Name the options that must be tested
Do not let one provider compare its favorite option with an intentionally weak alternative. Use the same requirement set for staying on the current platform, modernizing it, changing the frontend, moving to SaaS, choosing a composable architecture, or replacing only a specific capability. The platform decision matrix supplies a common structure.
5. Require a buyer-owned output
| Output | What it must answer |
|---|---|
| Current-state findings | What is known, inferred, missing, unsafe, or blocking a decision? |
| Requirements baseline | Which business and technical constraints were used for every option? |
| Option record | Why did each path win or lose, and what fact would reverse that result? |
| Architecture and data flows | Which system owns product, price, stock, order, customer, payment, and content? |
| Total-cost assumptions | What period, licenses, people, services, rework, risk, and migration cost are included? |
| Decision and roadmap | What is recommended, what happens first, and what acceptance gate controls the next spend? |
6. Ask for the conflict declaration
Require the adviser to name platform partnerships, referral fees, reseller arrangements, implementation services, subcontractors, and any financial benefit if its recommendation becomes a build. Ask whether it will give the same output if another supplier implements it.
7. Set the acceptance gate
Accept the opinion only when assumptions are visible, rejected options are explained, diagrams and estimates can be reviewed, conflicts are disclosed, and another qualified supplier could use the output without restarting discovery. If the report only says “choose Magento because it is flexible,” the engagement has not produced a decision record.
Copyable request
Use the brief with the ranking
Return to the seven-adviser comparison, check the OPINION-7 method, and use the due-diligence checklist before granting access. The editorial policy explains how provider claims are bounded.