Telegram to Google Calendar, bookings confirmed fast

Taxi bookings get “stuck” in NEW for a dumb reason: someone didn’t reply fast enough, picked the wrong provider number, or the chat session kept old state hanging around.

This hits dispatch teams first. But an ops manager watching service quality and a founder handling phones on weekends feel the same pain. Telegram Calendar booking automation fixes the handoff so rides get confirmed cleanly.

You’ll see how this n8n worker takes a Telegram selection, validates it, opens the booking in Postgres, optionally creates the Google Calendar ride, then resets Redis so the next request starts fresh.

How This Automation Works

The full n8n workflow, from trigger to final output:

n8n Workflow Template: Telegram to Google Calendar, bookings confirmed fast

Click to explore

flowchart LR

    subgraph sg0["Flow Flow"]
        direction LR
        n0@{ icon: "mdi:play-circle", form: "rounded", label: "Flow Trigger", pos: "b", h: 48 }
        n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "Input", pos: "b", h: 48 }
        n2@{ icon: "mdi:play-circle", form: "rounded", label: "Test Trigger", pos: "b", h: 48 }
        n3@{ icon: "mdi:swap-vertical", form: "rounded", label: "Test Fields", pos: "b", h: 48 }
        n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/redis.svg' width='40' height='40' /></div><br/>Reset Session"]
        n5@{ icon: "mdi:swap-vertical", form: "rounded", label: "Error Output", pos: "b", h: 48 }
        n6["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Set Open Booking"]
        n7["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Save User Memory"]
        n8["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/redis.svg' width='40' height='40' /></div><br/>Delete Route Data"]
        n9["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/redis.svg' width='40' height='40' /></div><br/>Delete Provider Number"]
        n10@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If Booking", pos: "b", h: 48 }
        n11@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If Not Zero", pos: "b", h: 48 }
        n12@{ icon: "mdi:swap-vertical", form: "rounded", label: "Cancel Output", pos: "b", h: 48 }
        n13["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/redis.svg' width='40' height='40' /></div><br/>Reset Session 2"]
        n14@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Switch", pos: "b", h: 48 }
        n15@{ icon: "mdi:swap-vertical", form: "rounded", label: "English", pos: "b", h: 48 }
        n16@{ icon: "mdi:swap-vertical", form: "rounded", label: "Chinese", pos: "b", h: 48 }
        n17@{ icon: "mdi:swap-vertical", form: "rounded", label: "Japanese", pos: "b", h: 48 }
        n18["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Booking"]
        n19@{ icon: "mdi:cog", form: "rounded", label: "Wait Call Back", pos: "b", h: 48 }
        n20@{ icon: "mdi:swap-vertical", form: "rounded", label: "Wait Output", pos: "b", h: 48 }
        n21@{ icon: "mdi:location-exit", form: "rounded", label: "Create Event", pos: "b", h: 48 }
        n22@{ icon: "mdi:cog", form: "rounded", label: "Call Back", pos: "b", h: 48 }
        n24["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Sync Booking Google Cal"]
        n1 --> n11
        n14 --> n16
        n14 --> n17
        n14 --> n15
        n18 --> n10
        n16 --> n22
        n15 --> n22
        n17 --> n22
        n10 --> n6
        n10 --> n5
        n11 --> n20
        n11 --> n18
        n11 --> n13
        n3 --> n1
        n20 --> n19
        n21 --> n24
        n5 --> n22
        n0 --> n1
        n2 --> n3
        n12 --> n22
        n4 --> n9
        n4 --> n8
        n4 --> n14
        n13 --> n12
        n13 --> n9
        n13 --> n8
        n6 --> n4
        n6 --> n7
        n6 --> n21
    end

    subgraph sg1["Flow 2"]
        direction LR
        n23["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/postgres.svg' width='40' height='40' /></div><br/>Delete Chat Memory"]
    end

    %% Styling
    classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
    classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
    classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
    classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef disabled stroke-dasharray: 5 5,opacity: 0.5
    class n0,n2 trigger
    class n10,n11,n14 decision
    class n4,n6,n7,n8,n9,n13,n18,n24,n23 database
    class n23 disabled
    classDef customIcon fill:none,stroke:none
    class n4,n6,n7,n8,n9,n13,n18,n24,n23 customIcon

