Trigger and output
The trigger is a new inbound inquiry or a meaningful update to one. The output is a deduplicated CRM record with the intended owner, reason for assignment, next action and response due time. If the rules cannot resolve it, a named operator receives the exception.
This is a reference design. Adapt it to the client’s CRM, territories, business hours and relationship rules before running it.
Required inputs
Keep the original submitted message, contact details, company identifiers, source, submission ID and submitted timestamp. Read existing customer status, open opportunities, account owner, suppression and recent activity before making a new assignment.
The GTM brain supplies territory rules, tie-breakers, excluded inquiry types, service coverage and escalation ownership. These are business decisions; enrichment cannot invent them.
Run the workflow
- Validate and deduplicate the submission. Retain repeat inquiries as activity on the correct record rather than silently discarding useful buyer intent.
- Match the contact and account using stable CRM IDs where available. Resolve ambiguous matches before writing an ownership change.
- Check customers, open deals and suppression. Existing relationships keep their owner unless the agreed escalation rule says otherwise. A marketing opt-out does not mean a support inquiry should vanish; route the service request appropriately without adding it to a campaign.
- For new accounts, enrich only missing fields required by the rule. Set a timeout and use a fallback if the provider cannot answer.
- Apply territory, segment and capacity logic. Store the rule version and assignment reason.
- Prepare the concise brief: inquiry, relationship, fit rationale, checked facts and the next action.
- Notify the owner once. Track acceptance and first response. Escalate missed commitments to the named fallback.
A usable routing receipt
- Inquiry
- Demo request from a contact at an existing account
- Relationship
- Open opportunity found
- Assignment
- Existing opportunity owner. No round-robin reassignment.
- Buyer context
- Original request and current opportunity summary attached
- Exception check
- If owner is unavailable, notify the documented cover owner
The receipt should explain the assignment. Keep the score’s inputs and reasoning available to the operator. Never require a rep to trust an unexplained number to understand the buyer.
Exceptions and stop conditions
| Case | Behaviour |
|---|---|
| Duplicate webhook | One assignment and one notification for the stable event |
| Two plausible account matches | Hold the ownership write; send to a named resolver |
| Customer using a personal email | Use relationship context; avoid creating a competing account |
| Open deal with a different contact | Preserve the opportunity owner and attach the new activity |
| Enrichment timeout | Use known data and the fallback route; do not leave the inquiry waiting |
| Owner absent or at capacity | Apply the agreed cover rule and log the reason |
| CRM write failure | Retry idempotently and expose the unassigned inquiry |
| Invalid or abusive inquiry | Apply the documented exclusion and retain the reason |
Test and release
Replay known inquiries for each exception above. Compare expected and actual owner, next action and notification count. Test reassignment separately from new assignment. A human checks the outputs before the rule becomes the live default.
Start with one defined inquiry type, such as demo requests. Keep an exception queue during the first live week and review it daily. Expand once the ownership results and response coverage are dependable.
What to measure
Track valid-owner coverage, time to acceptance, first response, missed commitments, exception age, reassignments and accepted opportunities. Separate no-fit from unworked leads. Review repeated exceptions weekly and change the relevant rule or input.
The inbound playbook explains the broader sales handoff. This workflow implements its ownership decision.
Publication and source record
Published on GTMhub: . Last reviewed: .