Writing analytical signals back into operational CRM
A fictional architecture case: copy or query, writeback grain, staleness, recalculation, removals and who owns a failed writeback.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
A small set of governed, read-only signals per account—value, segment, as-of date, version and a link to the definition—written idempotently and reconciled daily against what was published.
Performance is computed outside the CRM, but sellers act inside it—so the numbers they see are stale, editable or unexplained.
Should the CRM hold a copy of the metric—and who owns it once it lands?
Write back governed signals at account grain rather than querying live or copying the full KPI detail.
Account performance and pipeline coverage are computed daily in the data platform. Sellers work in the CRM and should act there: open a recovery plan when an account falls behind, generate pipeline when coverage is low. The first attempt copied every KPI detail into CRM fields that sellers could overwrite, with no date and no link to the definition.
02The reality · current state
What the data does today.
- Sellers overwrite derived values they disagree with
- Nobody can tell whether a value is from today or last month
- A recalculation leaves old values on accounts that are no longer eligible
- A partially failed writeback goes unnoticed for weeks
- Automation creates a new recovery task on every nightly run
03Target flow
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.
- 01 · ERP · CRM · PlanningSourcesFeeds by Batch
Orders, invoices, pipeline and targets.
- 02 · Data platformData platformHands over by Batch
Conformed history at account × month.
- 03 · Data platformDerived KPIHands over by Batch
Performance to target, coverage—one definition each.
- 04 · Data platformSegmentHands over by API
On Track, Underperforming, At Risk, No Sale.
- 05 · Integration → CRMCRM writebackHands over by Event
Upsert by account + metric version; read-only fields.
- 06 · CRM automationAction
One recovery task per entry into At Risk.
04Contracts
What one row or message means.
Meaning, grain, key, freshness and owner—written down before anything is mapped.
Account performance signal
The published value of a metric for one account and period.
- Grain
- Account × metric × period
- Key
Analytical customer key + metric + period + version- Freshness
- Daily; stale after 48 hours
- Owner
- Sales operations (definition) · data team (computation)
Activation trigger
An account entered a segment that requires an action.
- Grain
- Account × segment entry
- Key
Account + segment + entry period- Freshness
- Within an hour of writeback
- Owner
- Commercial operations
05Key dimension · Writeback, freshness & activation
A writeback contract, not a copy
What lands in the CRM is small, read-only and self-describing. Its lifecycle is explicit, so a stale or superseded value is visibly stale or superseded.
- ComputedDerived in the data platform
- PublishedReleased as the current version
- WrittenUpserted in the CRM by key
- AcknowledgedRead back and matched
- SupersededReplaced by a newer version
- ExpiredPast its freshness promise
| Field | Meaning | Rule |
|---|---|---|
| Value | The published metric for this account and period | Read-only in the CRM; never recomputed there |
| Segment | On Track, Underperforming, At Risk or No Sale | Exactly one per eligible account |
| As of | Period and computation time | Shown beside the value; stale after 48 hours |
| Version | Metric and rule version that produced it | A recalculation publishes a new version; the CRM keeps the latest |
| Eligibility | Whether the account is in the population | Leaving it writes “not eligible”—never a silent blank |
| Definition link | Lineage for the seller | Opens the definition, owner and sources |
Copy the signal, query the detail: sellers act on the value in the CRM and follow the link when they need the transactions behind it.
07Failure & recovery
Design the failure path before the happy path.
- Writeback partially succeedsPublished vs written, by keyReplay the missing keys; upsert makes it safeIntegration operations
- Values are older than their promiseAs-of date past 48 hoursShow “stale” in the CRM and suppress new tasksData platform team
- The metric is recalculatedNew version publishedOverwrite by version; tasks already created are not duplicatedSales operations
- An account leaves the populationIn CRM, not in the new publicationWrite “not eligible” and close open triggersData platform team
08Candidate architectures
Credible options, judged against these premises.
Query live from the CRM
Users who only look at the number
Cost: Cannot drive list views, assignment or automation; depends on the analytics service being upCopy every KPI detail into the CRM
Small, stable metric sets
Cost: Volume, staleness and values nobody can explainWrite back governed signals at account grain
Metrics that should change a seller’s action
Cost: Needs a writeback contract, freshness rules and reconciliation09The second layer
Questions that change the design.
Copy or query
- Should the metric be copied or queried live?
- What is the writeback grain?
- What does the seller need beside the number?
Freshness & change
- How is stale data identified?
- What happens when the source metric is recalculated?
- How is zero—or “no longer eligible”—handled?
Ownership
- Who owns a failed writeback?
- Can the CRM modify the analytical value?
- How is lineage exposed to the seller?
10Decisions & outputs
What the work produces.
- 01Writeback contract
- 02Ownership model
- 03Freshness & staleness rule
- 04Published-vs-written reconciliation
- 05Activation rule
- 06Lineage link