Case study · WhatsApp automation
A production WhatsApp RSVP system for a large West London badminton club, built with self-hosted automation, PostgreSQL audit history, and a self-improving AI intent loop.
Weekly sessions across multiple West London venues were generating a constant stream of WhatsApp replies that needed manual reading, interpretation, and recording before anyone knew whether a slot was filled.
Members wrote in every format imaginable: yes Wednesday, coming with my sister, cancel Friday, back next week. The goal was to automate the entire process without asking members to change behavior or move away from WhatsApp.
WhatsApp Business API handled member-facing messaging. n8n orchestrated workflows. PostgreSQL stored member records, RSVP history, prompt versions, and correction data. A local model running through Ollama handled intent detection. Everything ran in Docker and was exposed securely through Cloudflare Tunnel.
That kept the stack license-light, locally controlled, and practical to operate without depending on a high-cost SaaS layer for every part of the workflow.
When a member message arrived, an n8n webhook passed it to the local model, which classified intent into RSVP, LIST, SESSIONS, or MENU. That let the system handle natural language variations instead of brittle keyword rules.
When a message was misread, the correction was captured in PostgreSQL. A scheduled workflow then analyzed recurring corrections, generated an improved prompt, stored that in a prompt-versions table, and promoted it into active use. The system improved by learning from real member behavior instead of static assumptions.
Guest bookings originally created only one RSVP record when a member said they were coming with someone else. The workflow was updated to iterate over parsed party size and create separate attendee records.
Opt-out status from the WhatsApp API arrived as a string rather than a boolean, so a code node now normalizes that before outbound messaging. Large broadcasts are rate-limited in batches to stay inside API constraints. The contact sync was also rewritten to use batchGet requests, reducing a 30-minute sync to under two minutes.
Members still message the same WhatsApp number, receive confirmations within seconds, and can book, cancel, or check sessions using natural language. The interface did not change; the work behind it did.
This turned repetitive coordination work into an auditable, production-grade messaging system. The same pattern is applicable to clubs, gyms, and other organizations dealing with high-volume member communication.
This case study is a first-party operational account by the system designer and operator, not an independent client audit. “3,000+” describes contacts in the organisation database, not simultaneous active users. The under-two-minute contact-sync figure compares the revised batched process with an earlier run that took about 30 minutes under the observed conditions.
The four-stage improvement loop describes the implemented correction process: record an error, analyse recurring patterns, produce a revised prompt, then promote an approved version. It does not mean the model changes itself without review. Message delivery, workflow execution and the resulting RSVP record are treated as separate states.
The page was first observed on the public server on 9 July 2026, based on the server’s Last-Modified record. It was updated on 13 August 2026 to add this methodology, primary sources and the architecture visual.
Next move
If your business is buried under repetitive messaging, booking confirmation, or member coordination work, the same architecture can be adapted to your workflow.