Telegram trigger
Receives an update from an opted-in chat.
Day 4 presentation1 / 28
Zero to MVP AI Bootcamp
Automation & the Telegram booking agent
Understand automation platforms, learn n8n, and build the first working version of a personal appointment agent on Telegram.
Today you ship
A consent-based Telegram agent in n8n that gathers booking requirements, contacts an approved provider chat, proposes an available slot, and confirms the user's choice.
Scroll to move through the presentation.
Learning objectives2 / 28
By the end of today
- 1Explain what automation platforms do and when to choose deterministic workflow steps instead of an AI agent.
- 2Compare n8n with familiar automation categories using control, hosting, connectors, cost, and governance.
- 3Build an n8n workflow with Telegram triggers, structured state, branches, retries, and execution evidence.
- 4Respect Telegram's consent model: a bot communicates only with users or provider chats that have started or approved it.
- 5Gather the minimum scheduling information for a doctor appointment without diagnosing or collecting unnecessary health data.
- 6Require user confirmation before sharing details or creating an appointment.
- 7Reuse the same booking workflow for a salon by changing its required fields, provider policy, and tools.
- 8Prevent duplicate provider messages and bookings when Telegram or n8n retries an event.
Run of show3 / 28
Today’s learning path
- Module 130 min
What automation tools do
- Module 235 min
Choose an automation platform
- Module 345 min
Build reliable workflows in n8n
- Module 440 min
Design the Telegram conversation
- Module 555 min
Build the doctor appointment flow
- Module 635 min
Reuse the agent for a salon
- Module 735 min
Make the automation trustworthy
- Guided build
AI Service Booking Marketplace · Stage 4
Build, test, checkpoint, and ship.
Module 1 · Learn · 30 min4 / 28
What automation tools do
Automation tools connect systems and execute repeatable work after a trigger. They are strongest when rules and steps are known. AI can interpret flexible language inside a workflow, but validation, consent, communication, booking, and recovery should remain explicit.
A real example
A Telegram message starts a workflow. The system validates the chat, extracts scheduling fields, asks for missing information, waits for consent, contacts an approved provider chat, and records the outcome.
Technical terms
- Trigger
- The event that starts a workflow, such as a Telegram update, schedule, webhook, or database change.
- Connector
- A packaged integration that lets an automation tool read from or act in another service.
Module 1 · Reference5 / 28
Choose the right kind of execution
| Concept | Best when | Booking example |
|---|---|---|
| Manual work | Judgment, empathy, or exceptions dominate | Clinic staff resolves an unusual request |
| Normal software | The rule must be predictable and immediate | Validate a date or authorized chat ID |
| Automation | Known steps connect several systems | Send, wait, record, remind, and retry |
| AI-assisted workflow | One step interprets variable language | Extract service and preferred dates from a message |
| Agent | The next approved action varies with context | Clarify missing details or choose a safe booking tool |
Module 1 · Apply it6 / 28
Apply the concept
Classify ten business tasks as manual work, normal software, deterministic automation, or an AI-assisted workflow.
- 1Choose one business process and identify its trigger and successful outcome.
- 2Separate known rules from steps that require interpretation or human judgment.
- 3List the systems, data, permissions, and failure paths involved.
- 4Choose manual work, normal software, automation, or AI assistance for each step.
Success looks like
Every step uses the least complex mechanism that can perform it reliably and safely.
Watch for
- Do not call a fixed sequence an agent merely because one step uses an LLM.
- Automating a poor or unauthorized process makes the problem faster rather than better.
Module 2 · Learn · 35 min7 / 28
Choose an automation platform
Automation platforms make different trade-offs. Hosted tools reduce operations, self-hostable tools increase control, workplace suites integrate with their ecosystems, and custom code provides precision at a higher engineering cost.
A real example
The workshop chooses n8n because the booking flow needs visible branches, webhooks, Telegram and HTTP integrations, reusable sub-workflows, execution history, and the option to control hosting.
Technical terms
- Low-code
- A visual development approach that combines configured building blocks with expressions or code when needed.
- Self-hosting
- Running and operating software in infrastructure controlled by your team.
Module 2 · Reference8 / 28
Automation platform landscape
| Concept | Typical strength | Important trade-off |
|---|---|---|
| n8n | Flexible visual workflows, APIs, code, and self-hosting option | You own more design and possibly operations |
| Zapier | Fast hosted business automation and broad app catalog | Complex flows and high volume can increase cost |
| Make | Visual data mapping and multi-step scenarios | Large scenarios need disciplined structure |
| Power Automate | Microsoft 365, Azure, and enterprise governance | Licensing and environment governance can be complex |
| Custom code | Maximum control, testing, and product integration | Highest engineering and maintenance responsibility |
Capabilities, plans, and limits change. Confirm current product documentation before selecting a platform.
Module 2 · Apply it9 / 28
Apply the concept
Score n8n, Zapier, Make, Power Automate, and custom code against this booking-agent requirement.
- 1Define required triggers, actions, data volume, latency, and reliability.
- 2List security, privacy, hosting, governance, and audit requirements.
- 3Estimate connector, execution, maintenance, and engineering costs.
- 4Prototype the riskiest integration before committing to a platform.
Success looks like
The platform choice is justified by requirements and operational ownership, not by the longest connector catalog.
Watch for
- Self-hostable does not mean maintenance-free; include upgrades, backups, availability, and security.
- Connector availability does not guarantee that every API feature or authentication mode is supported.
Module 3 · Learn · 45 min10 / 28
Build reliable workflows in n8n
An n8n workflow is a visible program. Nodes receive items, expressions map values, branches apply rules, credentials authorize integrations, and execution history shows what happened. Reliability comes from normalized input, durable state, idempotency, and explicit failure handling.
A real example
A Telegram Trigger receives an update. n8n validates the chat and update ID, normalizes text into a common event, loads conversation state, routes the next question, saves state, and sends one reply.
Technical terms
- Node
- One configured step in an n8n workflow, such as a trigger, condition, API call, transformation, or message.
- Idempotency key
- A unique event identifier used to ensure a repeated delivery does not repeat its business effect.
Module 3 · Diagram11 / 28
A reliable n8n message cycle
Every incoming update passes through control points before the workflow replies or acts.
1 2 Authorize
Checks chat identity, role, and permitted bot action.
3 Deduplicate
Rejects an update ID that was already processed.
4 Normalize
Creates one predictable internal event shape.
5 Load state
Reads the current conversation and pending approval.
6 Route
Chooses a deterministic question, wait, action, or error branch.
7 Save + reply
Commits the transition before sending one response.
8 Observe
Records outcome, timing, and safe diagnostic evidence.
Module 3 · Apply it12 / 28
Apply the concept
Build Telegram trigger → normalize → validate → route → reply, then replay the same update safely.
- 1Create the Telegram trigger and inspect a real update payload.
- 2Normalize chat ID, update ID, sender role, message, and timestamp.
- 3Reject unauthorized chats and already processed update IDs.
- 4Load state, route the event, save the new state, and send one response.
- 5Add bounded retry and error branches, then replay a duplicate update.
Use this prompt
Review this n8n Telegram workflow as a reliability engineer. Check authorization, normalized event shape, durable state, idempotency, bounded retries, timeout, error routing, credential use, and privacy-safe execution data. Explain failure modes before suggesting node changes.
Success looks like
The same Telegram update can be delivered twice while producing one state transition and one intended reply.
Watch for
- Pin sample data only for development and remove personal content before sharing or exporting the workflow.
- Do not use workflow memory alone for state that must survive restarts or concurrent executions.
Module 4 · Learn · 40 min13 / 28
Design the Telegram conversation
Telegram bot communication is permission-based. A bot cannot initiate a private conversation with an arbitrary phone number. The requester and provider must start the bot, add it to an approved chat, or otherwise provide a usable chat identity through an authorized onboarding process.
A real example
The requester starts the bot and asks for an appointment. The clinic has already started the provider bot or added it to an approved scheduling group. The workflow may message those verified chat IDs, but it cannot discover and contact a doctor merely from a phone number.
Technical terms
- Chat ID
- Telegram's identifier for a private chat, group, or channel used by the Bot API.
- State machine
- A defined set of conversation states and allowed transitions between them.
Module 4 · Diagram14 / 28
Two-party Telegram booking conversation
The workflow coordinates two opted-in chats and never treats a proposal as a confirmed booking.
1 Requester starts
The user starts the bot and submits an appointment goal.
2 Agent gathers
The workflow collects only required scheduling fields.
3 Share approval
The user reviews recipient and exact information to send.
4 Provider chat
An approved clinic or salon chat receives the request.
5 Slot proposal
The provider returns one or more available options.
6 User approval
The requester accepts one exact slot or declines.
7 Provider confirms
The provider records the appointment and returns confirmation.
8 Both notified
The final status and reference are sent to both parties.
Module 4 · Apply it15 / 28
Apply the concept
Map requester states, provider states, timeouts, cancellation, escalation, and consent checkpoints.
- 1Onboard requester and provider test chats and bind each chat ID to its role.
- 2Define states for intake, missing details, consent, provider response, user confirmation, completion, cancellation, and escalation.
- 3Define which actor may send each event in each state.
- 4Add timeouts and clear recovery messages for inactive users and providers.
Success looks like
Every message has an authorized sender, valid state transition, explicit recipient, and predictable next action.
Watch for
- A saved phone number is not permission or a Bot API destination.
- Do not accept provider confirmation from a chat ID that is not bound to the pending request.
Module 5 · Learn · 55 min16 / 28
Build the doctor appointment flow
The doctor workflow coordinates scheduling, not healthcare. It gathers the minimum information a clinic needs to offer an appointment, obtains consent before sharing, and redirects emergencies, diagnosis, treatment, or medication questions to appropriate human services.
A real example
The requester asks for a dermatologist next week in Cairo. The agent gathers visit type, preferred days, location, name, contact method, and an optional short scheduling note, then shows the exact clinic message before sending it.
Technical terms
- Data minimization
- Collecting and retaining only information necessary for the stated purpose.
- Explicit consent
- A clear affirmative agreement to a specific action after the person sees what will happen.
Module 5 · Apply it17 / 28
Apply the concept
Run the full requester → approved clinic chat → requester confirmation → booking confirmation journey.
- 1Collect specialty or appointment type, location, preferred dates, name, and contact method.
- 2If the user describes an emergency or asks for medical advice, stop booking assistance and direct them to qualified urgent support.
- 3Create a minimal provider message and show recipient, fields, and purpose to the requester.
- 4After explicit consent, send it to the approved clinic chat and await proposed slots.
- 5Show the exact slot to the requester, require confirmation, then obtain final clinic confirmation.
Use this prompt
Turn this doctor appointment request into scheduling fields only: appointment type or specialty, location, preferred dates and times, requester name, contact method, and optional short scheduling note. Ask one focused question at a time. Do not diagnose, triage, recommend treatment, or infer medical facts. Before sharing, display the exact recipient and fields and require explicit consent.
Success looks like
A clinic-confirmed appointment is created with minimum information and two explicit approvals: before provider contact and before booking the proposed slot.
Watch for
- Do not ask for symptoms when the clinic can schedule from appointment type alone.
- Emergency language must leave the automated booking path and provide an appropriate immediate human-help instruction for the user's location.
Module 6 · Learn · 35 min18 / 28
Reuse the agent for a salon
A reusable booking system separates universal coordination from service-specific policy. Request, consent, provider contact, slot proposal, user approval, confirmation, reminder, and cancellation remain shared. Required fields and provider rules change.
A real example
Salon mode asks for service, branch, stylist preference, approximate duration, preferred times, name, and contact method. It does not run the doctor-specific safety branch unless a health-related request enters the conversation.
Technical terms
- Configuration
- Data that changes system behavior without copying or rewriting the core workflow.
- Sub-workflow
- A reusable workflow called by other workflows for a focused responsibility.
Module 6 · Reference19 / 28
One booking engine, two service policies
| Concept | Doctor appointment | Salon appointment |
|---|---|---|
| Service need | Appointment type or specialty | Haircut, styling, color, or another service |
| Provider choice | Approved clinic or practitioner category | Branch and optional stylist |
| Time input | Preferred dates and times | Preferred dates, times, and service duration |
| Sensitive boundary | No diagnosis, treatment, or unnecessary health details | No invented prices, duration, services, or availability |
| Shared controls | Consent, proposal, confirmation, cancellation, retry | Consent, proposal, confirmation, cancellation, retry |
Module 6 · Apply it20 / 28
Apply the concept
Switch the agent to salon mode and complete one haircut or styling appointment without changing the core state machine.
- 1Move common booking states and provider messaging into reusable sub-workflows.
- 2Create a salon policy defining required fields, optional fields, provider chat, opening hours, duration, and cancellation rules.
- 3Map salon input into the shared provider-request schema.
- 4Complete one booking and prove doctor mode still behaves correctly.
Use this prompt
Create a salon booking configuration for the existing appointment workflow. Require service, branch or location, stylist preference if any, preferred dates and times, requester name, and contact method. Keep consent, provider proposal, user approval, confirmation, cancellation, idempotency, and timeout behavior shared.
Success looks like
The same core workflow completes a salon appointment by loading a different policy rather than duplicating the doctor workflow.
Watch for
- Do not fork the entire workflow for every service category.
- Provider-specific prices, durations, and availability must come from approved provider data or responses, not model invention.
Module 7 · Learn · 35 min21 / 28
Make the automation trustworthy
Messaging systems retry, people respond late, and providers change availability. Trustworthy automation records one event once, correlates both conversations, expires stale proposals, and leaves each participant in a clear state.
A real example
Telegram delivers the provider response twice. The workflow recognizes the update ID, records one proposal, and sends one approval request. If the proposal expires, confirmation is blocked and the provider is contacted again.
Technical terms
- Correlation ID
- A shared identifier connecting messages, workflow runs, provider proposals, approvals, and the final booking.
- Compensating action
- A controlled action that corrects or reverses an earlier step when the full workflow cannot complete.
Module 7 · Apply it22 / 28
Apply the concept
Test duplicate messages, provider silence, changed availability, user cancellation, and n8n restart.
- 1Assign one correlation ID and idempotency keys to each request and external event.
- 2Set expiry times for provider contact, proposals, approvals, and booking confirmation.
- 3Store state transitions before sending messages and reject invalid transitions.
- 4Test duplicate, delayed, out-of-order, cancelled, and failed events.
Success looks like
Every test reaches one explainable final or recoverable state without duplicate contact or booking.
Watch for
- A retry should repeat a technical attempt, not repeat the business outcome.
- If state and messaging disagree, pause the workflow and escalate rather than guessing.
Guided project23 / 28
Build brief
AI Service Booking Marketplace · Stage 4
Build the deterministic n8n and Telegram foundation for a personal agent that coordinates doctor and salon appointments.
User story
As a requester, I can describe the appointment I need, approve what is shared, review a provider's proposed slot, and explicitly confirm or cancel it.
Guided build · Part 124 / 28
Build it step by step
Create the Telegram bot
Register the bot securely and bind requester and approved provider test chats.
Build the n8n backbone
Normalize updates, load conversation state, route actions, and record idempotency keys.
Gather the request
Collect only the required doctor or salon scheduling fields and validate them.
Guided build · Part 225 / 28
Build it step by step
Request sharing consent
Show the exact provider message and wait for explicit requester approval.
Contact the provider
Send the request to the approved clinic or salon Telegram chat and capture proposed slots.
Confirm the slot
Ask the requester to accept or reject before creating the booking and notifying both parties.
Guided build · Part 326 / 28
Build it step by step
Prove reuse and recovery
Run both service types plus duplicate, timeout, cancellation, and retry cases.
Ship checkpoint27 / 28
Do not ship until
- The Telegram bot communicates only with requester and provider chats that opted in.
- The doctor flow coordinates scheduling only and clearly redirects emergencies or medical questions to appropriate human channels.
- No information is sent to a provider before the requester reviews and approves it.
- A provider proposal does not become a booking until the requester confirms.
- The same core workflow completes both doctor and salon appointment scenarios.
- Repeated Telegram updates do not duplicate provider messages or bookings.
- Timeout, cancellation, provider silence, and retry paths end in a clear recoverable state.
Wrap and prepare28 / 28
Ship it. Show it. Prepare the next move.
Before the next day
- Write the exact job, allowed tools, and prohibited actions for the custom agent.
- Prepare ten conversation cases covering both doctor and salon bookings.
- Mark every action that needs requester or provider confirmation.