Who should get a lead the moment it arrives?

Who should get a lead the moment it arrives?

The person who can have a useful conversation about that specific enquiry, and who will actually follow up today. If nobody on your team meets both conditions, routing faster will not help you. It will just distribute the problem more efficiently.

Almost every request I get for lead routing is framed as a speed problem. The form submits, somebody eventually notices, and by then the enquiry has gone cold. Speed is genuinely part of it, but it is the easy part, and fixing it first is why so many routing setups get switched off.

What follows is how I actually think about the design, in the order the decisions have to be made.

Why is speed the wrong first question?

Because a fast handoff to the wrong person is slower than a slow handoff to the right one. If the enquiry lands with someone who has to forward it, you have added a hop and lost the context the form captured.

The version I see most often is a rule that assigns everything to whoever is next in a list. It looks fair, it is trivially easy to build, and it guarantees that some proportion of your enquiries start with a person who cannot answer the first question they will be asked.

Fit first, then speed. Once you know who should get a given enquiry, making that assignment instant is a small technical problem. Getting the assignment right is a business problem, and it cannot be solved by a faster trigger.

What does a routing rule actually need to know?

Three things about the enquiry and two things about your team. About the enquiry: what they are asking for, what kind of organisation they are, and whether they are already known to you. About the team: who is competent for that combination, and who is available.

That last one is where most rules are silently wrong. A routing rule that does not know about availability will happily assign a lead to someone on leave, and nothing in the system will notice. The lead sits assigned and unworked, which is worse than unassigned, because unassigned at least looks like a problem.

The "already known to you" check matters more than people expect. An existing customer filling in a contact form should not enter the same queue as a stranger, and an enquiry from a company you are already in a deal with should go to whoever owns that deal. Getting this one wrong is how you end up with two people emailing the same buyer.

Should you route by round robin or by fit?

Route by fit, and use round robin only to break ties inside a group that is equally capable. Round robin as the primary rule is an admission that you have not decided what your segments are.

There is a legitimate case for round robin, which is fairness when compensation depends on lead volume. That is a real constraint and I am not going to pretend it away. The resolution is to define capable groups first, then rotate within them, so fairness operates inside competence rather than instead of it.

Where round robin genuinely breaks down is with any enquiry that needs a specific answer. Pricing questions about an unusual deployment, or anything regulated, or anything technical enough that a wrong answer creates work. Those should be routed by capability every time, and everyone on the team already knows which category their enquiries fall into. The same reasoning applies one step later, when you decide who should own the demo.

What happens when the assigned owner does nothing?

Nothing, unless you built for it. This is the single most common gap in lead routing, and it is the one that quietly wastes the most money, because the enquiry looks handled in every report you run.

Every routing rule needs an escalation path with a clock on it. If the assigned owner has not touched the record within a defined window, reassign it or alert someone. The exact window matters much less than having one at all.

The escalation also needs a named recipient rather than a shared inbox, because a shared inbox is where accountability goes to die. This is the same principle that applies to failure alerts generally, which I have written about in who gets the alert when an automation fails overnight.

What does routing cost to run?

More than you think, because routing is rarely one action. Zapier's own documentation is a useful reference point here. It defines a task as any successful action that runs in Zapier, and says that in Zapier Lead Router each successful lead routed counts as five tasks.

That is a reasonable price for the work, and it is also a number worth doing arithmetic with before you commit. A routing rule that also enriches, writes to a CRM, posts to a channel and sets a reminder is several actions per lead, and at volume that becomes a real line item. Check the current rates on the vendor's own documentation, because they change.

The cost calculation also changes the design. If each lead is expensive to route, you stop routing things that do not need routing. Newsletter signups do not need a rule with five steps. Reserving the machinery for enquiries that could become revenue is both cheaper and clearer.

Which fields should routing be allowed to write?

Assignment, timestamp, source and a routing reason. That is close to the whole list. Anything that represents a human judgement about the deal should stay out of an automated write.

The routing reason field is the one people skip and then regret. One short string saying why this lead went to this person turns an opaque system into a debuggable one. Without it, every question about why a lead was misrouted becomes an archaeology exercise.

The wider principle is that automations should be conservative about what they touch in a CRM, because overwritten context is unrecoverable. I have gone through where I draw that line in which CRM fields an automation should never write.

How do you test a routing rule before it touches real leads?

Run it against last month's enquiries and read the assignments. You already have the perfect test set, and nobody gets misrouted while you are learning what the rule does.

Take fifty recent enquiries, run them through the logic on paper or in a spreadsheet, and compare the output with who actually ended up handling each one. Where the rule disagrees with reality, one of the two is wrong, and finding out which is the entire value of the exercise.

This is also where you discover the cases you did not think about. Enquiries with no company name. Enquiries from a country you do not serve. Enquiries that are obviously spam. Those become explicit branches instead of silent failures.

When should a human do the routing?

When the volume is low enough that a person can triage everything in a few minutes a day, or when the segments are still being invented. Both of those situations are more common than people admit, particularly at early stage companies.

A founder reading every enquiry for a few months is not a failure of process. It is how the routing rules get written, because the exceptions reveal themselves in a way no upfront design session produces. Automate after the pattern is visible, not before.

The automations I have built that lasted all followed that order. For Kismet Health the CRM path into HubSpot through Zapier worked because the process it encoded was already settled. Encoding an unsettled process just makes the churn more expensive.

What should you do next?

Pull your last fifty enquiries and, for each one, write down who should ideally have handled it and who actually did. If those columns match, you do not have a routing problem. If they do not, the pattern in the mismatches is your specification.

Then, before you build anything, decide what happens when the assigned person does nothing for a day. That single decision will do more for your pipeline than any improvement in assignment speed, because unworked leads cost the same as leads you never received.

If you want a second opinion on a routing design before you wire it up, reach out. It is much cheaper to argue about the rules on paper than to unpick a month of misrouted enquiries.