“We need an automatically updated dashboard” is a useful starting point. It tells you the team wants access to numbers without rebuilding reports manually. It does not yet define which numbers belong together.
The first delivery should answer a manageable set of business questions. Wider architecture supports that outcome; it should be proportionate to the work required.
The examples below are hypothetical. They are not a description of a completed client engagement or a public fixed-price package.
Choose the first questions
Begin with decisions, not a list of integrations:
- How much did we spend, and where?
- How many orders or new paying customers did we acquire?
- What is the average order value under our chosen revenue definition?
- How do ecommerce sales and subscriptions perform separately?
- Which recurring report can stop being assembled by hand?
Pick a few questions whose inputs are available. A tool appearing in the company's stack does not mean its data is necessary for the first report.
Define the denominator before displaying CAC
Customer acquisition cost needs an agreed acquisition count and a compatible spend scope.
If a business sells products and subscriptions, “new customers” could mean new purchasers, new paying subscribers, or people who became either. Those definitions produce different answers.
A synthetic first-version specification might look like this:
| Metric | Initial definition | Limitation |
|---|---|---|
| New-purchaser CAC | Included acquisition spend / first-time purchasers in the reporting period | Period-based measure, not proof of causal campaign attribution |
| AOV | Agreed included order revenue / included orders | Refund, tax, shipping, and discount treatment must be stated |
| Subscription reporting | New paid subscriptions and renewals shown separately | Identity matching to ecommerce buyers is outside this first version |
| Customer value | Observed revenue in a stated period or cohort | Historical observed value is not a prediction of lifetime value |
A ratio called CAC should not silently use orders in the denominator. Likewise, customer value over a short history should not be presented as a reliable lifetime estimate.
Paid versus organic needs its own definition
Paid versus organic can describe traffic, new customers, orders, or revenue. State which one the report uses.
Then identify the acquisition source: an order field, first-party tracking, a defined attribution system, or an existing report. Advertising platforms' attributed conversions are not automatically an exclusive partition of actual sales.
If the necessary attribution input is unavailable, show the limitation. Do not infer a reliable paid/organic split by subtracting platform conversions from orders.
The reporting-grain article explains another common source of disagreement.
Pick the smallest suitable data path
A first version may use an existing BI tool and managed connector, a reporting Sheet, a small modeled dataset, or custom extraction for one unsupported source.
Check the connector's required fields, historical coverage, refresh behavior, and source definitions before agreeing scope. A successful connection does not establish that the needed subscription, refund, or acquisition fields are present.
A warehouse becomes useful when shared definitions, historical reconciliation, transformation logic, or additional consumers justify it. A custom frontend is a separate decision.
Agree what the client receives
Write the first delivery in concrete terms:
- Included questions and metric definitions.
- Included sources and access requirements.
- Available historical range and refresh behavior.
- Dashboard/report/API output and who uses it.
- Validation against source reports.
- Known limitations and excluded follow-on work.
- Operating notes and handoff.
Claude access can be another interface when an authenticated integration exposes the agreed data and capabilities. It does not remove source integration, metric definitions, or access boundaries. A first dashboard also does not imply a complete customer-identity or attribution platform.
Make expansion explicit
A later phase may connect customer identities, reconcile refunds, add subscription cohorts, improve attribution, or recover historical data. Those are useful additions when the business needs them, rather than hidden promises inside a first report.
My commerce/backend case describes prior integration and reporting work. The reporting service explains focused and deeper engagement options.