BeautyOps: an AI receptionist and booking operating system for salons

BeautyOps is an AI-first receptionist and booking management platform built for beauty salons. The client came with a problem that most salon owners recognise immediately: the administrative layer of running a salon — answering enquiries, managing bookings, handling rescheduling, chasing deposits, sending reminders — consumes hours every week that should be spent on the business itself.

The ask was not a better booking form. It was a complete operational rethink. A platform that could handle the communication and scheduling layer of a salon automatically, integrating with the tools salons already use, without requiring the owner to manage another complex piece of software.

A beauty salon's front-of-house operation is deceptively complex. Enquiries come through Instagram DMs, WhatsApp, phone calls, and web forms simultaneously. Bookings sit across multiple systems — Square, Mindbody, Acuity, or Microsoft Bookings — depending on how the business has grown and which tools different staff members adopted at different times. Reminders go out manually or not at all. Deposit collection is a separate conversation. No-shows happen because the confirmation process is inconsistent. The owner ends up as the human glue holding together a system that was never designed to work as one.

For a single-location salon with a small team, this overhead is manageable but exhausting. At the point where a salon wants to scale — adding staff, extending hours, opening a second location — the manual process becomes the ceiling. Growth is limited not by demand but by the owner's capacity to manage scheduling and communication.

The deeper problem is that most booking software solves one part of this without addressing the whole. A booking widget handles online appointments but not the DMs. A reminder tool sends automated messages but does not handle rescheduling responses. An AI chatbot answers questions but does not connect to the actual booking system, and it responds the same way regardless of whether it is talking to a first-time visitor or a client of three years. The salon owner ends up managing four tools instead of one, and the administrative overhead barely decreases.

The platform was designed around a single principle: every communication and scheduling event that does not require a human decision should be handled automatically, and every human decision should be surfaced in one place.

The AI receptionist was built with long-term memory rather than a stateless question-and-answer system. Using RAG with pgvector embeddings, the receptionist learns the salon's voice from real conversations over time. It does not give the same generic response to every visitor. It responds the way that specific salon would respond, becoming more accurate with every interaction. The practical effect is a receptionist that sounds like the business rather than a support bot.

Rather than building a proprietary booking backend from scratch, the platform was built with pluggable connectors for the systems salons already use. Square, Mindbody, Acuity, and Microsoft Bookings each have a dedicated connector that pulls availability and pushes confirmed appointments back into the salon's existing system. This means a salon adopting BeautyOps does not have to migrate its booking data or retrain its staff. The platform layers on top of what is already there.

WhatsApp webhooks were added as a first-class integration rather than an afterthought, because WhatsApp is where a significant proportion of salon client communication actually happens. A system that does not handle WhatsApp does not handle the real communication pattern of the business.

The platform runs on Next.js 14 with TypeScript, Tailwind CSS, and shadcn-style UI components, hosted on Vercel. Authentication and role management are handled through Clerk. The database layer uses PostgreSQL with Prisma across a schema covering clients, bookings, services, reminders, jobs, payments, and audit events. Stripe handles deposit collection and payment webhooks. Resend handles transactional messaging. Sentry monitors server and client surfaces in production.

Booking creation is transactional at the database level, preventing double-bookings under concurrent load. Two clients booking the same slot simultaneously produces one confirmed booking and one clean rejection, not a conflict that has to be resolved manually. For a salon running peak-hour bookings through a public interface, that reliability is not optional. External automations connect through Make.com webhooks rather than hardcoded integrations, meaning SMS confirmations, WhatsApp follow-ups, and Google Calendar sync can be configured and modified without code changes.

The admin layer gives the salon owner a command centre view across the full operation: client management, booking CRUD, service configuration, availability settings, daily summary, reminder scheduling, and staff access. Every action that touches a booking or a payment generates a structured audit event.

The booking and webhook handling was built fail-closed. If a connector is unavailable, the system does not silently drop the booking. If a payment webhook arrives with an unexpected state, it does not process blindly. Rate limiting covers the public API routes to prevent abuse. The AI receptionist routes are scoped separately from the admin layer with explicit owner isolation.

The test suite covers 27 test files across unit, integration, and Playwright full-flow coverage. GitHub Actions CI runs on every push. Launch readiness documentation covers environment, Stripe, Clerk, Resend, and Vercel configuration in sequence so deployment is reproducible.

257 commits. 44 API routes. 33 pages covering public booking, confirmation, admin dashboard, services, clients, command centre, daily summary, settings, and legal.

The salon now has a single operational layer that handles enquiries, booking, confirmation, reminders, deposit collection, and rescheduling automatically across all the channels clients actually use. The owner's involvement is reserved for decisions that genuinely require a human — not for answering the same booking enquiry for the twelfth time that week.

What BeautyOps represents beyond this project is a replicable infrastructure. The connector architecture, the AI receptionist layer, and the admin operations model are all built to be extended to additional salons without rebuilding from scratch. The v1 scope was deliberately single-tenant and booking-first. The foundation it runs on is designed to scale beyond that.

The connector abstraction was introduced mid-build rather than specified in the architecture upfront. The final implementation is clean, but arriving at it required refactoring some early connector code that had been written before the pluggable pattern was formalised. Specifying the full connector interface and the availability/appointment contract before writing any connector implementation would have saved that rework and produced more consistent connector behaviour from the start.