A dispatcher and nine day-by-day SMS sequences, with the CRM as the cursor
Ten Make scenarios run timed SMS follow-up sequences: one dispatcher reads a CRM status change and routes to one of nine per-offer sequences, each of which sends the message for the current day and moves the day forward.
Where this applies
Sales teams that nurture leads with a timed message sequence per offer and want the progress visible in the CRM.
- scenarios: a dispatcher and nine sequences
- 10
- messages in the longest sequence
- 8
The problem
A lead who has enquired and gone quiet needs a timed series of nudges, different for each offer and different for someone who has opened an earlier message. Doing it by hand is inconsistent; doing it in a bulk tool means the CRM no longer knows what each lead has been sent.
The sequence's state has to live where the sales team can see and change it, and the copy for each offer has to be editable without touching the others.
What we built
A dispatcher
An instant webhook fires when a lead's status is set to 'Send SMS'. The dispatcher fetches the lead, normalises its phone number to international format with a small JavaScript step, and a router on the lead-stage label chooses the sequence for that offer and variant, calling it fire-and-forget with five fields: item, phone, course, day and name.
Sequences as callable tools
Each sequence is an on-demand scenario with typed inputs, one per offer and variant: 'Follow Up' for an enquiry and 'Opened' for a lead who has opened an earlier message. Editing the copy for one offer touches one scenario.
The CRM holds the cursor
A sequence is a router with one route per day label. Each route checks that the day equals 'Day N', sends that day's message through the SMS provider, then rewrites the day column to the next day and the SMS status to 'SMS Sent'. The last route sets 'Completed'. The day label is the cursor, and sales staff can see and move it.
Two lengths
The 'Follow Up' sequences send up to eight messages and the 'Opened' sequences seven. The only personalisation is the lead's first name.
The outcome
One dispatcher and nine sequence scenarios, all switched on and last edited in November 2025.
None has run yet, so this page describes a design rather than a volume.
Where it stops
There is no run history. The sequences do not check opt-out or pause status before sending, do not read replies, and have no fallback: a stage label the dispatcher does not recognise ends the run silently. Moving to the next day depends on something outside these scenarios setting the status again each day. The day and status labels must already exist in the CRM, because the update does not create them, so a missing label would fail after a message has gone. A tenth sequence, with unfinished wiring, is not described.
Built with
- Make.com
- monday.com
- Twilio
- JavaScript module
Patterns used
- Dispatcher and children
- CRM as state machine
- Fire-and-forget fan-out
- Typed on-demand interface
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no