← All writing

Lead AI Works Only When Routing Rules Are Clear

Make lead AI useful with clear routing rules, named owners and exception handling. Build a process that protects agency delivery time and margin.

A routing packet with client and inquiry cards sits on a table, with a burnt orange tab marking the first ownership decision.

Your agency can have lead AI reading every inquiry and still leave the founder deciding who should handle it. An existing client asks about another service, a referral arrives without a brief and two people assume the other owns the reply. Those unresolved decisions become internal work before any billable delivery starts.

Separate interpretation from assignment

Start with your agency’s own new-business inbox, contact forms and referral messages. The useful question is whether the system can interpret an inquiry well enough to apply a routing policy your team has already agreed on.

A model can extract the requested service, summarize a free-text message and flag missing information. Your routing rules should determine whether those extracted facts are sufficient to assign an owner.

Keep verified information separate from interpretation. An account owner stored in the CRM is different from a model’s guess that a sender belongs to an existing client. A request for a proposal is different from an approved commitment to prepare one.

This depends on clean, authorized inputs: the original message, permitted CRM records and current service definitions. Give the model access only to the information needed for its task.

The first artifact to create is a routing policy with named owners, an order of precedence and explicit conditions for human review.

Give lead AI a fixed order for conflicting rules

Most routing policies look reasonable until two rules match the same inquiry.

Suppose a current SEO client asks about paid media. The existing-account rule points to the account lead. The service rule points to the paid media lead. Without a priority order, someone still has to negotiate ownership in Slack.

A starting policy could look like this. Adapt the roles to your agency rather than copying them unchanged.

PriorityConditionInitial ownerRequired action
1Identity or access permissions are unresolvedNamed intake reviewerVerify before sharing account context
2Sender is a verified existing clientCurrent account leadClarify the request and involve delivery before committing work
3Inquiry matches an existing open conversationCurrent conversation ownerAttach the message to that record
4New inquiry matches a defined serviceAssigned service intake ownerReview fit and confirm the next action
5No rule produces a valid assignmentException queue ownerResolve the missing fact or policy gap

Run the policy from top to bottom and stop at the first applicable rule, unless a documented exception says otherwise.

Routing someone to an account lead does not authorize that person to promise a turnaround, add scope or start production. Those decisions need their own approval rules.

Make ownership visible in the handoff record

A lead AI workflow should create an assignment record with enough context for the recipient to act. A notification that says “new inquiry” leaves the recipient doing the interpretation again.

Keep the handoff compact: the original message, verified account match, request summary, assigned owner, rule used and next action. Include any uncertainty that could change the decision.

Define when ownership transfers. For example, the intake owner remains responsible until the receiving person accepts the assignment in the CRM. A notification alone does not establish that someone has seen or accepted the work.

Also define how an assignment can be returned. “Wrong person” is too vague to improve the system. Useful return reasons include incorrect account match, service outside scope, owner unavailable and missing information.

For an inquiry containing multiple requests, keep one accountable intake owner and create linked tasks where necessary. Otherwise, a question about a new retainer and an existing reporting issue can bounce between teams while neither gets answered.

A rule-based fallback should cover absences and unaccepted assignments. Set its timing around your actual coverage hours rather than assuming someone monitors the inbox continuously.

Keep uncertainty in an owned exception queue

An exception queue needs a person responsible for clearing it and a next-review deadline on each item.

Separate missing information from conflicting information. A message without a requested service may need a clarification. A message claiming to come from a current client, but using an unfamiliar address, needs verification before client records are exposed.

Use model output to identify the unresolved question. Do not treat a model saying it is confident as proof that the account match or assignment is correct.

Some decisions should remain outside automatic routing altogether. Requests involving contract terms, unpriced discovery work or commitments beyond an existing retainer need the appropriate commercial or delivery owner.

For lead AI, a useful boundary is whether an error can be reversed without exposing information or committing agency time. Low-risk categorization can have a different review path from a decision that triggers work. Define those boundaries through explicit human-review responsibilities.

Repeated exceptions are evidence that the policy needs attention. If every referral from a partner requires the founder to intervene, document the decision the founder keeps making.

An agency operations lead reviews a routing policy beside anonymized inquiry cards, with request type, assigned owner, routing reason, and review status laid out on the table.

Test rule collisions before enabling live assignment

Build a small test set from past inquiries, using only records you are authorized to process. Remove unnecessary personal and client information.

Include the awkward cases: an existing client requesting a new service, a duplicate inquiry through another channel, an unavailable owner, a referral with no brief and a message containing both a support request and a commercial question.

For each case, write the expected owner, permitted next action and reason before running the system. That gives you something concrete to compare against the output.

Test lead AI in shadow mode first. Let it propose assignments while your team continues using the current process. Record disagreements without automatically treating either the model or the existing manual decision as correct. Compare both against the written policy.

Check whether the request summary preserves uncertainty. “Interested in discussing a website refresh” should not become “ready to buy a website.” That change can send an inquiry down the wrong path even when the assigned owner looks plausible.

Enable live assignment only for the cases your policy covers. Keep the rest under review, with a way to pause automatic assignment without interrupting intake.

Track correction work alongside the software bill

A routing system can move messages quickly while creating extra work elsewhere. The delivery lead needs to see what happens after assignment.

Track how often assignments are returned, how long exceptions remain unresolved and how much staff time goes into correcting records. Record any work started before scope approval. These measures expose costs that a simple response-time report misses.

Whether financial review happens in-house or through a part-time CFO service such as CFOLab, the assessment needs both software costs and the staff time spent fixing assignments. Faster routing has limited value if senior people spend their afternoons untangling it.

Give changes to lead AI routing the same discipline as other operating changes. Record which rule changed, who approved it, when it took effect and which test cases were rerun.

Keep the extracted facts and routing decision traceable to the applicable rule version. That makes it possible to distinguish a model’s reading error from an outdated CRM owner or a policy that never covered the situation.

Review recurring correction reasons before adding more automation. Changing tools will not settle an unresolved disagreement about who owns a request.

Frequently asked questions

Can lead AI route inquiries without human approval? It can propose classifications that trigger rule-based assignment when the required information is verified and the action stays within agreed permissions. Ambiguous identity, conflicting ownership and commitments of agency time should follow a defined review path.

Should every inquiry go to the person with the most availability? Availability can be a routing condition, but it should not override account continuity, access permissions or the authority to approve work. Use capacity-based assignment only among people who are eligible to own the request.

Do we need a new CRM before fixing routing? Start by checking whether your current system can store ownership, next actions, exception status and decision history. Write the policy and test it against past inquiries before deciding whether software limitations require a change.

This week, test one source against a written policy

Choose one inquiry source and review its last 20 messages. Write the owner and permitted next action for each, then identify where two rules compete or no rule applies. Have the people receiving those assignments agree on the priority order before automating it.

At Archer Scaling AI, I install and run AI ops systems for marketing agencies. If you want to talk through the ownership gaps and internal work in your current process, book a free 30-minute intro call. The conversation is about your operations, with no sales pitch.

Let’s find the delivery margin you’re leaving on the table.

Book your free intro call. Thirty minutes to walk me through your ops and find out where the margin is leaking.