On this page
- What sales pipeline automation actually is
- Who this is for, and who it is not for
- What we actually build
- How it works technically
- The five kinds of CRM field
- The build process, stage by stage
- What you get at handover
- Where these projects go wrong
- What it costs to run once it is live
- How to tell whether you need this
- How to start
What sales pipeline automation actually is
Sales pipeline automation is the layer between your lead sources and your CRM that resolves identity, enriches records, routes ownership, runs follow-up and keeps the data honest. It handles the typing, the lookups and the chasing that surround selling. A model has one job in it, extraction, turning calls and emails into structured facts with evidence attached, while the scoring and the routing stay in code a rep can read and argue with.
The reason to build it as one layer rather than five automations is that all five write to the same records. Enrichment writes a company size, a rep corrects it, a form overwrites it that night, and by the end of a quarter nobody trusts the field. Deciding once, in one place, which source wins for each field is most of the work and almost all of the durability.
It is also the least glamorous kind of AI project. Most of it is identity resolution, rate limits and precedence rules. The model contribution is real but narrow, and any proposal that leads with the model is selling you the small part.
- Domain is the keyAccount identity is the registered domain, never the company name a human typed. Name matching is how you get three records for one customer.
- Code scoresA model turns correspondence into structured fields with quotes as evidence. The score is arithmetic in code, visible to the rep it affects.
- One writer per fieldEvery field needs one authoritative source and a written precedence rule. Two writers and no rule is wrong within a quarter.
- A default branchEvery routing rule set needs a fallback owner. Unassigned records are where pipeline quietly leaks, and nobody reports them.
- Cold gets its own domainSending reputation is shared. Cold sequences on the domain that carries your invoices is a mistake that takes months to undo.
- Identity resolution
- Deciding whether two records describe the same person or company. Person keys on the normalised email address, account keys on the registered domain, and everything else is a guess with consequences.
- Enrichment waterfall
- Trying vendors in order until one returns a usable result, caching what comes back, and never paying twice for the same domain inside a defined window.
- Write-back precedence
- The written rule saying which source wins when two of them want to set the same field, and what happens to the value that loses.
- Stage exit criteria
- The conditions a deal must satisfy to leave a pipeline stage, enforced at the gate. Without them a stage name is a mood rather than a fact.
- Recycle
- Returning a lead to nurture with a recorded reason and a date, instead of leaving it in a stage where it ages quietly and inflates the forecast.
Who this is for, and who it is not for
This pays back when volume has outgrown attention: enough inbound that routing matters, enough accounts that duplicates appear, enough calls that nobody writes them up properly. Below that, a small team with a tidy CRM and a shared discipline beats any system we would build.
| What is true of your pipeline | Verdict | Reasoning |
|---|---|---|
| Reps spend real hours on data entry and lookups | Good fit | That work is deterministic and it is the part they resent most |
| Leads sit unassigned or land with the wrong owner | Good fit | Routing is rules plus a default branch, and the payback is immediate |
| The same company exists three times in the CRM | Good fit | Identity resolution on the domain, plus a merge review queue, fixes it properly |
| Two or three reps, tens of deals, a clean CRM | Poor fit | Discipline is cheaper than a build at this size. Revisit at volume |
| Nobody agrees what the stages mean | Fix that first | Automation enforces stage gates. Undefined stages produce enforced nonsense |
| Leadership wants the system to decide who is a good lead | Careful | Score in code from extracted facts. An opaque score gets ignored by the people it is for |
- Your CRM is already untrusted. Automating on top of bad data produces confident bad data. The field audit comes first and it is not optional.
- You want more outbound volume, not better handling. That is a different project with a different risk, mostly about deliverability rather than software.
- The team is compensated in a way that fights the system. If a rep loses a lead by letting the system route it, the system loses.
- Nobody will own the rules. Routing rules and precedence rules change with territory, headcount and product. Unowned, they drift into fiction inside two quarters.
The first deliverable on most of these engagements is a field-level audit of the CRM, and it is frequently uncomfortable reading. Fields nobody has written to in a year, three fields holding the same idea, and a required field that reps fill with a full stop to get past the gate. Fixing that is cheaper than automating around it, and it is often where the actual return sits.
What we actually build
Five components. The identity layer decides how well the other four age.
Intake and identity resolution
Forms, chat, calls, product signups and list imports all land in one normalising path. Email addresses are lowercased and stripped of tags, free mail domains are flagged rather than treated as companies, and the account key is the registered domain with subdomains collapsed. Probable duplicates go to a merge review queue rather than being merged automatically, because merges are destructive and hard to reverse.
Enrichment
A vendor waterfall with caching: try the first source, fall through on a miss, store the result with the vendor name and the fetch date, and never call twice for the same domain inside a defined window. A cheap pre-filter decides what is worth enriching at all, because paying to enrich obvious junk is how these bills get surprising. Enriched values land in shadow fields and are promoted under a confidence rule.
Routing
Rules reading territory, segment, existing ownership and current capacity, in that order, with a default branch that always assigns somebody. A new lead at an account that already has an owner goes to that owner, not into the round robin, which is the rule most systems forget. Every routing decision is logged with the rule that fired, so a disputed assignment is a lookup rather than an argument.
Extraction and write-back
Call transcripts and email threads become structured qualification records with a verbatim quote behind every field. Those records write into the CRM under the precedence rules, alongside the existing CRM integration work. Scoring runs afterwards in code from the extracted fields, so a rep can see the arithmetic. If you want the scoring layer built as its own product, that is lead qualification agents.
Follow-up and hygiene
Sequences with real stop conditions on reply, meeting booked, unsubscribe and bounce, evaluated on the event rather than a nightly poll. Alongside them a hygiene job: stale deal detection, close dates in the past, missing next steps, stage gates, and a nightly reconciliation that reports drift between the source of truth and the CRM instead of silently fixing it.
- A written provenance and precedence map covering every field the system touches
- Identity resolution on domain and normalised email, with a merge review queue
- A cached enrichment waterfall with per-vendor spend visible
- Routing rules in version control, with a default branch and logged decisions
- A nightly reconciliation report of drift between systems, sent to a person
How it works technically
The inbound path is the one worth walking, because every decision in it is reversible only if it was logged.
The form or product event lands on a queue, not straight into the CRM. Queueing first is what lets you replay a day when a downstream system was down.
Normalise the email, derive the account domain, look for an existing person and an existing account. Ambiguity produces a candidate match for review rather than a merge.
Cache checked first, then the vendor waterfall on a miss. Results land in shadow fields with vendor and date, never overwriting anything the buyer told you directly.
Existing owner wins, then territory, then capacity-aware round robin, then the default branch. The decision is written with the rule identifier that produced it.
The owner gets a short brief: what the buyer said, what enrichment added, prior touches, and the extracted quotes. This is the piece reps actually notice.
If the owner has not acted inside the window, the system escalates to a fallback rather than letting the record sit. Speed here is a process choice, not a model capability.
Follow-up runs with event-driven stop conditions. At the end the record recycles to nurture with a recorded reason and a date, or it is disqualified with one.
The parts that break at volume
Three things: rate limits, ordering and recursion. CRM APIs meter you, so writes are batched and backed off, which is covered properly in rate limits, retries and backoff. Webhooks arrive out of order, so every write carries the source timestamp and a stale update is dropped rather than applied, otherwise a deal moves backwards on its own. And a workflow that writes a field which triggers a workflow that writes a field will find your API ceiling overnight, so every write is tagged with its origin and origin-tagged writes do not retrigger. If you are choosing between event and poll for intake, webhooks vs polling covers the trade.
SYSTEM
You extract a qualification record from sales correspondence. You never score,
never rank and never guess. Every field you fill must be supported by a verbatim
quote from the source, returned alongside it.
Hard rules
1. If a field is not stated in the source, return null and leave its evidence
array empty. An absent field is a correct answer.
2. Never convert a hint into a value. "We are growing fast" is not a headcount.
3. Quotes are verbatim, trimmed, and at most 200 characters each.
4. Currency values keep the currency the buyer used. Do not convert anything.
5. Return the JSON object only, with no commentary around it.
{
"company_stated_size": {"value": null, "evidence": []},
"budget_stated": {"value": null, "currency": null, "evidence": []},
"timeline_stated": {"value": null, "basis": "explicit|inferred|null",
"evidence": []},
"problem_stated": {"value": null, "evidence": []},
"incumbent_tool": {"value": null, "evidence": []},
"decision_process": {"value": null, "evidence": []},
"requested_next_step": {"value": null, "evidence": []},
"blockers": [{"value": null, "evidence": []}],
"disqualifiers": {
"out_of_geography": false,
"regulated_use_we_decline": false,
"needs_feature_we_do_not_have": false,
"evidence": []
},
"extraction_confidence": 0.0,
"prompt_version": "qual-extract-v4",
"source_ids": []
}
Scoring happens after this step, in code a rep can read, using only the fields
above. The model does not decide who is a good lead.The evidence array is the whole point of that schema. A field without a quote is not a field, it is an impression, and impressions are what make reps distrust a system. It also makes the extraction testable: you can check whether the quote actually says what the value claims, which is a far stronger evaluation than asking a second model whether the answer looks right.
The five kinds of CRM field
Before any automation writes anything, label every field it will touch. This exercise takes a day and it prevents the slow corruption that kills these systems in year two.
The ChatGPTalker CRM Provenance Grid
Every field belongs to exactly one of five provenance classes, and each class has exactly one write rule.
Recorded from a system event: an email sent, a meeting held, a trial started. The system writes it and humans never edit it. Treat it as immutable history, because it is the only class you can audit against.
The buyer told you: budget, timeline, headcount, incumbent tool. Written with a source and a timestamp, replaced only by a newer assertion from the buyer, and never by a vendor guess.
Computed from other fields: score, stage age, fit. Never hand-editable, recomputed on a schedule. If a human needs to override it, the override is a separate field with its own name and author.
The rep's opinion: confidence, next step, why it will close. Humans only. Automation may prompt for it and may flag it as missing, and it may never fill it in.
Bought from a vendor. Written to shadow fields carrying vendor name and fetch date, promoted into the main field only under a confidence rule, and never permitted to overwrite an Asserted value.
Then write the precedence order down, in the repository, beside the code that does the writing. Asserted beats Enriched. Observed never loses. Derived is rebuilt rather than argued with, and Judged is untouchable. Almost every CRM data-quality project is a rediscovery of this list after a year of quiet overwrites.
The build process, stage by stage
Six stages. The first is an audit, and it regularly changes the scope of everything after it.
- Field audit and provenance labelling
Every field the system will touch gets a class and a write rule. We also measure fill rate and staleness per field, which usually retires a handful of fields nobody has written to in a year and consolidates two or three that hold the same idea under different names.
- Identity and duplicate design
Keys, normalisation rules, the merge review queue and its policy. We measure the current duplicate rate first, because a merge strategy without a before number is impossible to defend to the person whose account got merged.
- Enrichment waterfall and caching
Vendor order, the pre-filter that decides what is worth enriching, the cache window, shadow fields and the promotion rule. Per-vendor spend goes on a dashboard from day one rather than arriving as a surprise invoice.
- Routing and the default branch
Rules in version control, decisions logged with the rule identifier, and a fallback owner that cannot be null. We replay the last month of leads through the new rules before anything goes live and show the team where assignments would have differed.
- Extraction and write-back
The qualification schema, the evidence requirement, the scoring code, and write-back under the precedence rules. Scoring is reviewed with the reps it affects, because a score nobody understands is a score nobody uses.
- Reconciliation and rollout
The nightly drift report, stage gates, hygiene jobs, then rollout by segment. Impact is measured against the numbers taken in week one, using the approach in measuring whether an automation actually worked.
Routing rules always look right on a whiteboard. Replaying a real month through them and showing each rep which leads would have moved is the cheapest argument you will ever have about territory. It also catches the rules that produce no assignment at all, which is the failure that hides best because nothing appears anywhere.
What you get at handover
The rules, the code, the measurements and the documents that let somebody else change any of it. All of it in your accounts and your repository from the first commit.
- The provenance and precedence map, written, reviewed, and matching what the code does
- Routing rules in version control, with a replay tool for testing a change against last month
- Extraction prompts and schemas as versioned artifacts, plus a labelled evaluation set of real calls
- Dashboards: duplicate rate, unassigned count, time to first touch, enrichment spend per vendor, drift report volume
- A runbook for adding a territory, changing a stage gate, reversing a bad write and clearing the merge queue
Where these projects go wrong
The failures here are quiet ones. Nothing crashes; the data just becomes slightly less true every week until somebody stops using it.
| Failure | How it shows up | What prevents it |
|---|---|---|
| Silent overwrite | A rep corrects a field, an automation reverts it that night, trust dies | Provenance classes, a written precedence order, and origin tagging on every write |
| Workflow recursion | API limits exhausted overnight by workflows triggering each other | Origin-tagged writes that do not retrigger, plus a circuit breaker on write volume |
| Duplicate accounts | Three records for one customer, from name matching or a free mail domain | Domain as the account key, normalised emails, and a merge review queue |
| Reputation damage | Cold sequences on the primary domain, then invoices landing in spam | A separate sending domain for cold outbound, with its own warmup and caps |
| Unassigned records | Leads nobody owns, invisible because no report counts them | A default branch that cannot be null, and an alert on unassigned count |
| Opaque scoring | Reps ignore the score and work their own list, which is usually better | Score in readable code from extracted fields, with reasons attached to the record |
| Out-of-order updates | A deal moving backwards a stage on its own | Source timestamps on every write, and stale updates dropped rather than applied |
Sending reputation is shared across everything leaving your domain. Run cold outbound from the domain that also carries invoices, password resets and customer replies, and a bad month of bounces will follow your transactional mail into the spam folder. Separate the domains before the first cold sequence, not after the first complaint.
Measuring activity instead of pipeline
Emails sent, tasks created and records touched all go up the moment you switch a system on, and none of them mean anything. The measurements that matter are duplicate rate, unassigned count, time from capture to first human contact, share of deals with a real next step, and how far a forecast made in week one drifts from what closes. Take those before the build. Most of the disappointment in this category comes from teams who cannot tell whether anything improved because nobody wrote down what it was like before.
What it costs to run once it is live
Enrichment is usually the largest recurring line, not tokens. Enrichment is priced per record and scales exactly with the volume you cannot control, so it deserves the pre-filter, the cache and a dashboard of its own.
Set the enrichment price to your own contracted per-record rate and the token prices to your provider's current published rate. These defaults are illustrative figures for the arithmetic, not quoted prices.
Two levers move that total. The pre-filter decides how many records reach a paid vendor at all, and tightening it is usually the single biggest saving available. The cache window decides how often you pay twice for the same company, and a longer window costs you freshness on firmographics that rarely change quickly anyway.
- Enrichment. Per record and contracted, so negotiate on the pre-filtered volume rather than the raw one.
- Integration maintenance. CRMs and vendors change APIs. Every connector is a dependency with its own release schedule.
- Rule maintenance. Territories, headcount and segments change. Unowned routing rules become fiction in about two quarters.
- The merge queue. Somebody reviews candidate duplicates. It is minutes a week, and skipping it is how duplicates return.
- Infrastructure. A queue, a worker, a database and a log store. Small next to enrichment.
Enrichment spend per closed deal, tracked monthly, is a more honest number than enrichment spend per record. It rises quietly when lead quality falls, which makes it an early warning about the top of the funnel rather than a cost report. Put it on the same dashboard as the routing metrics.
How to tell whether you need this
Five measurements, all available from your CRM today, and none of them require a vendor to help you take them.
- Export accounts and count how many share a registered domain. That is your duplicate rate, and it is usually higher than anyone in the room guesses.
- Count records with no owner, or with an owner who has left. Unassigned pipeline is the leak that no report shows.
- Measure the gap between capture time and first human contact, in hours, at the ninetieth percentile rather than the average. The average hides the bad tail.
- Sample thirty recent deals and check whether budget, timeline and next step are filled with something a stranger could act on. Full stops and single characters count as empty.
- Ask two reps how the lead score works. If the answers differ, or nobody can answer, the score is decoration and it is being ignored.
If those five come back healthy, you do not need this yet and we will say so. If duplicates are common, first contact is slow at the tail, and half the qualification fields are decorative, the return is in the hygiene and the routing rather than anywhere near the model.
How to start
The first call is technical and it goes fastest when someone with CRM admin access is on it. Bring exports rather than opinions about the data.
- A field-level export: fill rate and last-written date per field, however embarrassing
- The current routing rules, wherever they live, including the ones only one person knows
- Your enrichment vendors and contracted rates, so the pre-filter can be designed against real prices
- Twenty recent call recordings or email threads, for building the extraction evaluation set
The first deliverable is the field audit and the provenance map. It is a document, not software, and it is the thing that decides whether everything built afterwards stays true. Several teams have taken that document and fixed most of the problem themselves, which is a fine outcome and we would rather say so up front.
ChatGPTalker, Sales Pipeline Automation: identity resolution, enrichment waterfalls, routing precedence and evidence-bearing extraction.