The first morning brief my new workflow sent me said this: 5 texts in from 0 numbers.

Both numbers were correct. The five texts were me, texting my own business line while I tested it. The code counted my texts as traffic, and then, also correctly, refused to count me as a customer. Two honest counts made one sentence that meant nothing.

It took one real run to find. That is the whole reason I test against a real phone before anything goes public.

Why split them out

My lead-response system is fifteen n8n workflows that share one send path, one owner alert and a set of data tables. That is what makes them reliable together. It is also why you cannot import one of them on its own.

A lot of small businesses do not want a system. They want the one thing that is hurting this month. So I pulled four pieces out and rebuilt each one to stand alone. Each needs a Twilio account and nothing else.

1. The quote chaser

A quote goes out and the customer goes quiet. This texts them up to three times, spaced out over days, and stops the moment they reply. When they reply, the owner gets a text saying so. When the three nudges run out, the owner gets told the chase is closed.

It has no database. Before each nudge it asks Twilio one question: has this number texted the business since the quote went out? Twilio already keeps that record. There was no reason to keep a second copy.

2. The 7am owner brief

One text every morning: how many customers texted in, how many texts went out, anything that failed to deliver, and who is still waiting on a reply, newest first.

It reads the Twilio message log for the last eight days. The wider window is what lets an unanswered text from last Thursday still show up as waiting on Monday morning.

The 0 numbers bug lived here. The fix was to count customer traffic only: texts between the owner’s own cell and the business number do not count as anything. A second, smaller fix came out of the next run. A quiet day had to mean no customer texts, not no texts at all, or the brief skipped the “quiet” line whenever I had been testing.

3. Appointment reminders with quiet hours

A confirmation when the booking comes in, then reminders 24 hours and 2 hours before.

I already wrote about the bug that shaped this one: a quiet hours rule that is right for marketing will happily deliver a 5am reminder at 8am, after a 7am appointment. The standalone version works out every send time the moment the booking arrives, with quiet hours applied up front. A reminder that would land at night moves earlier, to 7:30 the evening before. A confirmation for a booking made at 11pm waits until 8am. Anything that would already be in the past, or would land on top of another text, is skipped.

Because the plan is made up front, the webhook can answer with it. The booking tool gets back the exact times each text will go out, or the reason nothing was planned.

The live test I liked most: I set a quiet window that covered the current time and booked an appointment inside it. The confirmation sat and went out at 11:45:00, the second quiet hours ended.

4. STOP, START and HELP alerts

When a customer replies STOP, Twilio blocks any more texts to them from that number. That is how it should work. But nobody tells the business. Their CRM keeps the customer on every list, the next campaign fails against that number, and nobody knows why.

This one sits on the number’s incoming texts. It answers Twilio with an empty reply, so the customer only ever sees Twilio’s own STOP and HELP responses and nobody gets texted twice. Then it texts the owner, and it can post the opt-out to a CRM.

When Twilio’s Advanced Opt-Out recognises the keyword, it says so in the request. The template trusts that first. Without it, the template falls back to Twilio’s default keyword list, matched against the whole message, so “Please stop by at 3” is a normal text and not an opt-out.

The pattern

Three of the four read the data Twilio already has instead of keeping their own. The fourth just passes along what Twilio has already decided. That makes them easy to install and hard to get out of sync, because there is nothing to sync.

What is not covered

Every template’s test notes say what I did not test next to what passed. The main gaps: the full multi-day waits were not run end to end, and the STOP handler was tested with the same requests Twilio sends, not with a real phone texting through Twilio. My business number’s incoming texts run the live system and I did not repoint it for a test.

Where they are

Free, MIT licensed, each with its own test notes:

github.com/mikematthewsai/n8n-lead-response/tree/main/templates

The quote chaser is in review for n8n’s public template library now. The others follow one at a time.