If you do not have a developer, a middleware platform is how iMessage gets connected to whatever already knows your appointments. It is a genuinely good answer, and it has a shelf life you can predict.
Which platform
| Zapier | Make | n8n | |
|---|---|---|---|
| App catalogue | Largest | Large | Smaller |
| Pricing model | Per task | Per operation | Per execution, or self-host |
| Branching and loops | Basic | Strong visual | Strong |
| Self-hosting | No | No | Yes |
| Best for | Getting live fastest | Complex multi-step logic | Volume, or data you will not send to a SaaS |
n8n's self-hosting option is the one worth noting for messaging specifically: if you are uncomfortable routing customer phone numbers and message bodies through a third-party automation platform, running it yourself removes that hop entirely.
The arithmetic that decides when to stop
Middleware bills per task, and one message is rarely one task. A realistic flow is: trigger, look up the contact, check a condition, send, log the result — five tasks per message. At a few hundred messages a month that is invisible. At a few thousand it is a real line item and a developer starts to look cheap.
| Messages/month | Tasks/month | Verdict |
|---|---|---|
| 200 | 1,000 | Comfortably inside a small plan |
| 1,000 | 5,000 | A mid plan. Still cheaper than building. |
| 5,000 | 25,000 | Compare against a few days of developer time |
| 20,000 | 100,000 | Build it. Middleware is now the expensive option. |
The four failure modes
- Silent stops. A zap that errors just stops sending. Nobody is told, least of all your customer. Turn on the platform's failure alerting before you depend on it, and check the run history daily for the first fortnight.
- No idempotency. A re-run or a duplicated trigger sends the message again. Most no-code flows have no natural guard against this. Use a lookup against a "already sent" record before sending.
- No suppression check at send time. The flow fires on a trigger, not on a list, so it is easy to forget the opt-out check entirely. Add it as an explicit filter step, and put it immediately before the send.
- Latency. Seconds to minutes. Fine for confirmations and reviews; genuinely wrong for an on-my-way alert.
The one step everyone omits
A filter that stops the flow if the contact has opted out. It is one step, it takes two minutes, and its absence is the single most common compliance failure in no-code messaging. Put it in before the send, not after the trigger. The rules.
A flow worth copying
- Trigger: appointment created in your booking system.
- Filter: contact has messaging consent, and a phone number.
- Filter: no message already logged for this appointment.
- Delay: until the appropriate hour in their timezone, if the trigger fired at 3am.
- Action: send via your provider's API.
- Action: write the send back to the customer record, so step three works next time.
Six steps, and steps two, three and four are the ones that separate a working programme from a complaint. What the coded version looks like.