The Problem: NEW Bookings That Never Become Real Rides

Most booking flows don’t fail loudly. They fail quietly. A Telegram chat collects a request, someone sends provider options, the customer replies “2”… and then nothing happens because the session state is wrong, the provider number isn’t valid for that route, or the booking record can’t be found in the database. Meanwhile, dispatch assumes it’s handled, the driver never gets assigned, and you’re stuck apologizing. Worse, your team starts “fixing it” by manually editing records and copying details into calendars, which adds errors and makes audits painful later.

The friction compounds. Here’s where it typically breaks down.

Bookings sit in NEW until someone remembers to chase the thread and flip the status by hand.
A single bad provider selection (or a “0” cancel) can poison the session, so the next message routes to the wrong logic.
Dispatch ends up maintaining two sources of truth, because the database says one thing and Google Calendar shows another.
Orphaned Redis keys and chat context accumulate, and weird edge cases show up right when volume spikes.

The Solution: Confirm the Booking, Sync the Calendar, Clear the Session

This workflow is built like a “worker” that waits for a call-center style trigger, then performs the real booking work reliably. It starts by taking the incoming Telegram session data (like chat ID, language, booking ID, and the customer’s provider selection number) and mapping it into consistent fields. Next it checks the input: “0” means cancel, and anything above 0 is treated as a provider selection that must be validated against the booking. If the booking is found and still eligible, the workflow updates Postgres to move the booking from NEW to OPEN, stores optional user context for future memory, then creates a matching Google Calendar event and syncs the calendar ID back into the database. Finally, it cleans up Redis keys and (optionally) chat history so the next request doesn’t inherit yesterday’s state.

The workflow starts when a message arrives from your upstream “Call In Center” flow (or your own trigger). Postgres is used to fetch and update the booking, Redis is used for session state and queues, and Google Calendar becomes the operational schedule your team trusts. Responses are returned to a callback sub-workflow, with language-aware replies (English, Japanese, Chinese).

What You Get: Automation vs. Results

What This Workflow Automates

Results You’ll Get

Validates provider selection input before it touches your booking records.
Moves booking status from NEW to OPEN in Postgres automatically.
Creates a Google Calendar ride event and writes the event ID back to the database.
Clears Redis session keys and queues so each chat starts clean.

Most teams save about 1–2 hours per day that used to go to manual “status fixing” and calendar entry.
Fewer missed rides because confirmations happen immediately after the customer chooses a provider.
Cleaner handoffs between chat, database, and dispatch scheduling.
Less “mystery behavior” from stale sessions because Redis is reset consistently.
Better customer experience, since cancel and error paths return a clear response fast.

Example: What This Looks Like

Say you handle about 30 Telegram bookings a day. Without automation, it’s common to spend maybe 5 minutes per booking fixing status, checking the database, and creating a calendar entry, which is about 2.5 hours daily. With this workflow, the dispatcher (or upstream bot) only needs to send the provider options, then the customer replies “1”, “2”, or “3” and the worker handles the rest in the background. Even if you assume a minute of oversight for edge cases, you’re getting roughly 2 hours back most days, plus fewer “where’s my taxi?” follow-ups.

What You’ll Need

n8n instance (try n8n Cloud free)
Self-hosting option if you prefer (Hostinger works well)
Telegram to receive provider selections and chat context.
Postgres for booking records, status updates, and memory.
Redis credentials (get it from your Redis host or managed Redis dashboard).

Skill level: Advanced. You’ll be comfortable wiring credentials, reading basic SQL tables, and adjusting session/state logic safely.

Don’t want to set this up yourself? Talk to an automation expert (free 15-minute consultation).

How It Works

A booking message arrives from your upstream flow. The worker is triggered by an Execute Sub-workflow Trigger (your “Call In Center” node, or any system that passes in the booking ID and the customer’s selection number).

Session and booking details are normalized. A field-mapping step consolidates the Telegram chat/session values into a consistent structure so downstream checks are predictable, even if your upstream bot changes later.

