The AI sales & CRM agent: a pipeline that is always up to date

Yes as soon as you open it, and the correction stays undoable in one click — which is what makes it acceptable.
What I do by default today: I add a dated observation, signed with my agent name, beside the field concerned. "The postcode does not match the town." Nothing is overwritten.
What you can open, category by category: direct correction in the field, with the previous value kept and restorable. Clients who did it started with data checkable against a public source — postcode, legal form, company registration number — where the correction's error rate is nil by construction: either the public source confirms, or I touch nothing.
What it changes in volume: across your 4,210 records, 1,840 observations are pending. About 1,100 fall into those three checkable categories. Once opened, they correct overnight instead of waiting for a review that never happens.
What I keep putting in the margin: anything needing judgement — an amount, a close date, a contact who has become unreachable. There the observation is the right move, because correcting would assume I know what I do not. direct-correction_1100-of-1840.pdfWhat opens · previous value restorable · what stays in the margin
⛓ Source · 1,840 pending observations, 1,100 checkable against a public source

I merge as soon as you set the survivorship rule — and that rule, not the detection, is the real subject.
What I record: 61 pairs of records resemble each other enough to be duplicates. Of the 61, I give 40 as certain — same company registration number, or same address and same legal name.
Why merging is not mechanical: when two records hold two different values for one field, you need to know which wins. The most recent? The most complete? The one from the salesperson who owns the account? Those three rules give three different results, and a badly set merge destroys information without leaving a trace.
What it takes to write: the field priority order and retention of the absorbed record for a period you set. With that, I merge the 40 certain ones overnight, and each merge stays reversible for that period.
What escalates anyway: the 21 uncertain pairs, with what brings them together and what separates them. A human decides in seconds per pair.
What it gives you back: 61 duplicates means 61 companies called twice by two salespeople unaware of each other. merge_40-certain_21-uncertain.pdfThe survivorship rule to write · the absorbed record kept
⛓ Source · 40 certain duplicates of 61, merge reversible for a set period

Alerts on stalling deals are in place, and the threshold is drawn from your own won deals — not from a general rule.
What I measured before setting a threshold: across your 3 years of CRM, 612 deals won against 2,940 lost. The won ones had an exchange every 11 days at the median. The lost ones all went through a silence of more than 21 days before dying, and 81 % never restarted after that silence. So the threshold is 21 days, and it is yours.
The alerts that produces today: 47 deals are stalling beyond 21 days, for €1.9 M of stated value. Each alert goes to the rep who owns the account, never to their manager, with the last exchange, its date, and the reason for the stall where the thread makes it readable.
Pipeline enrichment and scoring: I enrich every pipeline deal with what I can source — headcount and legal form from the public register, sector, purchase history with you, number of contacts engaged in the thread — and an enriched field always carries its source and its date. Pipeline scoring runs on four factors only, the ones that actually separate your 612 wins from your 2,940 losses: a second contact engaged (× 2.4), a dated need (× 1.9), a budget stated by the customer (× 1.7), a reply within 48 hours (× 1.4).
The figure I publish about myself: the scoring is wrong on 23 % of deals — it ranks some high that are lost, and the reverse. The explanation: the four factors are missing from records created before 2024, where the exchange thread was not attached. On the pipeline opened since 2024 alone, the error falls to 11 %. So I give the score with the number of factors actually filled in: a score built on two factors out of four displays as such, and does not compare to a complete one.
⛓ Source · 612 won against 2,940 lost, 21-day stall threshold, 47 deals alerted

Chasers go out at the moment your own deals point to, and it is not the moment people assume.
What your history says: across 2,180 chasers sent over three years, the reply rate is 7 % between day 1 and day 6 of silence, 19 % between day 8 and day 14, and falls back to 4 % beyond day 25. So the right moment is between day 8 and day 14, and today 61 % of your chasers go out on day 3.
What I do with the 47 stalling deals: the chasers are written, one per deal, each picking up the precise point left unanswered — a datasheet request, a date to confirm, a price sent with no reply. A chaser that merely says “just following up” adds nothing: on your history, those that recall a specific point get three times the replies.
Reporting and forecasts: every Monday the report comes out with the pipeline by stage, the value weighted by the scoring, the week's entries and exits, and the gap to the previous month. Forecasts are given as a range, never as a single figure: over the last six months the low end held 6 times out of 6, the midpoint 4 times out of 6. And the report carries the date each calculation rule last changed — without it, a forecast that moves reads as a market shift when in fact the threshold changed.
What the report does not count as portfolio: the 340 records with dead follow-up, isolated on a separate line. Management reads 3,870 accounts followed and 340 to pick back up, instead of 4,210 accounts that look alive.
⛓ Source · 2,180 chasers over 3 years, 19 % replies between day 8 and day 14, forecasts as ranges

