Project: an omnichannel assistant that books, invoices and updates the CRM

Lena's busy evening. Meet Lena. She runs a small photography studio on her own. During the day she's out shooting, and by evening her phone is full. A bride on WhatsApp wants a Friday slot. A company on Telegram asks for last month's invoice. The calendar on her wall is out of date, and the bills she meant to send are still in a pile. Every hour she spends answering messages is an hour she isn't paid for. In this project lesson, we'll build her an assistant that answers on both apps, books the shoot, sends the invoice and updates her client records. It brings together everything from this module.

What you will build. By the end of this lesson you'll have three things working together. First, both messaging apps feed one agent workflow, so there's a single place to fix and improve. Second, the agent gets real tools through an MCP server. MCP, the Model Context Protocol, is a standard plug that lets an agent use outside apps, the way a USB port fits many devices. Here the tools are booking, invoicing and updating the CRM. A CRM, or customer relationship management tool, is just your client address book with notes and a status for each person. Third, the agent gets a shared memory and safety checks, so it never sends money-related messages blindly.

The whole system on one page. Here's the full picture before we build it. Lena's clients reach her through two front doors, WhatsApp and Telegram. Both doors lead into one n8n workflow, which hands every message to a single AI agent. Watch what happens when a message arrives from Sara asking for Friday. The agent first reads the memory to learn who Sara is and what she's booked before. Then it acts through the MCP server: it finds a free slot in the calendar, updates Sara's status in the CRM, and the reply travels back the same way it came. Notice the agent never talks to WhatsApp directly. That's what makes adding a third channel easy later.

Step 1: one entry workflow. Start with the entry. In n8n, add the WhatsApp webhook you set up in lesson two. A webhook is like a doorbell address: Meta rings it every time a message comes in. Next to it, add the Telegram trigger from lesson three. Both feed a node that normalizes the message, meaning it turns two different formats into the same few fields: channel, sender, text and any attachment. Then look up the customer ID. Sara's phone number and her Telegram ID both point to one client record. Take your time here, because every later step trusts these fields. If the lookup finds nobody, create a new lead instead of guessing.

Step 2: the agent's instructions. Now the agent itself. In n8n, the AI Agent node needs a system prompt, which is the standing job description it reads before every message. Keep it short and specific, like this one. It names the five tools the agent may use. It forces a confirmation before booking, so a vague "maybe Friday" never becomes a real appointment. It forbids invented prices and points to the price tool, because a model will happily make up a number if you let it. And it sets a money limit that needs Lena's approval. Write yours for your own client's business. A plumber, a tutor or a beauty salon would only change the tools and the price list.

Step 3: tools through MCP. In lesson five you saw how one MCP server can expose tools from dozens of platforms. Here we use exactly that. Connect the agent to an MCP server that has Google Calendar, your invoicing app such as Stripe or Zoho Invoice, and your CRM such as HubSpot. The nice part is that the agent discovers the tools and their inputs on its own, so you don't build a separate HTTP node for each action. Give each tool only the permissions it needs. The calendar tool can read and add events but shouldn't delete them, and the CRM tool can update a contact but shouldn't wipe your client list.

Worked example: Sara books and pays. Here's the whole flow traced step by step, with no code. Message one arrives in the morning on WhatsApp: Sara asks to book a shoot on Friday. The workflow finds her customer record from her phone number, and the memory shows two earlier shoots and nothing open. The agent checks the slots: ten o'clock is taken, two in the afternoon is free. Sara answers yes, so the agent books it and the CRM stage moves to booked. Message two arrives in the evening on Telegram, asking for her invoice. Her Telegram ID points to the same customer, so the memory already knows about the Friday booking. The invoice is a hundred and fifty dollars, under the limit, so it goes out without approval, and the CRM moves to invoiced. Finally, Telegram delivers that second message again. It carries the same action key, so it's simply ignored, and we'll see why in a moment. In your real build, the agent and MCP tools do these steps, but the shape is identical.

Shared memory, seen from the client's side. Let's look at it from Sara's side. In the morning she's on the sofa, chatting on WhatsApp about her shoot. In the evening she's at her desk and switches to Telegram, because that's what she has open. To her, it's one conversation with Lena's studio. What makes that possible is the notebook in the middle: the shared memory, keyed by her customer ID and not by the app. It stores a short summary, her booking and her CRM stage, rather than every single word. So what would happen if memory were keyed by phone number instead? The Telegram message would arrive as a stranger, and she'd have to explain everything again.

Step 4: safety before money. An assistant that touches money needs a human in the loop for the risky cases. Here's the rule. The agent drafts every invoice, but only small ones go straight to the client. Anything over three hundred dollars goes to Lena first: the Telegram node's send-and-wait option sends her Approve and Reject buttons and pauses the run until she taps one. Bookings get a similar check: the client must answer a clear yes to the date, time and package. Finally, log every action with the time, the channel and the tool used. When a client disputes a charge months later, that log is your evidence.

Common mistake: acting twice. Here's the trap that bites almost every first build. WhatsApp sometimes delivers the same message twice, and a slow tool call can make the agent retry. Without protection, Sara ends up booked into two slots, and the CRM fills with duplicate contacts. The fix has three parts. Check the calendar again right before booking, not just at the start of the chat. Search the CRM before creating a contact. And attach an idempotency key to each action. That's a unique ticket number, like a receipt number, so if the same action arrives twice, the second one is simply ignored.

Recap. Let's wrap up. First, every channel enters one workflow and talks to one agent, so you fix things once and add new channels cheaply. Second, the MCP server gives that agent its real abilities: checking and booking slots, sending invoices and moving clients through the CRM. Third, shared memory keyed by customer, approval steps for big invoices, and protection against double actions are what turn a demo into something you can confidently sell to a real business. Lena now gets her evenings back, and her clients get answers in minutes instead of the next morning.

Your exercise. Now it's your turn. Build this assistant for a small business you know, or use Lena's studio. Use the WhatsApp test number from lesson one, the webhook from lesson two and your Telegram bot from lesson three. Run three test conversations: one that books a slot, one that asks for an invoice, and one that starts on WhatsApp and continues on Telegram. Then send the same message twice on purpose and check that only one booking appears in the calendar. Finally, write down one thing that broke and how you fixed it. That note is the start of the demo story you'll tell your first paying client.