A demo request sat unassigned over a weekend and went to a competitor on Monday. Here is the model behind a routing app, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A lead routing app is four parts: rules expressed in a readable order, a fallback that guarantees no lead ever lands unowned, speed measured from arrival to first contact, and an audit of why each lead went where it did. The rule that matters most is the fallback. Every routing system has cases its rules did not anticipate, and the difference between a good one and a bad one is whether those go to a named person or into a pool nobody checks on a Friday afternoon.
Lead routing
8 sec
Median to assignment
46 min
Median to first contact
3
Unactioned over 2h
4%
Went to fallback
| Lead | Matched rule | Assigned to | To contact | Note |
|---|---|---|---|---|
| Halden Foods, demo | Open opportunity | R. Iyer | 6 min | |
| Vantor, pricing | Named account | T. Okafor | 22 min | |
| Kestrel, trial | EMEA mid-market | M. Sandoval | 1h 40m | Deputy, on leave |
| Brightsea, content | Fallback | S. Roche | 3h 12m | No rule matched |
| Northrise, support | Existing customer | A. Mensah | 11 min |
You run marketing operations or revenue operations. You already have routing rules somewhere. What you want is rules a person can read, nothing landing unowned, and a number for how fast the first contact actually happens.
What happens to a lead in the first few minutes, and what you learn from it afterwards.
Email domain against existing accounts and open opportunities first, because an inbound from a live deal is not a new lead.
Named accounts, existing customers, open opportunities, then territory, segment and product interest.
Out of office, over capacity, on leave. A perfect rule that assigns to somebody on holiday is a lost lead with extra steps.
Never a pool. The fallback is the rule that separates a good router from an expensive one.
Time to assignment should be seconds. Time to first contact is what correlates with conversion.
Which fired, which never fire, and how often the fallback caught something, which is the rule you are missing.
A routing app is not a set of CRM assignment rules. It is four parts, and the second is the one that prevents the expensive failure.
Ordered conditions over what the lead is: territory, segment, product interest, named account, source. First match wins, and the order is visible rather than buried.
A named person who receives anything the rules did not anticipate. Never a pool, never a shared inbox, never nobody.
Time from arrival to assignment, and separately to first contact. The second is the one that correlates with conversion and the one nobody measures.
Which rule fired, what the lead looked like at that moment, and who it went to. Routing disputes happen weekly and are unanswerable without it.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Ordered, first match wins, and visible to the people they affect.
In this Helix project, build me a lead routing app.
A lead arrives with: name, email, company, job title, country, company
size if we know it, the source, what they asked for, and any campaign or
form reference.
Enrich it where I can supply a source: match the email domain to an
existing account or open opportunity first, because an inbound from a live
deal should never be treated as a new lead.
Then rules, as an ordered list I can read top to bottom. Each rule has
conditions over the lead's attributes and a destination, and the first
match wins. Show me the order and let me reorder it.
Seed with the ones every company needs: named accounts go to their owner,
existing customers go to their success manager, anything matching an open
opportunity goes to that rep, then territory and segment rules, then
product interest.
Let me test a rule set against a batch of past leads and show me where
each one would have gone before I turn anything on.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Testing against historical leads before switching over is the step that catches the rule that would have sent every UK enterprise lead to a departed rep.
The fallback, which is the rule that actually matters.
Now the part that prevents the expensive failure.
Require a fallback destination: a named person who receives anything the
rules did not anticipate. Not a pool, not a shared inbox, not a queue
somebody checks on Mondays. Every routing system has cases its rules did
not foresee, and the difference between a good one and a bad one is
whether those reach a person.
Then handle availability. Before assigning, check whether the destination
is out of office, over a capacity limit I set, or has leave booked. If
they are unavailable, route to their named deputy and record that this is
what happened. A perfect rule that assigns a hot inbound to somebody on
holiday is a lost lead with extra steps.
Support round-robin inside a rule, but only inside one. Round-robin as the
top-level strategy sends an enterprise inbound to whoever happens to be
next, which is fair to the reps and expensive for the company.
Alert on anything unassigned for more than a few minutes. That should
never happen, and when it does it is the most urgent thing in the app.Because those are different and only one of them matters.
Track two clocks and keep them separate.
Time from arrival to assignment, which should be seconds. And time from
arrival to first contact, which is the one that correlates with
conversion and the one almost nobody measures.
A lead assigned in four seconds and contacted in two days was not routed
well. It was assigned well, which is not the same thing.
Show each rep their unactioned leads ordered by age, and escalate anything
past a threshold I set to their manager. Then reassign, with the reason
recorded, if it goes past a second threshold.
Report median and worst-case time to first contact by rep, by source and
by segment. Include an out-of-hours breakdown, because the weekend gap is
usually where the worst numbers hide and an aggregate median conceals it
completely.The audit, and what it tells you about your rules.
Log every routing decision: the lead as it looked at that moment, which rule
matched, which rules were evaluated and skipped, the destination, whether
a fallback or deputy was used, and the timestamp.
Routing disputes happen weekly. "Why did I not get that lead" is
unanswerable without this, and answerable in ten seconds with it.
Then report on the rules themselves. Which rules fire most, which have
never fired at all, and how often the fallback is used. A fallback firing
frequently is not a fallback doing its job, it is a rule set with a gap in
it, and the leads it caught are the specification for the rule you are
missing.
And report leads by source against opportunities created, so the routing
data doubles as a source quality report you did not have to build
separately.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Salesforce>. Match an inbound against existing accounts and open
opportunities, then write the assignment.
<Okta>. Read the current sales roster and its groups, so a rule never
assigns to somebody who has left or is not on that team.
<your website forms>. Take the inbound the moment it arrives, because time
to first contact is the metric.
<Slack>. Tell the rep they have a lead, and escalate anything unactioned
to their manager.
<Marketo>. Read form fills and enrichment before routing, so the rules
have something to match on.
<Outreach>. Put the lead into a sequence the moment it is assigned, which
is what time to first contact measures.
<Snowflake>. Read historical routing outcomes, so a rule set can be tested
before it is switched on.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This handles inbound personal data and decides who gets paid on a deal, so set Access Control before sharing.
Routing is a read against your pipeline and a write of an assignment, and both have to be fast.
Salesforce
Match an inbound against existing accounts and open opportunities, then write the assignment.
Okta
Read the current sales roster and its groups, so a rule never assigns to somebody who has left or is not on that team.
Your website forms
Take the inbound the moment it arrives, because time to first contact is the metric.
Slack
Tell the rep they have a lead, and escalate anything unactioned to their manager.
Marketo
Read form fills and enrichment before routing, so the rules have something to match on.
Outreach
Put the lead into a sequence the moment it is assigned, which is what time to first contact measures.
Snowflake
Read historical routing outcomes, so a rule set can be tested before it is switched on.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working router. It handles inbound personal data and effectively decides who works which deal, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Routing decides who works which deal, so the audit is only useful if every rule change is attributable. SSO means people sign in with their existing account, and access is scoped so reps see their own leads.
App Security
Matching against accounts and open opportunities, and writing assignments back, needs real CRM access. Granting it to the app rather than pasting a key into it means it can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It applies ordered rules to inbound leads, assigns each one to a named person within seconds, falls back to a named person for anything the rules did not anticipate, and records why every lead went where it did.
The fallback. Every rule set has cases it did not foresee, and the difference between a good router and a bad one is whether those reach a named person or a pool nobody checks on a Friday afternoon.
Only inside a rule, never as the top-level strategy. Round-robin over everything sends an enterprise inbound to whoever happens to be next, which is fair to the reps and expensive for the company.
Time from arrival to first contact, not to assignment. A lead assigned in four seconds and contacted two days later was assigned well and routed badly, and only the aggregate hides the difference.
Because "why did I not get that lead" comes up weekly and is unanswerable without it. The same log tells you which rules never fire and how often the fallback catches something, which is the specification for the rule you are missing.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build, including testing a rule set against historical leads before switching it on. The judgement calls are the rule order and the fallback.
Sales and RevOps
Find the opportunities distorting your forecast, name who owns each fix, and make hygiene a short weekly list rather than a quarterly clean-up. Prompts to build it, and what it takes to run it.
Sales and RevOps
Split accounts into territories, load quota against them, and see the coverage and fairness of a plan before you commit to it. Prompts to build it, and what it takes to run it.
Marketing
Capture enough in a brief to start work without a meeting, prioritise against capacity rather than volume, and show requesters where their work sits. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.