One record shape for every channel
Most follow-up problems start with enquiries that look different depending on where they came from: a voicemail, a WhatsApp thread, a form email. Agree one shape first. Collect only what you need to reply and route; South Africa’s POPIA requires information to be “adequate, relevant and not excessive” for its purpose.
| Field | Contents | Why it is there |
|---|---|---|
id | A unique reference, created once | Lets every later step, and every person, refer to the same enquiry |
received_at | Date and time, with time zone | Ordering and response-time reporting |
channel | phone, website, whatsapp, email | Where it came from, and how to reply |
type | e.g. new job, existing job, supplier, other | Drives routing |
name | As the customer gave it | Personal reply |
reply_by + contact | whatsapp / call / email, and the number or address | One reply method, validated against its format |
summary | A few lines in plain language | What a person reads first |
details | The fields your business needs, e.g. vehicle and damage | What makes the first callback useful |
attachments | Links to photos or files, not the files themselves | Keeps the record small; files stay in storage you control |
status + owner | new, assigned, replied, closed; and who owns it | Nothing waits in one person’s inbox |
next_action_at | When the next follow-up is due | Drives reminders and escalation |
Capturing each channel
- Phone. A person or an AI receptionist fills the record during the call and reads the key details back to the caller. The summary is written for the person who calls back, not as a transcript.
- Website. The form or chat sends its answers to an endpoint that validates them before anything else happens: required fields, formats, a contact detail that matches the chosen reply method, and spam checks.
- WhatsApp. On the WhatsApp Business Platform, each incoming message reaches your workflow as a webhook. Messages from the same customer within an open enquiry are added to that record instead of creating new ones. Photos are saved to storage you control, and the record keeps the link.
Delivering it reliably
- Sign it. The sender signs each delivery with a shared secret and a timestamp, and the receiver rejects anything unsigned or too old. That stops anyone else posting fake enquiries into your system.
- Confirm only after storing. The receiver answers “received” only once the record is safely stored. Until then, the sender treats the delivery as not done.
- Retry, then alert. Failed deliveries are retried with increasing delays. If they still fail, a named person is told. An enquiry is never silently dropped.
- Make repeats harmless. Give every enquiry a reference when it is created, and have the receiver ignore a reference it has already stored. Retries then cannot create duplicates.
Routing
Write routing down as simple rules: if the type is X, assign it to Y and set the next action for Z hours. For a panel-beating workshop, for example: new damage goes to the estimator, insurer and assessor messages go to the claims administrator, and “is my car ready?” goes to the workshop manager. Rules like these are easy to check and easy to change. If a rule needs judgement, it should go to a person, not to an AI guess.
Following up without duplicates
- Every scheduled follow-up first re-reads the record. If the status is “replied” or “closed”, or the customer opted out, it stops.
- Each follow-up records that it was sent, so a rerun of the workflow cannot send it again.
- A follow-up goes out on the customer’s chosen reply method. On WhatsApp, messages outside the 24-hour customer-service window must use approved templates and are charged by Meta. See what a WhatsApp chatbot costs to run.
- Reminders to your team (“this enquiry has had no reply for four hours”) are usually more useful than more messages to the customer.
When something fails
| Failure | What should happen | Who is told |
|---|---|---|
| The destination (CRM, sheet, inbox) is down | Delivery is retried with increasing delays; the enquiry is kept, not dropped | An alert goes to a named person if it still fails |
| The same enquiry arrives twice | The second copy matches the first by its reference and is ignored or merged | Nobody; duplicates are expected |
| A required field is missing or invalid | Rejected at entry with a specific message; the customer can correct it | The customer, at once |
| A follow-up is due but a person already replied | The status check stops the automated message | Nobody |
| The customer opted out | All further messages to them stop, on every channel | The owner sees the opt-out on the record |
| An automation step fails silently | A daily check lists enquiries still “new” after the agreed time | The team lead |
Is this workflow worth automating?
A workflow is a good candidate when most of these are true:
- It happens often: daily or weekly, not twice a year.
- The steps can be written down as rules, without case-by-case judgement.
- The information it needs already arrives in a usable form, or can be made to.
- A mistake is cheap to notice and fix, or a person reviews it before it matters.
- Someone owns it, and will notice when it stops working.
If the steps are unclear, write them down and run them by hand for a few weeks first. Automating an unclear process makes the confusion faster, not smaller.
How this site’s own form does it
The request form on this website follows the first half of this design. It validates every answer on the server, rejects mismatched contact details, rate-limits repeated attempts, and logs outcomes without any personal details. It then delivers the request as a signed webhook to an n8n workflow. The visitor sees a thank-you only after the workflow confirms delivery. If delivery is not set up or fails, the page says so and offers WhatsApp and email instead. We build client workflows on the same principles, in n8n or in tools you already use.
See workflow automation for how Devincam scopes this for a business. For the fields a workshop needs, see the panel-beater enquiry checklist.
Sources
Checked 27 October 2026. Prices and policies change; follow the links for the current version.
- n8n documentation: Webhook node Receiving signed deliveries and responding only when ready.
- n8n case study: System AI A published WhatsApp → n8n → CRM build (UK agency); its results are self-reported.
- Meta for Developers: WhatsApp Business Platform pricing 24-hour customer-service window and template rules.
- POPIA section 10: minimality Unofficial publication of the Act; confirm against the Government Gazette text for legal use.