Lead Routing: Choose Assignment Rules That Fit Your Sales Team

Lead routing decides who takes responsibility for a new enquiry. Begin with the people who can handle the request, preserve a useful existing relationship where appropriate, and choose a fair way to distribute work within that eligible group. Give unmatched or unaccepted enquiries a named fallback so they remain visible.

For a small team whose members handle similar work, a simple rotation may be enough. Different service areas, languages or specialisms require an eligibility check first. Uneven backlogs may justify capacity-based assignment. The best method is the one your team can explain and maintain when someone is away.

Here is the decision this guide will help you make: when the next enquiry arrives, who should receive it, why that person, and who takes over if they cannot act?

Start with one enquiry and the people who could help

Consider a fictional Canadian implementation-services team. Ana handles English-language Ontario enquiries. Bea and Cyril handle English and French in Ontario. Dev handles English-language British Columbia enquiries. Bea is also the only person approved for the example’s restricted records. These invented responsibilities illustrate the choices; they are not staffing recommendations.

A new Ontario enquiry asks for an implementation consultation in French. Sending it to the next name in an all-team rotation could select Ana or Dev, neither of whom meets the stated requirements. The first decision is therefore to identify the suitable group: Bea and Cyril.

If both are available, authorized and able to take more work, the team can use a rotation or a maintained workload measure to choose between them. The customer does not need to know the allocation mechanism. They need someone who can understand the request and take the next step.

Now add a detail: the customer already works with Bea, who is on leave. There are two responsibilities to consider. Bea may remain the relationship owner, while someone else handles this enquiry. If the record is ordinary and Cyril can cover it, an approved temporary handoff may be suitable. If it is restricted and Cyril lacks access, an automatic transfer to him would be inappropriate.

The duty manager then owns the exception: arrange authorized coverage or a suitable next step. The request should not sit unattended merely because the preferred owner is absent, and an access restriction should not disappear merely because the queue is busy.

This example shows why a useful policy combines methods. Eligibility determines who can receive the work. Relationship continuity can influence who should receive it. Rotation or workload can settle the remaining choice. A fallback handles the cases where that process produces no usable owner.

Compare the common routing methods

You do not need to select one method for the entire business. You may use territory to choose a team, expertise to narrow the group and a rotation to allocate within it. Keep each layer connected to an actual operating need.

Round robin: take turns within a suitable group

A round-robin process gives the next enquiry to the next eligible person in a defined sequence. It can suit a team with comparable skills, working hours and enquiry types. People can understand it, and the basic rule is easy to explain when someone asks why they received a request.

Equal new assignments do not necessarily create equal workloads. One person may start the day with several unresolved proposals while another has none. One may handle complex work that takes longer. If those differences are material, a simple rotation needs a capacity limit, separate pools or another reviewed adjustment.

Decide what happens when someone is away or unable to take work. Does the rotation skip them? Do they rejoin at the next normal position? Does a temporary absence affect later allocation? These are management decisions with practical consequences, especially where salespeople receive commission.

Also verify what the software means by rotation. A feature may distribute evenly over time without literally walking through a fixed sequence. Avoid promising a particular order until the actual behaviour is confirmed.

Territory: route according to where the work belongs

Territory-based routing is useful when location changes who can deliver, travel, price or support the service. It can reduce unnecessary transfers by sending a site-specific enquiry to the team responsible for that area.

Define which location matters. The customer’s head office, billing address and project site may be different. For an on-site service, the project address often matters most. For remote work, the relevant boundary might be an approved market or contractual region.

Write down what happens at borders and for multi-location projects. If one proposal covers Ontario and British Columbia, sending it independently to both territories could create competing conversations. A coordinator may need to own the combined request while regional specialists contribute.

Use confirmed service information where possible. A telephone area code or company name is not a reliable substitute for the location of the requested work. Unknown territory should go to clarification, rather than quietly defaulting to the home office.

Expertise or language: match the work to someone equipped to handle it

Specialist routing makes sense when the first conversation requires knowledge or a language capability that the whole team does not share. A software integration question, an enterprise procurement process or a French-language request may need a specific pool.

Keep the criteria concrete. “Senior salesperson” is less useful than “approved to handle this service and able to conduct the requested conversation.” Maintain the roster when people train, change roles or stop covering a service.

