Lead routing upstream of your CRM · agent-native
Every lead onto the right track
shunt /ʃʌnt/ · verb To move a rail car from one track to the track it needs. Shuntline does it for leads.
Shuntline takes in every lead your group receives, in whatever JSON shape the sender uses, from a web form or an AI agent. It records what was missing, routes each lead by rules your team edits, and hands it to the partner, CRM or agent-assisted team that turns it into business. Leads are JSON, the language agents already speak, so agents plug in at the door and at every exit over MCP.
The CRM carries the plumbing
In most enterprise CRMs, Salesforce included, the lead object is one of the most customised in the estate. Yet few people actually work leads there. Most of a lead's life is receiving, checking, routing and handing off, between systems. Shuntline moves that work out of the CRM.
Every new channel is a project
A new form, partner or event means new fields, layouts and a release before the first lead can land.
- fields per channel and partner
- record types per business line
- staging objects for imports
Routing hides in triggers
Assignment rules, flows and code fire on every insert. Nobody can say in one sentence why a lead went where it went.
- assignment rules and queues
- flows and triggers on insert
- integration users
Licences for systems talking to systems
Partners, dealers and reporting users need access to leads, not to a CRM. Each one is still a seat, a profile and a permission set.
- partner and community seats
- read-only reporting users
- middleware field mappings
Salesforce stays the destination
Salesforce, or any other CRM, is where your sellers and service teams engage with customers. Lead dispatching is a different job: taking in many senders, each with its own data model, and passing their leads on. That job does not need a CRM. Shuntline takes it out of the org, and Salesforce receives the final business object, an opportunity or a case, never the intermediate lead.
People working customers
Accounts, contacts, opportunities, cases, activities. A stable model that sellers, managers and service teams use every day.
- one model, governed by your CRM team
- licensed per user who works in it
- changes go through a release cycle
Systems passing leads on
Web forms, partner feeds, event exports and campaigns, each sending its own fields. Most of the work is checking and routing, with no person involved.
- as many data models as there are senders
- new senders every month, no release needed
- partners and dealers served without CRM seats
- AI agents served over MCP, without seats either
No intermediate object
The lead stage happens before the org: no fields, record types, staging objects or conversion logic per sender. Assignment rules and insert triggers for dispatching come out too.
One door into Salesforce
Instead of one integration per sender, a single flow maps each folder to an opportunity or a case, once. New senders connect to Shuntline, not to the org.
Bulk traffic stops upstream
Retried deliveries, duplicates and incomplete payloads are handled before Salesforce sees them. Fewer API calls, less storage, no automation firing on leads nobody will work.
Easy to route elsewhere
Dealers, partners, marketing tools and AI agents take their leads straight from a folder. No Experience Cloud licence or extra integration user each.
Agents speak JSON. So does every lead.
A lead in Shuntline is the JSON object the sender posted, kept exactly as sent. That is the native language of AI agents: they read it, reason on it and write back with no mapping layer, no SDK and no CRM seat. Connecting an agent is a token or an MCP scope, not an integration project.
Agents send leads
An agent that qualifies a chat, a call or an inbox posts its lead to the intake API like any other sender, with its own source token. Whatever fields it extracted are stored as sent and routed by the same rules.
Agents work the gaps
Leads flagged at the door, or left without a matching rule, are exposed to agents over MCP. An agent completes what was missing, enriches it or settles where it goes. Each change is a new version; the original stays frozen.
Agents work a folder
A team exposes its folder to its own agents, scoped per purpose: follow-ups, qualification, enrichment. Agents work leads from Claude or any MCP client, without a CRM seat or an export job.
# what the agent posts { "email": "j.martin@example.com", "intent": "fleet quote, 12 vans", "channel": "chat" }
Same JSON, no mapping
# what an agent reads over MCP { "payload": { "email": "j.martin@…", … }, "flags": ["no_phone"], "folder": "fleet-sales" }
How a lead travels
Five steps, and each one stays inspectable afterwards. Shuntline is the part of the chain that remembers.
- 01 · ARRIVE
It arrives
Through the API or as a row in an uploaded CSV. The payload is stored before anything reads it.
- 02 · CHECK
It gets checked
Flags record what was missing: no phone, no postal code, no consent. A person or an agent over MCP can complete it; the original stays as sent.
- 03 · FILE
It gets filed
Rules are read in order and the first match picks a folder. When no rule matches, the lead waits for a person or an agent to decide.
- 04 · LEAVE
It leaves
The consumer collects the folder on its own schedule, or the folder pushes each lead to a webhook.
- 05 · KEEP
It stays on record
Original payload, flags, folder and the rule that decided, frozen as they were. Corrections are new versions.
API in, API out, MCP for agents
No schema to declare. A lead is a JSON object in the sender's own shape, the same language AI agents read and write, so onboarding a sender or an agent means issuing a token. Every door has its own credential and can reach nothing else.
Intake API
One endpoint, one bearer token per source. Nested objects and undeclared fields are stored as sent. Retries are safe: a repeat of the sender's own id returns the original lead. Any agent with an HTTP tool posts the same way.
CSV import
Trade-show scans and partner exports become leads attributed to a source, checked and routed exactly like API traffic.
Folder collection
An ETL claims the next batch with a folder token and acknowledges what it took. A consumer that dies mid-batch gets its leads served again.
Webhooks
A folder can push each lead to an HTTPS endpoint, with an optional field mapping that renames and reduces the payload. Values are never rewritten.
MCP server
Expose flagged and unmatched leads, or a whole folder, to AI agents with access scoped per purpose. Agents complete, triage and act on leads from Claude or any MCP client, without a CRM seat each.
Built for a group, not a team
Shuntline is delivered as software you own and run, with the controls a security review asks for. One database serves every brand, country and channel, and each keeps its own rules.
OIDC across the board
Sign-in goes through your identity provider. No passwords and no user table here: people, teams and admin rights come from your directory, and revoking access happens once, centrally.
Source code included
You receive the codebase. Fork it, adapt it, test it and deploy it on your release cycle. No per-seat pricing and no vendor between you and a change you need.
Direct database access
Every lead is kept in PostgreSQL, encrypted at rest, with a documented schema and JSONB payloads. It grows with your cloud instance, and your BI tools query it directly: no export jobs, no rate limits, nothing that stops you leaving.
Nothing is overwritten
The original payload is frozen at arrival. Corrections are new versions, every rule change is versioned, and each routing decision keeps the rule as it read at the time.
Teams and least privilege
Every source and folder belongs to a team. Source tokens can only post, folder tokens can only collect their own folder, MCP scopes reach only what an agent's purpose needs, and all are rate-limited and revocable one by one.
One database, every specific
Each country, brand or channel gets its own flags, rules and folders. Adding one never forks the schema or touches another team's routing.
Your cloud, your region
Shuntline runs in your own cloud account, next to the data it serves. Pick the provider and region your policies require. Each deployment upgrades on its own schedule.
What it will not do
A short list of boundaries keeps Shuntline simple to run and easy to trust.
Impose a schema
Senders send the fields they have, in their own shape. Nothing has to be declared before the first lead arrives.
Rewrite what was sent
Mappings rename and drop fields on the way out. They never convert or invent values the sender did not provide.
Replace your ETL
Leads leave by collection or webhook. Your integration platform turns them into opportunities or cases in the CRM, and carries them anywhere else.
Route your own leads in a demo
Bring a few real payloads. We will run them through intake, flags and rules live, and show where each one would land.
- A working session with the team that builds it
- Your payloads, routed with the dry-run endpoint
- Architecture, security and hosting questions answered