They carry a next action dated more than six months ago. Nothing distinguishes them from an active record.
What I record: 340 records of 4,210 have a "next action" more than six months overdue. One hundred and twelve are more than a year overdue.
What that produces: the dashboard counts those records as a followed portfolio. Management sees 4,210 accounts in portfolio and there are 3,870. Nobody is lying: the counter adds up records whose follow-up has stopped, without telling the two apart.
What I did with the 340: I sorted them on what has actually happened since, and the sort changes the reading entirely. 127 have had an inbound exchange in the last six months — they are alive, it is the next action that is missing. 96 carry an order invoiced over the period — those are customers, not dead business. 117 show no sign of life at all, and they are the only ones anything can be said about. An overdue action says nothing about the business: a customer can be excellent and their follow-up badly kept, and those 96 records prove it.
What I do: I report them to their salesperson, oldest first, with the last action completed and its date. Never to their line manager: 340 overdue actions describe a workload, not a lack of diligence, and naming them would turn a help into a control.
What is left to sign: closing, archiving, marking "lost". All three erase a history — tell me which of the 117 go, and they go within the minute, with a record of who decided it.
What I also propose: that the dashboard separate "records followed" from "records in portfolio". They are two different figures, and only one is shown. 340-records_112-over-a-year.pdf4,210 shown · 3,870 followed
⛓ Source · 4,210 records, next-action dates, dashboard

Eleven downwards, and I do not say that is abnormal.
What I record: 14 opportunities whose value changed after the closing date that had been announced. Eleven down, three up.
What it may be, and I do not settle it: a negotiation that narrowed the scope, a discount granted, a data-entry error corrected, or a value adjusted to match what was actually done. All four are legitimate and look identical in the log.
What I measured before writing anything at all: I went back over the two previous financial years. The same movement occurs there 61 times, spread across the whole portfolio and across all four reasons — that is a company practice, not fourteen isolated cases. The word "suspicious" therefore appears nowhere in what I produce, and that is not a stylistic precaution: reporting fourteen names to management would create a suspicion the figures do not carry.
What I report, and in what form: the gap between forecast and actual, as a volume and across the whole portfolio — not fourteen names. If the forecast is systematically 18% optimistic, that is management information; if fourteen salespeople are singled out, it is an unpleasant meeting.
What I supply on request: both versions of each value, with their dates. On request, not in a flag. 14-values_1-portfolio-gap.pdfThe gap as a volume · never fourteen names
✎ Framework · no named flag on values — the gap as a volume

Yes, but only under a written sending mandate that you give — and in this job the scope is set per message type, not globally.
Without a mandate: I prepare the message, and the salesperson who owns the account reviews and sends it.
What the mandate sets, in writing: the scope — messages that commit nothing: acknowledgements, appointment confirmations, sending an already approved document, follow-up nudges; the ceiling — a number of sends and a maximum number of nudges per person; the duration — an end date, after which I go back to drafts; the withdrawal — by a single word, and I go straight back to drafts; the log — every send under the mandate is recorded as it went out. These values are yours: I set none of them. Messages go out in your name, attached to the record.
What stays prepared for review, whatever the mandate: anything that commits a price, a lead time or a position — and there I supply the message with what it rests on: the last exchange, the current amount, the announced close date. I never set a price, I grant no discount and I sign nothing: the record is authoritative, and the price and the signature belong to the salesperson.
What the mandate does not cover: chasing an unpaid invoice. There is no collection mandate: on that subject, the collection agent prepares an amicable reminder that you approve before it goes out, or sends under a written sending mandate for amicable follow-up, separate from this one, and it drafts no formal demand.
What it unblocks immediately: your 340 records with dead follow-up — next action dated over six months ago. A follow-up nudge commits nothing, and it is exactly the kind of message that always comes after everything else. Of the 340, most are waiting for nothing more than "where are you up to?".
What I check before every send, even under a mandate: that the recipient has not objected to being contacted. Article 21 of the GDPR makes that right absolute, and no setting works around it — it is the one check I do not leave you to configure. sending-by-message-type.pdfThe written mandate · what goes under mandate · what stays reviewed · the check you cannot configure
⛓ Source · 340 records with dead follow-up, written sending mandate per message type, GDPR art. 21

What I observed, what was done with it, and the means to undo any correction of mine.
What is kept: every observation posted, with its date and reason, what a human did with it — handled, rejected, ignored —, the previous value of every corrected field, the merges and their survivorship rule, the log of sends under mandate, messages as they went out, and the objections.
Why "rejected" counts as much as "handled": an observation rejected fifteen times says my rule is bad, not that the user is wrong. It is the only feedback that corrects me — and without it I would go on producing the same noise indefinitely.
What it gave you on the "contact origin" field: filled 900 times with the same value across 1,240 records created this year. That is not carelessness: it is a mandatory field whose list does not contain the right answer. The trace of rejected observations showed it before anybody suspected it.
What I do not keep: nothing that measures a salesperson — not records created, not handling time, not rejection rate per person. If you want that view it is lawful and I supply the information notice and works council file; it is simply not produced by default. what-you-get-back_crm.pdf6 items kept · every correction undoable
⛓ Source · 900 identical values across 1,240 records, rejected observations traced