Over-specialization can create unnecessary bottlenecks. If general intake can arrange an assessment without specialist judgement, let it handle that step and involve the specialist later. Reserve narrow routing for work where the distinction actually changes the next action.

The fallback must preserve the essential requirement. If a French-speaking candidate pool is unavailable, an English-only general pool is not automatically an acceptable substitute. A supervisor can arrange support or an agreed alternative without pretending the original need disappeared.

Existing-account ownership: preserve useful context

Customers often benefit from speaking with someone who knows the relationship. Existing-owner routing can prevent repeated explanations and conflicting offers. It is particularly useful when an open discussion or account commitment is relevant to the new enquiry.

First establish that the ownership record is current. A contact assigned years ago through an import may not represent an active relationship. A person may have changed employer, or the account manager may no longer work for the business.

Separate the relationship from the immediate task. The account manager can remain responsible for continuity while another employee handles an assessment, support issue or new specialist request. Avoid transferring every related record merely to arrange temporary coverage.

Always check availability, ability and access. Existing ownership should not override a restriction or leave a customer waiting indefinitely for someone on leave.

Capacity-based assignment: account for the work already waiting

Capacity-based routing considers the defined workload before giving someone another enquiry. It can help when backlogs differ substantially or staff split their time across different duties.

Choose a measure you can maintain. Active enquiries may be sufficient where requests are similar. More complex work may need separate queues or carefully defined work units. A vague busy score that employees interpret differently will create disputes rather than clarity.

Decide when work stops consuming capacity. Is it after a useful first response, after qualification, or only when the opportunity closes? Each choice measures a different burden. Counting every open opportunity could make a salesperson with many long-term proposals look unavailable for a brief intake call.

Keep availability separate. An employee on leave may have the smallest backlog and still be the wrong recipient. Capacity only helps after the person is eligible and able to act.

Manual triage: use judgement where the variation warrants it

A small or highly specialized team may benefit from an intake coordinator reviewing new requests. Manual triage can handle unusual combinations that would otherwise require many brittle rules.

It works when the queue has a named custodian, coverage and a visible handoff. “Someone checks the inbox” is not a complete process. The coordinator needs enough context and authority to assign the work without seeking approval for every ordinary case.

Watch for the coordinator becoming the bottleneck. Repeated, straightforward decisions can become rules once the team understands them. Keep judgement for the exceptions that genuinely need it.

Choose the simplest combination that fits

Write down the conditions that would make a person unsuitable for a request. Service capability, territory, language, required access and current availability are common examples. These are eligibility checks, not points in a score.

Next, decide whether relationship continuity should take priority among eligible people. Then choose how to distribute the remaining enquiries. A rotation is easier to maintain than a workload model if nobody can keep the workload data current.

For the fictional implementation team, the everyday approach could be:

• Keep a current existing owner when that person can appropriately handle the enquiry now.
• Otherwise choose the group matching service, territory, language and access needs.
• Allocate within that group using a maintained workload rule or rotation.
• Send unresolved cases to the duty manager with the reason and original enquiry context.

Do not add every possible customer characteristic to the rules. A field should change the destination for a defensible reason. The acquisition campaign may be valuable for reporting but irrelevant to who can help. A lead score might inform order of attention without deciding who has permission or the right expertise.

Keep those purposes clear when discussing improvements. Routing owns assignment and accepted responsibility. The speed-to-lead guide owns the useful response and its timing. A high score does not excuse an unowned enquiry, and a completed assignment does not show that the customer has been helped.

Turn the decision into a short routing matrix

A routing matrix makes the policy visible. Start with the request conditions, eligible group and fallback. Add an order when rules can overlap. You do not need a large table of technical fields to discuss the first queue.

The fictional team’s three service rules look like this:

The French Ontario enquiry matches the first two descriptions. The specific French rule takes precedence, so the general rule does not make Ana eligible. The candidate group is then checked for current availability, capacity and access. A restricted record leaves only Bea eligible under this example’s permissions.

The table is intentionally small. The real policy also needs to address existing ownership before ordinary distribution and identify requests that require clarification. Keep those preliminary decisions beside the matrix so staff do not mistake one table for the entire process.

Decide which rule wins before configuring it

Overlapping rules are not inherently wrong. A broad Ontario rule can sit below a more specific French-language rule. The problem arises when two equally authoritative rules lead to different destinations without an agreed winner.

