AL-2026-02 · White paper
Conversation ownership: a data model for omnichannel sales
Four channels, one customer, and no agreement about who is responsible. A proposed model where ownership is explicit, transferable, and always held by someone.
Most CRM data models represent channels as parallel logs attached to a contact. This paper argues that structure is the root cause of the failure modes sales teams complain about most, and proposes a model where the conversation, not the channel, is the primary object.
1. The failure this addresses
A customer submits a form on Monday, replies to a WhatsApp message on Tuesday, answers a call from a voice agent on Wednesday, and speaks to a human rep on Thursday. In a channel-log model these are four records under one contact, and the following questions have no reliable answer:
- Who is responsible for this customer right now?
- Has anyone responded to what they said most recently, on any channel?
- If an automation fires today, does it know about Thursday's call?
- When this closes, which touch gets the credit?
Every one of these is answerable by a human looking at the screen and unanswerable by the system, which means every one of them is a place where automation misfires and a rep has to clean up.
2. The proposed model
2.1 The conversation is the primary object
A conversation spans channels. It has a customer, an owner, a state, and an ordered timeline of events drawn from every channel. Channels become an attribute of an event, not a container for it.
This is a small change to state and a large change to behaviour, because it makes "the last thing that happened" a well-defined value. In a channel-log model, each log has its own last event and none of them is authoritative.
2.2 Ownership is a required, single-valued field
Every conversation has exactly one owner at every moment of its life, assigned at creation, inside the same transaction that creates it. Not nullable, not eventually assigned. The mechanics of doing this quickly enough to sit inside a write are covered in routing a lead in under a second.
An automated agent can be an owner. This matters: if a voice agent is working a conversation, the model should say so rather than leaving it unowned or falsely attributing it to the human who will eventually pick it up.
2.3 Transfers are events, not edits
Ownership changes are recorded on the timeline with a reason, rather than overwriting a field. The current owner is a projection of the transfer history. This costs a little storage and buys the ability to answer "why is this mine?", which is the question reps actually ask.
2.4 Activity is unified and directional
Every event carries a direction: inbound from the customer, or outbound from the business. This is the substrate that lets automation fire on evidence rather than on a timer. "No inbound activity of any kind for N hours" is a statement that requires a unified, directional timeline and is inexpressible without one.
3. Consequences for automation
| Rule | Channel-log model | Conversation model |
|---|---|---|
| Follow up if no reply | Fires per channel; sends four nudges | Fires once, on the conversation |
| Escalate if stalled | Cannot see cross-channel activity | Sees the whole timeline |
| Stop on engagement | Only detects same-channel replies | Any inbound event stops it |
| Respect messaging windows | Window state lives in the channel | Window is a constraint on a send |
The middle two rows are where customers notice. A nudge that arrives after the customer has already replied on a different channel is the single most common complaint about CRM automation, and it is a data model problem wearing a configuration problem's clothes.
4. What the model does not solve
Attribution. Making the timeline unified means every touch is visible; it does not decide which touch earned the outcome. We have implemented several standard schemes: first touch, last touch, and weighted variants. The recurring problem is not statistical. It is that a sales manager has to explain the resulting number to the team, and the models that survive that conversation are the ones too simple to be accurate.
We consider this unsolved and list it among our open problems. This paper deliberately stops at the point where attribution begins, because the data model is a prerequisite for any attribution scheme and is worth getting right independently of which one you eventually choose.
5. Migration notes
Moving an existing installation from channel logs to conversations is not a schema change, it is a backfill with judgement in it, deciding retrospectively which historical events belonged to the same conversation. Two things we would recommend to anyone attempting it:
- Set a cutover date and do not backfill before it beyond a shallow window. Reconstructed conversation boundaries in old data are guesses, and they will be treated as facts by every report built on top of them.
- Assign historical ownership from the transfer history where it exists, and to an explicit "unassigned, pre-migration" identity where it does not. A synthetic owner that is honestly labelled is much safer than a plausible wrong one.