Customer lookup
Matches by name, email, or phone before taking action.
AI Project
Bob’s Bots Scheduling Assistant
A multi-channel AI assistant for service intake, scheduling, and business information retrieval.
Bob’s Bots is a customer-facing AI assistant built for a fictional robot repair business. It handles service inquiries, helps schedule repair appointments, and answers business questions in a way that is structured around a real workflow rather than just open-ended conversation.
Workflow AutomationSchedulingCustomer LookupService Intake
Appointment lifecycle
Books, updates, and cancels appointments with clear confirmation.
Availability checks
Confirms weekday business-hour slots before booking.
Business info answers
Keeps policy and shop questions inside supported knowledge.
What the assistant does
A practical service workflow, not a novelty bot.
The assistant is designed to help customers who need to schedule a robot repair service. It can guide the interaction from an initial inquiry through appointment booking, while also handling supporting tasks that make the process more useful and complete.
Its core flow includes:
- taking in customer service inquiries
- checking whether the customer already exists in the database
- asking whether a new customer should be added if no record exists
- recommending the first available 1-hour appointment slot between 9:00 AM and 5:00 PM on weekdays
- answering business questions using retrieval-augmented generation (RAG)
This gives the assistant a clear operational role. It is not just answering questions. It is helping move a customer through a real service workflow.
Workflow and orchestration
One conversational surface tied to real service operations.
IntakeLookup or createCheck availabilityBook / update / cancel
At the backend level, the project is built as an MCP-based workflow. That makes it flexible by design: instead of being tied to one front end, it can support different interface types depending on the use case.
For this site, the project is presented through a TypeScript chat interface connected to that workflow. The same backend pattern could also support other interfaces, including email-based workflows or voice-agent experiences.
That separation is an important part of the project. It reflects a more systems-oriented way of thinking about AI: not just designing a conversation, but designing a reusable service layer that different interfaces can connect to.
Tooling and systems
The site demo reflects the reference implementation and service logic.
The site demo is built around a chat interface that lets visitors interact with Bob’s Bots directly. It is designed to show how the assistant handles a realistic service flow, including appointment scheduling, customer lookup, and business questions.
This matters because the project is not just a concept. It is meant to be experienced as a working assistant through the site itself, with sensible guardrails in place to keep the public demo practical and low-risk.
A voice-based version is also possible, but I’m treating that as a separate demo available on request rather than embedding it directly into the site.
MCP-backed workflow
The reference implementation is structured as a reusable service layer rather than a one-off chat surface.
Scheduling and lookup logic
The assistant checks availability, matches customers, and keeps booking actions tied to identifiable records.
Multi-interface potential
The same workflow pattern can support chat, email, or voice-adjacent experiences.
Safe launch behavior
The on-site demo includes clear loading, success, and failure handling instead of exposing raw backend errors.
Live demo / current implementation
Try the scheduling workflow directly from the site.
The demo below is framed around service intake and appointment handling rather than a generic chat window. It makes the workflow clear before you start and shows the behind-the-scenes actions in a readable way.
Live demo
Try the scheduling flow
Start with booking, rescheduling, cancelling, or asking about shop policies. The assistant asks one question at a time and follows the service rules defined for the project.
Try asking
Workflow notes
- Bookings are one hour long between 9:00 AM and 5:00 PM on weekdays.
- No same-day bookings are allowed.
- Updates and cancellations require a matched appointment first.
Guardrails and service logic
Clear confirmation and business rules are part of the product.
Customer identity is matched before updates or cancellations happen.
Availability is checked before booking, with weekday business-hour rules applied.
The assistant asks one question at a time instead of guessing missing details.
Destructive actions like cancellation require explicit confirmation.
FAQ answers stay within supported business information rather than pretending to know everything.
When something fails, the interface falls back to a clear next step instead of surfacing raw errors.
Why this project matters
AI applied to a real service scenario with practical reuse behind it.
What interested me most about this project was the opportunity to build something practical. Rather than treating AI as a novelty interface, I wanted to create something that could handle real tasks, support real users, and be flexible enough to evolve across different interaction models.
It also reflects the way I tend to think about systems: not just in terms of the interface, but in terms of the workflow behind it, the logic supporting it, and the different ways people might interact with it.
Although Bob’s Bots is built around a robot repair business, the underlying structure is reusable. The same backend pattern could be adapted into other service assistants or repurposed into a more general scheduling or personal assistant model.
That flexibility is part of what makes the project meaningful to me. It is not just one assistant for one scenario. It is a reusable approach to building practical AI workflows.
Bob’s Bots reflects the kind of AI work I’m increasingly interested in: systems that are useful, structured, and built around real workflows. It combines practical automation with UX thinking and reusable backend design, and it shows how I approach AI not just as an interface, but as a service layer that can support different kinds of experiences.