Ask two team members to route a few invented enquiries using the written policy. Include a boundary location, a specialist request and an existing customer. If they disagree, refine the policy before translating it into software.

Microsoft’s current Dynamics 365 assignment-rule documentation describes rules applied in listed order, with processing stopping at a match. That makes order consequential. Other tools may use different mechanics, so the configuration must reproduce the decision your team agreed on rather than silently supply a different one.

If a specific rule has no eligible person, do not automatically fall through to an unrestricted general rule. Decide whether that fallback is suitable and permitted. Sometimes the right outcome is a visible hold while a supervisor arranges appropriate coverage.

Collect only the information needed to route

A useful intake process gathers enough information for the next decision without making the customer complete a sales specification. For the fictional team, service, project location and requested language determine much of the initial route. Existing ownership and record access come from trusted internal information.

The source can vary. A form may provide a service selection. A caller may describe the same need in ordinary language. A referral email may omit location entirely. The policy needs to work with all those routes, including unknown values.

Agree how common variations are interpreted. “Ontario” and “ON” can map to the same approved category. An unfamiliar location should remain unresolved until someone checks it. Guessing or forcing a default can send work to a team that cannot fulfil it.

Keep the original message available to authorized staff. A standardized category can simplify routing while losing a detail that matters to the response. The recipient should be able to see why the classification was made and correct it when necessary.

Missing information should have a next action. If location determines the route, an intake coordinator can ask for it. If a campaign tag is absent but does not affect assignment, work should continue. Requiring irrelevant fields delays the customer and encourages placeholder entries.

Maintain internal inputs as carefully as customer inputs. An employee’s service skills, languages, territory and availability can become outdated. Name the person who updates the roster when someone changes role, joins the team or takes leave.

Keep existing customers from being passed around

A customer asking for additional work may expect the account manager to recognize the relationship. A purely new-lead rotation can create a cold introduction inside an established account.

Before assigning, check whether the enquiry belongs to an active relationship and whether an open opportunity already addresses the same request. The goal is continuity, not keeping every future message attached to one employee forever.

In the fictional French enquiry, Bea’s leave creates a coverage decision. If Cyril has the required access and expertise, a supervisor can arrange temporary enquiry ownership while Bea remains the relationship owner. The handoff should include what the customer has already discussed, any promises and the next action.

If Cyril is not authorized for the record, the supervisor must arrange an appropriate route. Sending the full enquiry to a broad team channel while deciding would defeat the restriction. Use an access-controlled link and enough context for the authorized reviewer to act.

Explain temporary coverage to the customer where useful. A short message that a colleague is handling this request while the usual contact is away can prevent confusion. The internal system should make the same distinction so the temporary responder does not unintentionally become the permanent account owner.

When the usual owner returns, decide whether to transfer the active request back or let the covering person finish it. An automatic reversal can disrupt a conversation that is progressing well. Continuity should follow the current work, with an explicit handoff if responsibility changes.

Employee departures need a broader review. Find open enquiries, future tasks, active opportunities and account relationships. Reassign them deliberately and check that someone accepted the work. Disabling an account does not prove that everything associated with it has found a new owner.

Design a fallback that someone actually works

Every routing process produces exceptions. A service is missing, two rules conflict, the only specialist is away or a record requires restricted handling. A fallback should make that situation manageable rather than hide it in an “other” queue.

Name the duty role and the person covering it. Say what the reviewer can decide and where they get help. A supervisor handling missing location information may have different authority from someone resolving access restrictions.

Give the reviewer the reason for the exception. “No owner found” is less useful than “French-language Ontario request; both eligible responders unavailable.” The second explanation points directly to a coverage decision.

Keep the request’s original timing and customer commitments attached. A move to review is still the same enquiry. The backup should know whether someone has already promised a callback or asked for information.

Make the queue easy to inspect. Show unassigned and unaccepted work, when it arrived and the next action. Assign someone to check it at a frequency suitable for the volume and response promise. A fallback that depends entirely on one notification can fail when that notification is missed.

Stop transfers that circle back to the same problem

An enquiry can bounce between sales and operations if each team thinks the other should handle it. Automatic reassignment can reproduce that loop faster.

Record where the request has already been offered and why it was returned. After a bounded number of unsuccessful transfers, have a supervisor resolve the responsibility directly. Choose the boundary for your team; no universal transfer count fits every process.

