AI FrontDesk
From one-off bots to a platform for digital front-desk employees
Architecture and core backend in place. Hotel workflows near production-ready. Validated demand through demos and early clients.
Key Results
What AI FrontDesk Is
AI FrontDesk is my ongoing attempt to stop building one-off bots and instead create a reusable system for delegating front-desk jobs—answering calls, qualifying requests, booking, routing—to digital employees.
It’s where I combined domain-driven design, state machines, and everything I learned from unreliable tools and messy client work into a single architecture.
Context
After building several chatbots and voicebots for different businesses, I kept seeing the same pattern:
- They all did some flavor of “front desk” work: answer, ask a few questions, route, schedule, confirm
- Every implementation was custom, brittle, and hard to maintain
- Tools with “magic AI” hid state, cache, and behavior in ways I couldn’t control
I didn’t want to keep hacking together new flows for each client. I wanted a system where you define a job and deploy a digital employee to do it reliably.
Hotels were the first obvious use case: lots of repetitive calls, simple but critical workflows, and clear success criteria.
The Core Problem
Design a platform where you can consistently delegate specific operational jobs (like answering hotel calls) to AI agents, without rebuilding everything from scratch each time.
System Design
I treated AI FrontDesk as a domain-driven product:
- Domain: Front-of-house operations (hotels first, later generalizable)
- Jobs to be done:
- Answer calls and capture intent
- Qualify and collect necessary data
- Check availability / constraints
- Create or modify bookings
- Route edge cases to humans
Each “digital employee” is modeled as a state machine:
Greeting → IntentDetected → CollectingDetails → CheckingAvailability → Confirming → EndingCall
↓ ↓ ↓
Escalating ←──── (ambiguity / timeout / error) ────────────→ EscalatingClear transitions between states, with explicit handling for:
- Ambiguous answers
- Repetition / misunderstandings
- Timeouts and errors
Architecture pipeline:
- Jobs to be done → functional requirements
- Non-functional requirements (latency, reliability, observability)
- Bounded contexts and layers (core domain, integrations, interfaces)
- Choice of tech stack and design patterns to match those constraints
Implementation & My Role
This is a living system, but several concrete pieces are built:
Architecture & modeling
- Defined the domain model and main bounded contexts for front-desk work
- Chose state-machine-based agents as the core pattern after painful experience with cycling bots
Backend implementation
- Implemented backend services to run and track agent state
- Integrated with telephony/voice and messaging providers
- Wired logging and observability so I can see exactly what state an agent is in
Hotel prototypes
- Built voicebot flows for hotel use cases (availability checks, reservations)
- Engineered workarounds for missing APIs (including web automation for PMS where needed)
- Sold and onboarded initial clients using a “demo as minimum viable service” approach
Go-to-market experiments
- Used cold email and demo calls to validate that “unanswered calls” and “front-desk overload” are real, painful problems
- Offered no-setup-fee, first-month-test deals to reduce friction and learn quickly (and learned where that creates too much free labor)
Current Status & Reality
- The architecture and core backend are in place; several hotel-focused workflows are close to production-ready
- I’ve validated demand and pricing sensitivity through demos and early clients
- I also hit the limit of trying to be architect, backend engineer, salesperson, and implementation team all at once
This forced me to narrow scope, focus on a smaller set of front-desk jobs, and treat AI FrontDesk as a platform I build into over time, not a monolith I finish in one shot.
Key Learnings
Execution speed without architecture breaks down. The earlier bots I built moved fast but collapsed under complexity. AI FrontDesk is where I learned that architecture isn’t overhead—it’s the only way to move fast repeatedly.
Architecture without ruthless prioritization also kills momentum. It’s easy to design a beautiful system that never ships. Selling the demo as a minimum viable service exposed the real edge cases and forced me to cut scope.
State machines are non-negotiable for serious AI agents. After seeing voicebots loop and misbehave due to hidden state and cache, I committed to explicit states and transitions as the backbone of any agent I build.
You cannot build a platform and run a bespoke service business indefinitely as one person. AI FrontDesk taught me to separate reusable platform components from tightly scoped, high-value services on top of them.
Key Learnings
- Execution speed without architecture breaks down—earlier bots moved fast but collapsed under complexity
- Architecture without ruthless prioritization also kills momentum—selling the demo exposed real edge cases and forced scope cuts
- State machines are non-negotiable for serious AI agents—after seeing bots loop due to hidden state, I committed to explicit states and transitions
- You cannot build a platform and run a bespoke service business indefinitely as one person