The input is validated, then the booking is opened. If the input is “0”, the workflow treats it as a cancellation and resets session state. If it’s 1 or above, Postgres is queried to fetch the booking record, an If condition confirms it’s a NEW booking under the same chat session, and then the status is updated to OPEN. Optional memory storage can write context for future support conversations.

Dispatch gets a calendar event, then the workflow cleans up. Google Calendar can be used to create a ride event, followed by a Postgres sync so the database stores the calendar reference. Redis cleanup deletes provider selection queues and route data, and replies are routed by language before a callback sub-workflow sends the final response.

You can easily modify the provider selection rules to match your own dispatch logic based on your needs. See the full implementation guide below for customization options.

Step-by-Step Implementation Guide

Step 1: Configure the Execute Workflow Trigger

Set up the entry points that start the workflow, including the main workflow trigger and the chat test trigger for development.

Add and open Workflow Start Trigger to accept executions from parent workflows.
Add and open Chat Test Trigger to enable chat-based testing of the flow.
Connect Workflow Start Trigger to Assign Input Fields, and Chat Test Trigger to Mock Field Mapper.

Step 2: Connect Postgres, Redis, and Google Calendar

These services store booking records, manage session cache, and create calendar events.

Open Fetch Booking Record and connect Postgres. Credential Required: Connect your Postgres credentials.
Open Mark Active Booking, Store User Context, Sync Booking to Calendar, and Utility: Clear Chat History and connect Postgres. Credential Required: Connect your Postgres credentials.
Open Clear Session Cache, Clear Session Cache 2, Remove Provider Cache, and Remove Route Cache and connect Redis. Credential Required: Connect your Redis credentials.
Open Create Calendar Event and connect Google Calendar. Credential Required: Connect your Google Calendar credentials.

⚠️ Common Pitfall: Leaving Postgres or Redis credentials unconfigured will cause the booking fetch and cache-clearing branches to fail silently, since several nodes use onError continue behavior.

Step 3: Set Up Input Mapping and Validation

Normalize incoming data for the booking flow and validate required fields.

Configure Mock Field Mapper to create test-friendly input fields during chat testing.
Configure Assign Input Fields to standardize input names expected by downstream nodes.
Set up Nonzero Check to validate that required inputs are present before the booking lookup.

Use Mock Field Mapper only for testing with Chat Test Trigger; keep Workflow Start Trigger aligned with production inputs.

Step 4: Configure Booking Lookup and Activation

Fetch the booking record and transition it into an active state when validation passes.

Configure Fetch Booking Record with your SQL query to retrieve booking data based on the mapped inputs.
Set up Booking Condition to determine if a valid booking was found.
Configure Mark Active Booking to update the booking status to active in your database.
Route errors from Booking Condition to Error Response Payload for user messaging.

Nonzero Check outputs to both Waiting Message and Fetch Booking Record in parallel, so make sure the input mapping is complete before this split.

Step 5: Configure Cache Clearing and Language Routing

Clear cached sessions and route replies by language.

Configure Clear Session Cache and Clear Session Cache 2 with the Redis keys you need to delete.
Set Remove Provider Cache and Remove Route Cache to remove any provider- and route-specific cache keys.
Configure Route By Language to switch on language codes and route to Chinese Reply, Japanese Reply, or English Reply.
Build language-specific payloads in Chinese Reply, Japanese Reply, and English Reply before sending to downstream workflows.

⚠️ Common Pitfall: Clear Session Cache outputs to Remove Provider Cache, Remove Route Cache, and Route By Language in parallel—ensure all three branches handle missing cache keys gracefully.

Step 6: Configure Sub-Workflow Calls and Calendar Sync

Send waiting messages, cancellation notices, and confirmation responses, then sync the booking into Google Calendar.

Set up Waiting Message and connect it to Run Sub-Workflow (Config Req) 1 for pre-processing or user feedback.
Configure Cancellation Payload and Error Response Payload to pass cancellation or error data into Run Sub-Workflow (Config Req) 2.
After Mark Active Booking, ensure Create Calendar Event creates the event and connects to Sync Booking to Calendar to store the calendar ID.
Note that Mark Active Booking outputs to Clear Session Cache, Store User Context, and Create Calendar Event in parallel, so each branch must handle the same booking payload.