Do not return a request to the same unavailable person simply because a new event arrived. Preserve the reason the earlier assignment failed until it has been resolved. A customer’s repeated submission should not wipe out the handoff history.

A manual override can select a different suitable person, but it should preserve access requirements and explain the reason. Review frequent overrides later. They may reveal an outdated territory, an unrealistic workload rule or a service that needs a clearer owner.

Treat capacity as a live operating choice

A workload rule is only as useful as the information behind it. If a salesperson closes completed enquiries promptly while another leaves them open, their apparent capacity will differ even when their actual workload does not.

Define the unit and keep it tied to the task being allocated. For first-response work, unresolved intake requests may be more relevant than every active deal. For a technical assessment queue, time commitments or separate complexity categories may matter. Avoid precise weighting that nobody can justify or maintain.

The existing companion uses active enquiry counts as a simple teaching model. Suppose Ana has one of four available slots occupied, while Bea and Cyril each have two of four. Among otherwise eligible Ontario English responders, Ana has the lowest used-capacity proportion. Dev’s empty queue does not matter because he serves a different territory.

Those numbers are fictional limits, not recommended caseloads. They demonstrate that eligibility comes first and that a workload measure needs a clear denominator. If one employee has a limit of two and another eight, comparing raw counts alone tells a different story from comparing the share of each limit used.

Check how often the information changes. A yesterday-evening snapshot may be misleading by the morning rush. If the system cannot establish current capacity, arrange review or use another approved method. Unknown workload should not silently mean unlimited availability.

Plan for a specialist bottleneck. If Bea is the only person eligible for restricted French-language work, changing the allocation formula cannot create another qualified responder. The business needs a coverage, training or service-scope decision.

Verify what the software actually balances

HubSpot’s current owner-rotation documentation distinguishes ordinary equal distribution from additional options for specific record types. It also specifies paid-seat and team-membership requirements. Check the exact object, subscription and action rather than assuming a feature named rotation implements your workload policy.

Microsoft’s assignment documentation similarly treats availability and capacity as configurable considerations. Ask which records contribute to the workload calculation and how an unavailable seller is treated. A setting that appears enabled may still rely on a schedule or roster nobody maintains.

The practical test is straightforward: create known starting workloads, vary one person’s availability and verify the destination for the next invented enquiry. Repeat with everyone at capacity. The result should match the policy, including the fallback.

Separate repeat delivery from a new customer request

An integration may send the same form submission twice after a temporary failure. That should not create a second owner or duplicate customer contact. Preserve a source event identifier so the system can recognize a replay.

A customer submitting again is a different situation. They may be following up on the same unanswered request, adding a service location or starting a separate project. An email address alone cannot tell you which.

For the same underlying request, keep one main enquiry with a clear owner and link the additional message. Preserve any new information and the original arrival time. Before treating it as a duplicate, confirm where the next action will happen.

For a genuinely different purchase, create or retain a separate enquiry while linking the customer relationship. Otherwise, two projects can become tangled in one status and one set of notes.

When identity is uncertain, route the question to someone who can review it safely. Shared inbox addresses, company domains and phone numbers can belong to several people. Similar names may be different organizations. Avoid automatic merges based on a weak resemblance.

The response process should not restart its clock whenever the customer tries again. Routing should supply one current owner and the full relevant history, making it easier for that person to respond to the actual situation.

Keep channels from creating competing owners

The same customer may call, submit a form and reply to an older email. If each channel has an independent assignment process, three employees can believe they own the same request. The customer then receives repeated questions or inconsistent promises.

Decide where cross-channel responsibility is resolved. A small team might use one intake queue with links to the original conversations. A larger team may keep channel-specific tools but share the current enquiry owner. The important point is that a new message updates the work already underway when it concerns the same request.

Include partner referrals in this decision. A salesperson may be named in the referral, while the ordinary territory rule points elsewhere. Decide whether the named relationship changes ownership or simply supplies context. Do not make staff infer the policy from whichever notification arrives first.

Test a realistic sequence: an enquiry arrives by form, someone accepts it, and the customer calls before receiving the reply. The person answering should be able to see the accepted owner and add the new information. If they can resolve the request immediately, record that outcome so the original owner does not continue working from an outdated picture.

This does not require every channel to share one interface. It requires a clear place to establish the current owner and a reliable way for the people involved to see the latest action.

Confirm the handoff, not just the notification

