Case study
The dangerous failure mode for automation isn't crashing. It's failing silently.
A booking confirmation that doesn't send is bad. A booking confirmation that doesn't send and nobody notices is worse. Zentry's automation is built around that distinction.
The problem
Manual WhatsApp confirmations don't fail loudly. They just quietly stop scaling.
Every small service business already uses WhatsApp to confirm bookings — that's not the gap. The gap is that it's manual: someone opens a chat, types a confirmation, and does it again for the next customer, and the one after that. It works fine at five bookings a day. At thirty, messages get delayed, some get forgotten entirely, and nobody notices until a customer shows up to a slot that was never actually confirmed.
Zentry's job is to remove the "someone has to remember to type this" step without removing the thing customers already trust: a WhatsApp message from the business, not an email nobody opens or an SMS that feels like spam.
The approach
Automation that logs its own failures, not just its successes.
The design principle that shaped BookingAutomationService and PaymentAutomationService was: never let an automated message fail without a trace. Every send attempt — template missing, customer phone missing, the WhatsApp API itself throwing an error — writes an ActivityLogger entry with the specific reason, not just a generic "failed" flag. A business owner should never have to wonder whether a customer got notified; the log answers that directly, every time.
Tenant onboarding got the same "don't let this fail silently" treatment from the opposite direction: instead of open self-serve signup, a business submits an onboarding request and an admin explicitly approves or rejects it before TenantProvisionService creates anything. That's a deliberate choke point — WhatsApp Business API access ties to real phone numbers and real Meta approval, so letting anyone self-provision a tenant would create accounts nobody could actually use.
The architecture
What's actually running under it.
- Backend
- A custom
PHP MVCcore — its own Router, Model, View, and middleware layer, in the same "no framework by choice" style as the hospital SaaS. - Messaging
WhatsApp Business APItemplate messages, rendered through aTemplateParserand sent via a dedicatedWhatsAppServicewith its own exception type.- Multi-tenancy
TenantMiddlewareandTenantResolverscope every request, withTenantProvisionServiceonly running after an onboarding request is explicitly approved.- Reliability
- Every automated send — success or failure — writes an
ActivityLogentry with the specific reason, not a generic pass/fail flag.
The outcome
Honest about where it actually is.
Booking automation, payment automation, tenant onboarding with approval, and the activity-logging safety net are built. The messaging layer is explicitly in what the code itself calls "Temporary Test Mode" — currently sending through Meta's generic verified hello_world template while real, business-specific approved templates get mapped in. That's not a hidden gap; it's the honest next milestone before this can onboard a real paying tenant.
Running a booking-driven business, or building something that needs reliable WhatsApp automation done right?
Get in touch