Automated CRM Follow-Up That Tells You When It Breaks
Part 1 of 6 in the series The Follow-Up Machine
- Overview, Automated CRM Follow-Up That Tells You When It Breaks
- Architecture, An n8n Workflow Example Built to Survive Retries: The Follow-Up Machine Architecture
- Register, EspoCRM Webhooks in n8n: The Event Name, the Signature and the Stage That Did Not Exist
- Evaluate, An Hourly n8n Workflow That Does Not Overlap Itself: Locks, Merge Barriers and Quiet Runs
- Enrich, AI Summaries of CRM Emails with n8n and Mistral: The Prompt, the Parser and the Comma
- Alerts, n8n Error Workflows That Actually Alert: Deduplication, Stale Locks and the Friday Email
Your CRM already knows which deals have gone quiet. The proposal went out, the stage says Proposal, and the last logged contact was eleven days ago. All of that is in the database. Nothing in the database will interrupt your week to mention it.
Some CRMs close that gap for you. Pipedrive flags deals that have sat untouched for too long, and HubSpot can do something similar with workflows on its higher tiers. If you are on either, you may already have what this post describes.
I run a self-hosted CRM, EspoCRM, without its paid Advanced Pack, so there is no workflow automation built in. So I built one for my own pipeline. This is what it does, and more usefully, what went wrong.
The rules
When a deal enters the Proposal or Negotiation stage, the machine schedules three follow-ups: 5, 12 and 21 business days out. Business days means public holidays from a table are skipped, in my case the Austrian ones, generated for the Tirol region. That matters more than it sounds. Without the table, a follow-up lands on a national holiday and nothing happens for four days.
Every hour from 07:00 to 19:00 on weekdays, it looks at each open deal and applies one rule:
| What it finds | What it does |
|---|---|
| The deal is won or lost | Stops watching, cancels the remaining follow-ups |
| Real contact since last time: a sent email, a held call, a meeting | Restarts the clock from that contact |
| The deal was deleted | Stops watching, quietly |
| None of the above, and a follow-up is due | Creates a task in ClickUp that links to the deal |
“Real contact” is deliberate. A call scheduled for next week is not contact, and neither is someone tidying a field on the deal. Only things that actually happened reset the clock.
On top of the tasks, I get two emails. On Tuesday to Friday at 08:45, a short list of what is due today, sent only when something is. On Friday at 15:45, a digest of what moved, what is stuck and what closed.
Where the AI earns its place
Remembering to follow up is the easy half. The hard half is opening the deal and working out what the last conversation was about.
So a second workflow reads the last three emails on each deal and condenses them into two lines: where things stand, and a sensible angle for the next follow-up. Those lines appear in the task and in the morning list. The model is Mistral Small, and it answers in the language the correspondence was in.
It does not write the follow-up email and it does not send anything. The machine reminds, and a person writes. An automated follow-up reads like one, and the recipient notices.
It never writes to the CRM
The machine reads from the CRM and never writes to it. Its own state, meaning which deals it is watching and which follow-ups have fired, lives in a small separate database.
That keeps the CRM as the authoritative source. A bug in the machine cannot corrupt a deal. If its database is lost, the business data in the CRM survives, because every hour the machine compares its list against the CRM and recreates any missing watch. What does not come back is its own history: which reminder already fired, and when. That same hourly check means webhooks are an optimisation, not a dependency. Any CRM that can list its deals over an API could sit underneath it. The CRM-specific part is small: six API calls across three workflows, and one list of stage names. The rules, the business days, the reports and the duplicate protection know nothing about EspoCRM.
The rule that matters most: fail loudly
A follow-up system that silently stops is worse than none, because you keep trusting it.
Two things guard against that. The Friday digest is built to send even with nothing to report, and its footer says when the hourly check last succeeded. A run that fails does not count as a success, even while the workflow itself is still scheduled. If the last successful check was more than 24 hours ago, the warning moves from the last line to the first. And every failure sends an alert, but at most one every six hours per workflow. Otherwise one expired credential produces two dozen emails overnight, you write a filter, and the next real failure goes straight into it.
Both guards share one limit, which I only found while writing part 6: they both depend on the same database. If that is down, neither the alert nor the Friday email goes out, and the missing email is the only signal left.
Every workflow is also safe to run twice. Webhooks get retried, schedules overlap and networks drop. Running twice has to produce exactly what running once does, or you get duplicate tasks, and after the third duplicate you stop believing any of them.
What went wrong
The plan said half a day. The first commit was on 28 July and the last fix on 6 August. One day of that went into the AI summaries, which I added along the way. Most of the rest went into things no plan anticipates, because they only show up once real data runs through the system.
For five days it ignored exactly the deals it was built for. The stage filter looked for “Proposal/Price Quote”. That is the SugarCRM spelling. A stock EspoCRM calls the stage “Proposal”. Every deal at proposal stage was silently skipped. Nobody noticed, because my test deal happened to be in Negotiation, which worked.
Emails and calls store their date in different fields. Calls and meetings have a start time, and emails have a sent time. The machine first read only the start time. Most real contact is email, so that was not an edge case. It was the main case.
A German sentence broke a database write. The first real AI summary contained two commas. The n8n Postgres node splits its query parameters on commas, including commas inside the resolved values. The database received half a sentence where it expected a number.
The error workflow did not fire. n8n’s documentation says an error workflow does not need to be active. On the version I run, an inactive one produced no alert when a scheduled run failed. It has to be switched on.
None of these was hard to fix. What is instructive is how they surfaced. Only the comma caused an error, and so an alert. The stage name and the date field caused nothing at all: the machine ran cleanly and simply did less than it should. The error workflow bug is worse still, because it switched off the alarm itself. I found those three only by testing with real deals, case by case.
That is the actual lesson.
Failing loudly catches crashes. Against a system that runs without errors and does the wrong thing, only testing with real data helps.
Build it or buy it
If your CRM already detects stale deals, use that. It is less to maintain.
If you run a self-hosted CRM, or sit on an entry plan that leaves automation out, this is a small system with a clear edge. It reads a list, keeps a little state and creates tasks. Most of the effort goes into making it trustworthy, not into making it work.
What is still missing
Numbers. It has been running since early August, which is too short to say honestly how many deals it saved. I will write that up when there is something to report. This post is part 1 of a series. The individual workflows, the schema and the failure handling are in parts 2 to 6, which are more technical.
If a process in your business goes quiet in the same way, tell me about it. Follow-up is rarely the only one.