A routing decision selects a destination. The assignment still needs to be saved, available to the recipient and accepted under the team’s operating process.

Make the recipient’s responsibility clear. They should see what the request concerns, why it reached them, any relevant relationship, the existing deadline and the next expected action. A generic “new lead” notification may not provide enough context to distinguish a new enquiry from an update to an existing one.

Keep notifications proportionate. A record reference and secure link may be enough. Copying sensitive details into email or a broad chat channel can expose information beyond the people allowed to see the CRM record.

During a transfer, the previous owner remains responsible until the replacement accepts, unless a supervisor explicitly takes over. If the previous owner cannot act at all, the supervisor must hold that responsibility. There should be a clear answer during the transition, not only after it ends.

A saved owner field also does not prove that related tasks moved. Check the actual object your policy controls: enquiry, lead, opportunity, ticket or conversation. Decide which associated actions should follow and which relationship ownership should stay unchanged.

Our CRM implementation guide covers the broader record and permission design. For routing, verify the specific end state: the right person can access the right work, knows they own it and has a way to act.

Test ordinary assignments and uncomfortable exceptions

Begin with invented enquiries that staff can reason through without software. Ask the business reviewer to state the expected owner or review destination before the test runs. This keeps the test from becoming a demonstration that merely accepts whatever the automation does.

Use the French Ontario enquiry first. With Bea and Cyril both available and authorized, the chosen distribution method should select one of them. Add the restricted-access requirement and confirm that only Bea remains eligible. Make Bea unavailable and verify the approved review path.

Then try a location on a territory boundary, a request with no service selected and an existing customer with an outdated owner. Those cases expose policy gaps that an ordinary form submission may never show.

Test a declined or unaccepted handoff. Does the backup see it? Does the original timing survive? Can the request return to the same unsuitable owner indefinitely? Check the actual person and queue that will handle the exception.

Include a disabled account and a recipient without access. Use that person’s permissions, not an administrator’s view. An assignment that only an administrator can open has failed the business task.

After the written policy is coherent, test the live implementation in an appropriate controlled environment with approved destinations. Confirm the saved owner, associated tasks, notification contents and exception visibility. Keep these results separate from tests of an offline teaching example.

If the platform cannot support a proposed rule, decide openly whether to simplify the policy, add a supported control or retain manual review. Avoid labelling a nearby feature as equivalent when it changes the customer or staff experience.

Review routing problems without blaming the enquiry

A valid prospect can be mishandled after arrival. A perfectly assigned request can still be outside commercial fit. Keep those questions separate when reviewing the process.

Look at unassigned work, returned handoffs, repeated transfers and manual corrections. Group them by useful reasons. Missing location suggests an intake problem. An unavailable specialist suggests a coverage problem. Conflicting rules suggest a policy problem. Access failure suggests a permissions or configuration problem.

Review some apparently successful assignments, too. Was the recipient suitable? Did the account relationship survive? Did someone quietly move the enquiry later because the original route was wrong? A populated owner field can conceal poor assignment quality.

If you calculate an error rate, describe the sample. Three incorrect assignments among 30 reviewed records is evidence about those 30 records. It is not automatically the rate across every enquiry in the business. Counts and examples are often enough to identify the repair.

Consider staff experience alongside the customer journey. A rule can distribute new leads evenly while leaving specialists overloaded or repeatedly assigning work outside a person’s agreed role. Ask whether the chosen measure reflects the burden you intended to balance.

Discuss commission or territory disputes through the business’s approved management process. Keep the customer served while that decision is resolved. Silently moving ownership to settle an internal dispute can disrupt communication and make the record unreliable.

When changing rules, keep the previous version and effective date. That allows a manager to explain why yesterday’s enquiry went somewhere different from today’s. Introduce a significant change to a manageable queue and inspect the results before expanding it.

Use the matrix before the optional code

The lead-routing companion pack includes blank and example routing matrices, an owner roster and an offline simulator. Start with the CSV matrix as a discussion aid. It is an editable planning view, not a native CRM import file.

The simulator is optional educational code for a technical reviewer. Its JSON policy and roster control execution; changing a CSV alone does not change the simulator. The included notes explain how the review views and executable files correspond.

The preserved test pack contains 60 fictional routing cases and 20 configuration-rejection checks. Its existing local test report supports the example logic at the recorded test point. It does not establish that your CRM, permissions, notification system or staff workflow has been tested.

