Designing embedded commercial analytics around management decisions
A fictional, composite case: not “better dashboards”, but an analytical product layer between what the facts mean and where the work is done.
Independently created. Contains no employer or client implementation detail, internal names or figures.
The case in brief
Current reality
Commercial information is spread across accounts, pipeline, orders, invoices, prices, targets, stock and usage—and managers move between CRM pages, reports, exports, spreadsheets and ERP views to answer one question.
What must become true
One embedded decision layer that brings the relevant analytical domains together, preserves governed metric definitions, uses consistent filters, moves from overview to detail and back to the operational record, supports export where it is genuinely useful, respects access rights and measures its own usage—without becoming another system of analytical truth.
Design question
Which management questions should the embedded analytical layer answer—and which facts, calculations and responsibilities should remain outside it?
01The reality · current state
What the data does today.
A B2B manufacturer runs its commercial teams in the CRM, its transactions in several ERPs and its governed performance model in a data platform. Managers preparing a review open a CRM report for pipeline, an export for orders, a spreadsheet for targets and an ERP screen for stock—selecting the same customer and period each time. Native dashboards exist per object, each with its own filters, and nobody knows which of them are actually used.
- Reporting is organised by system object, not by the question a manager is asking
- Every dashboard has its own filters, so the same customer and period are selected again and again
- Drill-down paths differ by report and often end in an export
- Analytical views are visually and logically disconnected from the record where action happens
- Metrics are re-defined inside individual reports
- Nobody knows which views are used, ignored or replaced by spreadsheets
02The semantic problem
Which meanings are mixed today.
The layer had to separate three things that native reporting mixes together: what the facts mean, how a decision-maker explores them and where the action is carried out.
- Data architectureWhat the facts mean—owned by the governed model, not re-defined in a view.
- Analytical experienceHow a manager moves from a question to evidence—owned by the decision layer.
- Operational systemWhere the follow-up is recorded and done—owned by the CRM.
- A dashboard vs a decisionA dashboard organises charts; a decision layer organises questions, evidence and action.
03Key dimension · Questions, evidence & action
A decision surface, not a set of dashboards
Each area starts from the question a manager asks, names the evidence it needs, and ends where the action is taken. Domains are grouped by decision—never shown as one screen per object.
| Decision area | Management question | Evidence | Analytical view | Drill-down | Operational action |
|---|---|---|---|---|---|
| Customer healthDomains: Accounts · Contacts | Where is the customer base concentrated, and which relationships need attention? | Account performance, contact coverage, activity recency | Portfolio overview by segment | Account → contacts and recent activity | Open the account plan |
| PipelineDomains: Leads · Opportunities | Where is future business coming from—and where is it stuck? | Pipeline by motion and stage, ageing, conversion | Pipeline flow and ageing | Stage → opportunities past their benchmark | Update, requalify or close the opportunity |
| PerformanceDomains: Budget / Targets | How is actual performance evolving against the governed target? | Performance to target, year to date, by version | Actual vs target by period | Region → account → product line | Review or open a recovery plan |
| TransactionsDomains: Orders · Invoices · Prices | What has been ordered, what has actually been invoiced—and what remains open? | Open orders, invoiced revenue, price realisation | Order-to-invoice picture per account | Account → open or late orders | Follow up the order with the customer |
| AvailabilityDomains: Stock | Does product availability change the commercial decision? | Availability for the customer’s location | Availability against open demand | Product line → item and location | Adjust the offer or the promised date |
| AdoptionDomains: Usage | Are the analytical and CRM capabilities actually being used to run the business? | Module use, filters, exports, return visits | Usage by team and module | Module → view → action taken | Change, retire or explain a view |
- 01OverviewThe state of the business for the chosen filters
- 02DomainOne management question and its evidence
- 03BreakdownWhere the difference comes from
- 04DetailThe accounts, orders or opportunities behind it
- 05Record & next actionThe CRM record, where the follow-up is done
A dashboard organises charts. A decision layer organises questions, evidence and action—and never ends in a dead end.
04Grain & contracts
What one row or message means.
Meaning, grain, key, freshness and owner—written down before anything is mapped.
Module metric set
The governed measures one module reads, with their definition versions.
- Grain
- Module × metric × definition version
- Key
Module + metric + version- Freshness
- As published by the model
- Owner
- Sales operations
Filter dimension
A dimension that means the same thing in every module it filters.
- Grain
- Dimension value × validity period
- Key
Dimension + value- Freshness
- Daily
- Owner
- Data platform owner
Usage event
One interaction with a module, filter, drill-down or export.
- Grain
- User × module × action × day
- Key
Pseudonymous user + module + action + day- Freshness
- Daily
- Owner
- Analytics product owner
06Decision experience
Filters, access and usage—designed before the charts.
Information architecture shapes decisions. A global filter only works if the dimension means the same thing in every domain; access must follow the commercial model; and a product should measure its own usefulness.
One filter layer, one meaning
A filter is kept across modules only where the dimension is conformed, its relationship to each fact is defined and “not applicable” is shown rather than silently ignored.
| Dimension | Means the same everywhere as | How facts relate to it | Where it does not apply |
|---|---|---|---|
| Period | The reporting period of the governed model | Order date, posting date or target month—declared per fact | Never ignored; the module states its time basis |
| Customer | The governed commercial account | Through the account’s identity links | Leads before conversion are shown apart |
| Owner | The accountable owner of the account | Through the account, not the transaction | Shown as “no owner” rather than dropped |
| Subsidiary | The selling company | Through the transaction’s company | Group-level views say so explicitly |
| Channel & business unit | The governed commercial classification | Through the account or the product line | Marked “not applicable” in usage views |
Two levels of access
| Level | Can | Inherits or restricts |
|---|---|---|
| Standard analytical access | Use modules, filters, drill-down and permitted exports | Inherits commercial visibility from the CRM; sensitive terms stay restricted |
| Admin & governance access | Configure modules and views; see usage telemetry | Cannot change metric definitions—those belong to the governed model |
Usage telemetry
An analytical product should measure its own usefulness.
| Signal | Question it answers | What it changes |
|---|---|---|
| Modules used | Which questions matter to which teams? | Roadmap and retirement of modules |
| Filters used | How do managers actually slice the business? | Default filters and dimension quality |
| Exports | Where does analysis leave the product? | The missing view or drill-down |
| Return visits | Is the layer part of the routine? | Management cadence and training |
| Ignored views | What does nobody need? | Remove or explain the view |
07Candidate architectures
Credible options, judged against these premises.
Native CRM dashboards only
Simple, object-level monitoring
Cost: Fragmented filters, re-defined metrics, analysis that ends in exportsAn embedded analytical layer on the governed model
Management decisions that must stay close to commercial work
Cost: An analytical product with an owner, a roadmap and telemetryExternal BI for everything
Broad exploration, complex modelling, enterprise reporting
Cost: Far from the workflow; context is lost between analysis and actionCriterion by criterion
| Criterion | Native CRM dashboards | Embedded analytical layer | External BI |
|---|---|---|---|
| Proximity to the workflow | High, per object | High, across domains | Low—a separate tool |
| Cross-domain analysis | Limited | By design, from the governed model | Strong |
| Navigation & drill-down | Report by report | Question → evidence → record | Flexible, generic |
| UX control | Low | High | Medium |
| Governance of definitions | Easily re-defined per report | Reads governed metrics | Reads governed metrics, if connected to the model |
| Analytical complexity | Simple | Moderate, focused | High |
| Maintenance | Low per dashboard, high in total | A product with an owner | A separate platform and team |
| Best audience | Individual users of one object | Commercial managers and teams | Analysts and enterprise reporting |
Design decision
Build an embedded analytical layer for operational and commercial management decisions, organised by management question and backed by the governed analytical model; keep metric computation in the data platform and action in the CRM; and leave broader exploration and enterprise reporting to external BI where it applies.
08Resulting architecture
Where the data comes from, where it goes—and how.
Every hand-over is named with its mode. The mode follows the business tolerance for waiting, inconsistency and loss.
CRMEmbedded analytics layerData platformERP
- 01 · CRMCRM recordsFeeds by Batch
Accounts, contacts, leads, opportunities and activities.
- 02 · ERPERP factsFeeds by Batch
Orders, invoices, prices and stock.
- 03 · PlanningTargetsFeeds by Batch
Published target versions.
- 04 · Data platformGoverned modelHands over by API
Conformed facts and metric definitions—see the performance data model.
- 05 · Embedded analyticsDecision layerHands over by Event
Modules by question, one filter layer, drill-down to detail.
- 06 · CRMOperational record
The account, opportunity or task where the next action is taken.
09Failure & quality
Design the failure path before the happy path.
- A metric is re-defined inside a moduleDefinition version check at publicationThe module reads the governed version or is not publishedSales operations
- A filter cannot apply to a domainDimension relationship not defined for that factShow “not applicable” instead of an unfiltered numberAnalytics product owner
- The governed model is lateAs-of date past its promiseViews show “stale” with the last as-of dateData platform team
- Exports dominate a moduleUsage telemetryFind the missing view or drill-down; do not just add export columnsAnalytics product owner
- A view shows data a user may not seeAccess review against CRM visibilityVisibility is inherited, never widened; fix at the sourceCRM platform owner
10Governance
Who keeps the meaning stable over time.
| What | Owner | Cadence | Evidence |
|---|---|---|---|
| Module roadmap | Analytics product owner | Quarterly | Usage telemetry and review feedback |
| Metric definitions used by modules | Sales operations | Per definition version | Modules reading each version |
| Filter dimensions | Data platform owner | With every new domain | Dimensions marked “not applicable” |
| Access levels | CRM platform owner | Quarterly review | Configuration and telemetry access granted |
11The second layer
Questions that change the design.
Questions
- Which decision does each module support—and who takes it?
- Which question does a manager ask first in a review?
- Where should the analysis end: in an export, or in a record?
Semantics
- Does each filter mean the same thing in every domain?
- Which metrics are computed in the model, and which only displayed?
- What does the layer show when a filter does not apply?
Boundaries
- What belongs in the embedded layer, and what in external BI?
- Who may configure a view, and who may see usage?
- How will we know the layer is actually used?
12Decisions & outputs
What the work produces.
- 01Decision surface map
- 02Module catalogue by management question
- 03Global filter semantics
- 04Drill-down paths to operational records
- 05Access model
- 06Usage telemetry model
- 07Embedded vs external BI boundary