Case study · WhatsApp automation

How RSVP automation scaled to 3,000+ members

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.

  • Large badminton club · West London
  • Direct build and deployment

Manual RSVP handling had become operationally expensive.

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.

The system was built entirely around self-hosted operational tooling.

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.

The four-stage loop made the automation progressively more accurate.

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.

Several operational edge cases had to be solved before the system was reliable.

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.

The member experience stayed the same while the operating model changed completely.

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.

Next move

Need something similar?

If your business is buried under repetitive messaging, booking confirmation, or member coordination work, the same architecture can be adapted to your workflow.