Step 7: Test and Activate Your Workflow

Validate the execution paths and enable the workflow for production use.

Use Chat Test Trigger to run a manual execution and verify that Mock Field Mapper and Assign Input Fields populate the expected data.
Confirm that a successful run reaches Mark Active Booking, triggers cache clears, and creates a record in Sync Booking to Calendar after Create Calendar Event.
Test error and cancellation paths to ensure Error Response Payload and Cancellation Payload send to Run Sub-Workflow (Config Req) 2.
When satisfied, toggle the workflow to Active to enable production executions.

🔒

Unlock Full Step-by-Step Guide

Get the complete implementation guide + downloadable template

Common Gotchas

Postgres credentials can expire or need specific permissions. If things break, check the n8n credential test and your database user grants first.
If you’re using Wait nodes or external rendering, processing times vary. Bump up the wait duration if downstream nodes fail on empty responses.
Redis cleanup is powerful and easy to mis-scope. If you see unrelated sessions “reset,” verify the key prefix and chat/session IDs used in Reset Session and Delete Provider Number.

Frequently Asked Questions

How long does it take to set up this Telegram Calendar booking automation?

About 60–90 minutes once your Postgres, Redis, and Google credentials are ready.

Do I need coding skills to automate Telegram Calendar booking?

No, but you do need to be comfortable editing mappings and checking database fields. If you can follow a structured checklist and test a few scenarios, you’ll be fine.

Is n8n free to use for this Telegram Calendar booking workflow?

Yes. n8n has a free self-hosted option and a free trial on n8n Cloud. Cloud plans start at $20/month for higher volume. You’ll also need to factor in Google Calendar and database hosting costs (usually minimal), plus any OpenAI usage if you keep AI nodes active.

Where can I host n8n to run this automation?

Two options: n8n Cloud (managed, easiest setup) or self-hosting on a VPS. For self-hosting, Hostinger VPS is affordable and handles n8n well. Self-hosting gives you unlimited executions but requires basic server management.

Can I customize this Telegram Calendar booking workflow for multiple taxi providers and regions?

Yes, and it’s a common tweak. You can adjust the provider selection logic in the Nonzero Check and Booking Condition branches, then swap or extend the Postgres queries used in Fetch Booking Record and Mark Active Booking to match your own tables. Many teams also customize the Route By Language replies and the Google Calendar event fields (title, location, reminders) so dispatch sees exactly what they need at a glance.

Why is my Telegram connection failing in this workflow?

Usually it’s the Telegram bot token, webhook settings, or the upstream sub-workflow not passing the fields this worker expects. Check the Chat Trigger/Test Trigger mapping, then confirm the Assign Input Fields node is receiving chat ID, booking ID, and the selection number.

How many bookings can this Telegram Calendar booking automation handle?

A typical setup handles hundreds per day, and self-hosting scales further if your Postgres and Redis are sized correctly. On n8n Cloud, volume depends on your plan’s execution limits, but this workflow is lightweight per booking compared to heavy AI pipelines.

Is this Telegram Calendar booking automation better than using Zapier or Make?

Often, yes. This flow uses branching logic, database reads/writes, session cleanup in Redis, and sub-workflows, which is where Zapier/Make setups start getting fragile or expensive. n8n also lets you self-host, so you’re not paying per tiny step when volume grows. The tradeoff is you own more of the setup, and you will need to test edge cases like cancels, missing bookings, and duplicate sessions. If you want a second opinion before you commit, Talk to an automation expert.

Once confirmations and calendar sync happen automatically, dispatch stops living in the chat backlog. Set it up, test a few edge cases, and move on to the work that actually grows the operation.

Telegram to Google Calendar, bookings confirmed fast

How This Automation Works

n8n Workflow Template: Telegram to Google Calendar, bookings confirmed fast

The Problem: NEW Bookings That Never Become Real Rides