Project: an AI appointment booking assistant ready to show a client

Lina's phone never stops. Meet Lina. She runs a small hair salon with one chair and a lot of loyal clients. Every day her phone fills up with messages: can I come Thursday, do you have anything after work, how much is a beard trim. Each reply means putting down the scissors, checking her paper diary, and typing back. Some messages wait three hours. Some never get answered, and those people book somewhere else. That's real money walking out the door. Today you'll build the thing Lina would happily pay for: an assistant that reads those messages, checks her calendar, books the slot or offers alternatives, and tells her what happened. This is the project that ties the whole module together.

What you will learn. Here's the plan for this lesson. First, you'll turn a messy client request into a clear design, so you know exactly what the assistant must do and what it must never do. Second, you'll build it step by step in n8n, using pieces from earlier lessons: a webhook to receive the chat, a free local model in Ollama to understand the message, Google Calendar to check availability, and Google Sheets plus email to keep Lina informed. Third, you'll package it so a real business owner can watch it work in two minutes and understand what they're buying. You already know every piece. Now we connect them.

The client brief as a picture. Before touching n8n, draw the job. On the left is the Customer, typing something like: can I get a haircut next Thursday morning. They don't use a form, they write normal sentences, with typos. In the middle is the Assistant, which is our workflow. Its job is to understand the request, ask for anything missing such as a name, and never invent an answer it can't back up. On the right is the Calendar, Lina's Google Calendar, which is the single source of truth. A slot is free only if the calendar says so. Write these three roles down for every automation project. It keeps the AI in its lane: it understands language, while the calendar decides facts.

The workflow at a glance. Here's the whole system. It starts when a customer types into the chat box on Lina's website, which sends the text to an n8n webhook, the trigger you met in lesson one. Now look at the helpers it calls: the Ollama model running on your own machine, Google Calendar, Google Sheets and email, all free at this size. Let's follow one booking request. The message goes to the model, which sends back neat fields. The workflow asks the calendar whether the slot is free, logs the booking in the sheet, emails Lina, and replies to the customer. Every arrow is a node you already know how to configure.

Step 1: words become fields. The first real step is extraction. Omar writes: hi, it's Omar, haircut next Thursday around ten please. In the AI node, your prompt tells the Ollama model to reply only with JSON, a simple format of named fields like the one on screen: intent, service, date, time, name and phone. Also put today's date into the prompt with n8n's now expression. Without it, the model has to guess what next Thursday means, and the date will often be wrong. Tell it to write null, meaning empty, when something is missing instead of guessing. Here the phone is missing, so the next node, an IF node, sees an empty field and sends a polite follow-up asking for a number. Only when every field is filled does the request move on to the calendar. Never let the model fill gaps with made-up details.

Step 2: find free slots. Now the calendar check. In n8n, a Google Calendar node fetches Thursday's events, and a small Code node works out what's free. This Python version shows the same logic. You don't need to write it yourself: you can paste it into the Code node as given. Lina works nine to five in one-hour slots, and ten, eleven and two are already booked. The function walks through the day hour by hour and keeps every slot that isn't taken. Omar wants ten, which is booked, so instead of a flat no, the line that starts with near sorts the free slots by how close they are to ten, and we offer the nearest three: nine, noon and one. That one small touch often turns a rejection into a booking.

Step 3: decide and reply. A Switch node now picks one of three paths. If the slot is free, the workflow creates the calendar event with the client's name and service, then replies: you're booked for Thursday at nine. If it's taken, it replies with the three nearest times and waits for the customer to pick one. The third path matters most for trust. If the model marked the intent as unclear, or the request is unusual, like a complaint or a group booking for a wedding, the workflow doesn't try to be clever. It tells the customer Lina will reply personally and forwards the message to her. Clients relax when they see the assistant knows its limits.

Step 4: log, notify, catch errors. Every confirmed booking gets appended as a row in a Google Sheet, so Lina has a record she can read without opening n8n. Here are three bookings so far, each with a date, client, service and price. One SUM formula gives her the booked revenue this week, a hundred and fifty dollars, and that number is often what makes an owner say yes. She also gets a short email per booking. Finally, attach the error workflow from lesson six: if Ollama is down or the calendar login expires, an Error Trigger emails Lina straight away and the customer gets a polite holding reply. Nothing fails silently.

Ready to show a client. A working workflow isn't yet a sale. Prepare a demo the owner can follow without knowing what a node is. Write three test messages: an easy booking that goes straight through, one that asks for a taken slot and gets alternatives, and an odd one, like a wedding party of eight, that's handed to a human. Record your screen for two minutes showing the chat, the calendar filling in, the sheet row and the email arriving. Then write one page: what it does, what it never does, and what it costs to run. The model itself is free because it runs locally, and the demo can run on your laptop. But a live assistant on Lina's website needs an always-on computer or a small server with a public address for the webhook, so put that hosting cost on the page too. Show that page and the owner sees a solved problem, not a tech project.

Common mistake: trusting the AI with facts. Here's the mistake that loses clients fastest. It's tempting to give the model the whole job: here's the message, write a nice reply. The model will cheerfully write, yes, Thursday at ten works, because that sounds helpful, even when the slot is taken. The result is a double booking: two customers, one chair, and an owner who switches your system off that afternoon. The fix is the rule from the brief. The model only turns words into fields and writes friendly text. Whether a slot exists is decided by the calendar node, every time. Keep facts in your tools, and language in the model.

Recap. Let's wrap up. First, design before you build: name the customer, the assistant and the source of truth, and write down what the assistant must never do. Second, give each part one job. The local model turns messy messages into fields, the calendar decides what's free, and anything unclear goes to the owner. Third, the extras are what make it sellable: a booking log with a weekly total, an email per booking, an error alert, and a short demo with a one-page summary. You've just built a complete, client-ready automation with free tools.

Your exercise. Before the next lesson, build this assistant for a real or imagined business you know well: a barber, a dentist, a tutor or a dog groomer. Use the webhook, the Ollama extraction step, a Google Calendar check, the three-way decision, the sheet log and the error workflow. Then run your three test messages: an easy booking, a taken slot and an odd request. Fix whatever breaks, because something will, and that's normal. Finally, record a two-minute demo and write the one-page summary. Keep both files. They're the first piece of your portfolio, and the thing you'll show your first paying client.