Get each enquiry to someone who can act on it.

Separate an incoming enquiry, a contact, an account and an opportunity. Two people at one company can ask different questions. One person can send a new request about work already in progress. Matching the company supplies context; it does not make every new message a duplicate.

Name the event that starts routing, the record it should create or update and the output the recipient receives. A useful task includes the original enquiry, relevant account history, the rule that selected the owner and unresolved questions. A notification containing only a name and email address may force the recipient to reconstruct the request.

The CRM data quality checklist helps establish identity and field ownership. Shared customer data defines how account context should travel between systems. Routing then allocates the work; qualification remains a separate assessment of fit and the next useful step.

Decide how existing ownership, service responsibility, product expertise, territory and capacity interact. Does an existing account owner keep a new site’s request when it falls into another region? Does a technical support issue go to sales? Agree the order of precedence before configuring it in the software.

Salesforce’s assignment-rule guidance provides a product example of ordered criteria and assignment to users or queues. Confirm the trigger, order and fallback behaviour in the system you actually use; a written policy alone does not prove the configuration follows it.

State what happens when no rule matches or two rules conflict. A named review queue can be a valid destination when someone owns it and knows what to resolve. “Unassigned” is a status to investigate, not a finished handover. The territory coverage guide helps settle overlaps before turning them into routing conditions.

Name a substitute, shared queue or deliberate pause for each route. Set a review interval for unaccepted work and an escalation recipient. Use a time commitment the team can actually operate; an automatic escalation every few minutes can create noise while leaving the underlying request untouched.

Keep the permanent account owner distinguishable from the person covering today’s task. Covering a colleague should not silently rewrite long-term ownership or redirect every future message. Record when cover begins, who can reassign work and how responsibility returns.

Record when someone accepts the task; inbox delivery alone does not confirm that it has been read or taken on. The operator needs to distinguish work awaiting acceptance, work accepted by cover and work held while ownership is resolved.

Preserve the source request identifier where one exists and give the resulting task a stable reference. If the same event arrives again, find the existing action and its state. Stripe documents duplicate webhook delivery; check the equivalent delivery contract for each connection involved in your handover.

A new enquiry about another product or a changed requirement may deserve a new task on the same account. Compare the actual request and identifiers rather than discarding messages with a familiar email address or subject. Uncertain duplicates belong in review with both requests visible.

Include the uncertain-save case. If a connection times out after creating a task, the operator or recovery process must determine what happened before creating another task or sending another notification. Keep queued, confirmed and unresolved outcomes distinct, and preserve enough information to reconcile a delayed response.

Changes in account context also need a rule. If ownership changes while a task is waiting, decide whether to keep the current recipient, transfer the task or request review. Retrying an old event should not silently overwrite a newer ownership decision.

Use a new account, an existing account, an ambiguous match, an absent owner, an event delivered twice and a new request from a familiar contact. For each, write the expected record, recipient, context and exception before running the test. Keep the exercise contained without real customer messages or production record changes.

Ask the recipient to find the original request, explain why it reached them and show the next action. Then interrupt a connection and inspect how the operator discovers and resolves the uncertain result. The workflow testing checklist gives a record for expected and observed outcomes.

Add a changed territory rule and an already reassigned task before acceptance. These cases reveal whether the system uses current rules deliberately or replays an outdated decision. Keep the tested rule version and outcome with the handover documentation.

Track incorrect matches, missing owners, unaccepted tasks, failed deliveries and repeated notifications separately. Inspect the actual records behind a change in counts. More assignments may reflect duplicated events or a broader input feed rather than more useful conversations.

Review exceptions with the people receiving the work. A recurring queue item may expose a missing territory decision, confusing form field or outdated account plan. Repair the source of the ambiguity where possible, then test the affected cases again.

For campaign responses, agree who reviews the reply, asks clarifying questions, qualifies the enquiry and arranges the next conversation. A Build campaign includes its agreed operation and reply handling. Your team, ClarityRev or both can carry out those steps, while sales calls, technical commitments, prices and closing remain with your team. A standalone routing repair has its own scope; an AI-assisted inbox task may fit AI Workflows. In each case, agree who handles exceptions and keeps the connection working.