Protect ownership before enriching the request

Narrated reference walkthrough. System-generated voice. Illustrative inputs.

0:00 The decision
This narrated reference walkthrough uses illustrative inputs and makes no live CRM changes. The buyer problem is a demo request that gets enriched and routed as if it were a new account, even though the company already has an open deal. Ownership needs to be resolved before optional enrichment becomes the bottleneck.

0:30 Start with the actual request
Save the original inquiry, source and submitted context. Resolve the company and existing relationship using reliable identifiers. A customer, an open opportunity and a genuinely new account need different branches. The useful output is an owned next action, not merely a richer row in an enrichment table or another lead notification.

1:00 Inspect the ownership gate
The diagram checks identity and relationship before selecting the owner. Existing relationships stay with their current owner. A new eligible company follows the agreed territory and capacity rules. An unresolved identity gets a named exception owner. The request remains saved, and the team can see what needs resolution instead of losing it silently.

1:30 Run a new-company example
The example starts with a new eligible company, resolved identity and an available owner. The decision assigns the owner now. Available accepted enrichment can add context, but it does not replace the ownership receipt. That receipt should preserve the source, owner, reason and next action so the handoff can be inspected.

2:00 Keep the existing deal owner
Change the CRM relationship to an open opportunity. The example keeps the existing owner and sends the context into that conversation. It does not create a new cold prospect. This avoids campaign collisions and the uncomfortable experience of a buyer getting an unrelated message while already speaking to your revenue team.

2:30 Link the duplicate request
Now choose a duplicate request. The workflow links it to the original inquiry and preserves source history. A repeated form submission or webhook can contain useful new context, but it should not create competing owner tasks. The event receipt explains what was linked, what was retained and which conversation remains accountable.

3:00 Use the capacity fallback
Return to a new company and make the assigned owner unavailable. The agreed fallback keeps the request owned and exposes the capacity exception. A routing system needs this operating rule before launch. Otherwise the ideal diagram stops working as soon as someone is away or the sales team reaches its workload limit.

3:30 Do not wait for optional enrichment
Restore the owner and make enrichment unavailable. The example still routes the request, then queues optional enrichment separately. This is a useful failure test: a research provider outage should not make the sales team wait for a saved, eligible inquiry that already has enough context to assign an accountable owner.

4:00 Measure the real handoff
Read owner assignment, acceptance and first action as distinct observations. Check the response target against the company’s actual commitment. Track unowned requests, identity exceptions and source completeness. Faster routing helps only if the correct owner can use the context and work the request; a notification timestamp alone does not prove that.

4:30 Put the decision to work
Use the reference example to rehearse customers, open deals, duplicates, unresolved companies and capacity failures. The full page includes inputs, branches and a test checklist. GTMhub connects this job through GTM engineering on the company brain. The client keeps its accounts and receives the brain and lane plugin after the first term.