An out-of-office is not a reply
“I'm away until 22 June, for urgent matters call 06-…” reads like a response and isn't one. Count it as a reply and you drop someone from follow-up who never read a word.
Bergsma Interieurbouw makes bespoke kitchens and cabinetry in Zwolle. Enquiries arrive every week through the website form and by phone. Most get answered once and then never again, because following up is dull work that always loses to something more urgent.
Bergsma is a simulated engagement: a company we set up ourselves to build and test this workflow on.
Anyone can build a sequence of reminders. The risk sits on the other side: that you keep emailing someone who already replied, who opted out, or who appears twice in your system and therefore gets everything in duplicate.
That is not just annoying for the recipient. It is exactly the behaviour that makes a business decide to stop following up altogether — at which point the cure is worse than the disease.
So this workflow runs every working day, reads its own memory first, and decides per person all over again whether anything should go out at all. The answer is often no.
A simple follow-up sequence falls over on every one of these. So all six are in the test data.
“I'm away until 22 June, for urgent matters call 06-…” reads like a response and isn't one. Count it as a reply and you drop someone from follow-up who never read a word.
A 4.7.1 from greylisting resolves itself. A 5.1.1 means the address does not exist. In the mailbox they look the same; the difference is a prospect.
Someone fills in the form twice, once with a dot in the email address and once without. The phone number is identical. Without that link, two sequences run at one person.
If the consent box is unticked, nothing goes out. Not even if the enquiry is otherwise perfect. Calling someone about their own enquiry is still allowed, so it is not a dead end.
Not to the enquiry. Someone who opts out and fills in a form again three months later does not quietly land back in a sequence.
There is a competitor fishing for trade prices and a supplier pitching himself. The latter had been in the showroom sequence for two emails before he pointed it out himself.
The run covers Friday 12 June. The previous run was Tuesday evening; Wednesday and Thursday were skipped. So this run had sixty hours of events to catch up on at once. It took 25 seconds and cost four and a half cents. This is what came out.
A second attempt at someone with a clear question and no deadline, and a first at a former client coming back on her own. Next attempts are scheduled for 19 and 16 June.
Among them a care group replacing pantry kitchens at three sites: score 92 out of four assessed criteria. That deserves a phone call, not a sequence.
The same person appeared twice, with a slightly different email address and the same phone number. Two emails were scheduled for that day. Neither went out — he had replied overnight.
One because it was a consumer provider, where a lookup returns nothing but still costs quota. One because the service happened to be down. Both enquiries were processed anyway.
So on a day with three new enquiries and four incoming messages, two emails went out and five things landed with a human. That is not a shortcoming of the workflow; that is what it was built for.
The workflow runs in n8n on our own server, on a schedule that fires every working day. On the left the sources and the memory, in the middle six steps that all run in code, and only then the two steps that call AI. On the right the four outcomes.

Every AI step has a Success and an Error output, and both run into the same checking step. That is deliberate: whether the model answers or falls over, something comes out that the rest of the workflow can work with.
That is why the run carried on when the model dropped out entirely during testing.

The workflow first processes what came in, and only then what was scheduled. The other way round you send a reminder this morning to someone who replied last night. That is the mistake people notice most.
Merging afterwards fixes nothing: both emails are already gone. So this step sits ahead of every send decision, and matches on phone number when the email address is spelled slightly differently.
The model scores four criteria, each with a literal quote as evidence. Code then checks that the stated score equals the sum of those criteria. A bare 82 means nothing; an 82 that adds up from four assessed points does.
Too uncertain, not assessed, or an incoming message that could not be interpreted: in all those cases nothing goes out and it lands with a human. Doing nothing is a valid outcome here, not a malfunction.
During testing the connection to the model dropped completely. The run carried on: the consent check, the identity merge, the bounce sorting and the scheduling are all code. Only interpreting the replies and assessing the enquiries was missing, and the daily report said so in as many words.
That was not luck but a design choice: the things that can cause harm do not live in the AI layer.
It also exposed a gap. In the first version someone still got a reminder, even though he had complained overnight that he was already getting too many. His message could not be interpreted, so the sequence was never stopped.
Now the rule is: if a message comes in that cannot be interpreted, the sequence stands still until a human has read it. Better a day late than an email to someone who just asked you to stop.