Capturing expert judgment through real high-touch sales workflows
A three-part system thesis for turning execution-linked expert judgment into reusable operating intelligence and Product / Client learning loops.
High-touch commercial work has context, but loses how experts use it.
What systems preserve
- Catalog facts and product data
- Customer behavior, clicks, purchases, returns, unsubscribes
- CRM fragments, relationship records, order history, sales attribution
- Final outcomes after the action
What disappears
- Why an advisor selected, removed, held, or softened a direction
- How product, client, timing, message, and relationship context were connected
- How a prior edit changed when adapted to another client, group, segment, or moment
- Which expert judgment produced the client-facing action
The missing data object is the commercial decision itself: what was selected, for whom, how it was framed, when it was sent, how it was adapted, and how the client responded.
The capture mechanism must originate from real work.
The system should not ask experts to pause and explain themselves after the fact. For high-fidelity judgment data, the expert needs a better working surface first, and the event record should be emitted as a side effect of the work.
Boundary
The tool captures the trace of judgment. It does not claim to capture the full internal state of the expert.
Operating principle
Build the tool the expert needs to do the work, and let the data be a byproduct of the work itself.
A clienteling-specific workflow becomes the capture layer.
| Workflow step | Data trace |
|---|---|
| Browse / discover products, select product set, arrange sequence | Ordered SKU list, anchor and supporting pieces, product set context |
| Write subject and message, choose recipient or segment | Message frame, recipient logic, recipient count, timing |
| Reuse or adapt an existing edit | parent_edit_id, products kept / removed / added, resequencing, rewrite, retargeting |
The event record develops through a stepwise attribution chain.
Ordinary behavioral data says a client clicked or purchased. Attributed behavior says the client clicked or purchased after a specific advisor action, product set, message frame, timing choice, and tracked session.
A department-level multi-agent layer returns judgment to operating workflows.
The system is centered on the high-touch sales department. It reads existing enterprise context, supports Sales Agent and Operations Agent workflows, and captures expert judgment as events inside real work.
decides · approves · acts · reviews
The MVP uses CEE as the main stream and selected ODE as bounded judgment context.
| Event type | When it happens | Captured fields |
|---|---|---|
| Commercial Execution Event / CEE | Judgment becomes client-facing commercial action. | Product set, recipient, message, timing, parent-child diff, tracking, attributed outcome. |
| Operating Decision Event / ODE | Judgment happens inside department workflow. | Trigger, timestamp, context snapshot, decision/action, rationale, owner, outcome where available. |
| Expert Judgment Event | Any captured CEE or selected product/client execution-related ODE used by Dual Intelligence. | Event type, workflow, owner role, timestamp, context, action, outcome. |
For the first Dual Intelligence MVP, selected ODEs enter the shared spine only when they can be bound to a product, client, segment, edit, or commercial opportunity.
Dual Intelligence uses one shared execution spine to power two connected learning loops.
Product Loop
Learns how products function in expert-led selling: product role, pairing pattern, message sensitivity, timing sensitivity, client-state fit, and commercial context sensitivity.
Client Loop
Learns context-specific client and segment state: readiness, purchase saturation, brand fatigue, tone sensitivity, timing sensitivity, relationship risk, and service sensitivity.
A product is not only a SKU with attributes. A client is not only a profile with behavior. The expert action connects the two.
The shared execution spine learns from three signal types.
A single event is evidence. Repeated expert judgment events with joined outcomes create stronger learning patterns for both Product Loop and Client Loop.
Start with the shared execution spine, then turn it into two learning loops.
| Step | Build focus | Output |
|---|---|---|
| 1 | Finalize Commercial Execution Event schema from Whitepaper 01. | Reliable CEE stream with product set, recipient logic, message, timing, tracking, parent-child diff, and attributed outcome fields. |
| 2 | Select ODE categories from Whitepaper 02 that explain Product / Client execution. | Only ODEs bound to product, client, segment, edit, or opportunity. |
| 3 | Define shared spine joins and multi-recipient handling. | Event ID, edit ID, product ID, client / recipient ID, segment ID, advisor-safe ID, workflow source, timestamp, recipient-level outcome joins. |
| 4 | Define outcome attribution layers. | Event-level, product-level, and client-level outcomes with direct / probable / indirect / unassigned confidence labels. |
| 5-7 | Generate Product Loop outputs, Client Loop outputs, and confidence gate. | Read-only insight, advisory suggestion, or workflow guidance based on repeated evidence, recency, attribution confidence, and expert override feedback. |
This work shows how frontline judgment can become system architecture.
What the public overview shows
- A concrete business problem in high-touch commercial work
- The event objects needed to preserve expert judgment
- A department operating layer that keeps humans as judgment owners
- A first MVP path from workflow capture to Product and Client learning loops
What it demonstrates
- Business-side system design from real operating constraints
- Workflow-native data capture instead of retrospective annotation
- Clear boundaries between deployed workflow, agent architecture, and future learning loops
- Translation between commercial judgment, data structure, and implementation planning
Full whitepapers are available for deeper review where appropriate.