The example intentionally includes strict choices, such as holding an unavailable existing owner for supervisor review and using a deterministic tie-break. You can choose a different justified policy for your team. Change it explicitly, write the expected result and test the new behaviour rather than treating the example’s defaults as universal best practice.

No code is necessary to decide that French-language work needs an appropriate responder, that existing relationships deserve context or that a fallback requires an actual person. Those decisions should be settled before someone configures the automation.

Advanced implementation checks for the system owner

A production integration has failure modes that a written matrix cannot resolve on its own. The implementer should address them without making every salesperson learn the underlying machinery.

Repeated events need durable recognition. If the same submission is retried, the integration should find the prior assignment rather than allocate again. The companion’s supplied event list illustrates the decision but does not maintain a production event ledger or coordinate several running processes.

Simultaneous enquiries require care with capacity. Two workers can both read one remaining slot and propose the same owner. Use a supported transaction, reservation or serialized assignment process, then test concurrent arrivals. A local function returning the expected owner does not prove this protection exists.

Conflicting updates need a rule as well. If a supervisor changes the owner after an automation reads the record, the older automation should not quietly restore the previous state. Check the current record version or use an equivalent supported control before committing a change.

Separate assignment from notification recovery. If the owner change succeeded but the alert failed, retry the alert without assigning again. If a timeout leaves the outcome uncertain, inspect the actual record and event history before repeating a write.

A failed permission check may prevent both the intended assignment and the fallback write. Surface that as an operational failure through an authorized route. Do not report that the review queue received the enquiry unless the write actually succeeded.

Finally, reconcile source events with their outcomes. Each real enquiry should be explainable as assigned and accepted, awaiting controlled review, linked to an existing request or deliberately handled through another approved process. Replays should not inflate the count of new business.

A useful routing policy leaves the team with a simple, dependable answer: this person owns the next step, these conditions explain why, and this named fallback takes responsibility if the handoff cannot be completed.

Frequently asked questions

What does lead routing mean for a sales team?

Lead routing decides who takes responsibility for each new enquiry. It starts with the people able to handle the request, keeps a useful existing relationship where that helps, and then spreads work fairly within that group. A named fallback catches anything unmatched or unaccepted so it stays visible.

What are good practices for routing new sales leads?

Check eligibility first, such as territory, language or approved access, before any rotation picks a name. Choose the simplest combination of rules your team can explain and maintain while someone is on leave. Confirm that the assigned person actually accepted the enquiry instead of trusting the notification, and test uncomfortable exceptions as well as ordinary assignments.

How does queue-based lead routing differ from skill-based routing?

With a shared queue, enquiries wait for a coordinator or team member to review and assign them, which suits unusual requests that would need many brittle rules. Skill-based routing sends an enquiry straight to a pool with the needed knowledge or language, such as French-speaking staff. A queue only works with a named custodian and cover, while skill-based pools need a roster that stays current as people change roles.

What should I check before choosing lead routing software?

Confirm what the software actually balances before promising your team a particular order. A rotation feature may even out assignments over time without walking through a fixed list of names. Also check how it treats people who are away, how it handles existing account owners and whether it can send unmatched enquiries to a fallback someone actually works.

Is round robin a fair lead distribution rule?

Round robin suits a team with comparable skills, hours and enquiry types, and people find it easy to understand. Equal new assignments do not always mean equal workloads, though, since one person may already hold several open proposals or handle slower, complex work. Where those gaps matter, add a capacity limit or separate pools, and decide how the rotation treats someone on leave.

What does a lead routing example look like with language and territory rules?

In the post's fictional team, a French-language Ontario enquiry can only go to the two people who cover Ontario in English and French. A plain all-team rotation could have picked someone without French or someone serving British Columbia. Once the eligible pair is known, a rotation or workload measure can choose between them.

What belongs in a lead routing template or matrix?

A short routing matrix lists each type of enquiry, the eligible group, the method that picks a person inside that group and the fallback owner. It should also state which rule wins when two conflict, for example existing-account ownership against territory. Collect only the form information the matrix needs to route, and use the project location, not an area code, when territory matters.

What should a lead routing process do when the usual owner is away?

The relationship owner can stay on the account while someone else handles the new enquiry through an approved temporary handoff. If the record is restricted and the cover person lacks access, a duty manager should own the exception and arrange authorized cover. The request should never sit unattended because the preferred person is absent.