A five-person sales team receives enquiries from several service pages. Some requests require integration expertise, others need a regional representative, and some arrive outside working hours.
Forwarding every submission to a shared inbox leaves ownership unclear. A routing workflow should produce a recorded decision and a recoverable next step.
Start after durable acceptance
Validate the enquiry and save it before promising receipt. Preserve permitted campaign context alongside the enquiry. Use a stable submission reference so later delivery and assignment attempts can be traced.
Keep contact matching separate from enquiry creation. An existing contact can submit a new request that needs its own history.
Define a rule order
For this hypothetical team, the rules could be:
- Keep an existing active account owner when appropriate.
- Match the required service expertise.
- Apply an explicit regional coverage rule.
- Select an available representative within that eligible group.
- Send unmatched enquiries to a monitored fallback queue.
This order is a business decision. Write it down and test it with sales before embedding it in code.
Make ownership changes atomic
Two workers should not assign the same enquiry independently. Use a transaction or conditional state update that reserves one assignment.
Record the selected owner, rule version, decision time, and a controlled reason code. That makes 'why did this lead reach me?' answerable without searching application logs.
Do not trust a hidden browser field as authority to assign a privileged owner. Evaluate routing rules on the server.
Include availability and fallback behavior
A representative on leave should not receive work simply because their name remains in a rotation. Define how availability is updated and who maintains it.
If nobody is eligible, keep the enquiry visible in a fallback queue with an owner responsible for reviewing it. A notification to an unattended inbox is not a complete fallback.
Separate assignment from notification
The assignment can succeed while an email notification fails. Save those states separately. Retry the notification without assigning the enquiry again.
If CRM delivery is asynchronous, record pending and confirmed delivery states. Avoid creating a second owner decision every time the integration retries.
Verify operational outcomes
| Scenario | Expected behavior |
|---|---|
| Returning active account | Existing-owner rule evaluated |
| Specialist unavailable | Documented alternative or fallback |
| Two workers process one enquiry | One effective assignment |
| Notification fails | Ownership remains stable |
| No eligible representative | Monitored fallback state |
Measure unassigned age and time to first action. Routing is successful when somebody can act on the enquiry, not merely when a script chooses a name.
Top comments (0)