Din taxiinkorg fylls snabbt. Ena minuten är det ”hämtning nu”, nästa är det ”vad kostar det till flygplatsen”, och ändå hänger varje svar på att någon letar i gamla prislistor och gissar vilken leverantör som är tillgänglig.
Den här Postgres Telegram booking-automationen slår hårdast mot dispatchansvariga, men driftansvariga och små flottägare känner av det också. Du vill ha offerter som är konsekventa, bokningar som loggas och färre ”sorry, fel leverantör”-ögonblick som kostar förtroende.
Det här n8n-flödet omvandlar inkommande körförfrågningar i Telegram till en offert matchad mot rätt leverantör och en ny bokningspost, med Postgres-data plus Redis-cachning. Du får se vad det gör, vad du behöver och var team vanligtvis kör fast.
Så fungerar den här automationslösningen
Hela n8n-flödet, från trigger till slutresultat:
n8n Workflow Template: Postgres + Telegram: snabbare taxiofferter
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@{ icon: "mdi:robot", form: "rounded", label: "AI Agent", pos: "b", h: 48 }
n5["<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/code.svg' width='40' height='40' /></div><br/>Code"]
n6@{ icon: "mdi:brain", form: "rounded", label: "xAI @grok-2-1212", pos: "b", h: 48 }
n7@{ icon: "mdi:database", form: "rounded", label: "Create Booking Data", pos: "b", h: 48 }
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/>Provider Number"]
n9@{ icon: "mdi:wrench", form: "rounded", label: "Calculator", pos: "b", h: 48 }
n10@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If Active", pos: "b", h: 48 }
n11["<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/>Provider Cache"]
n12["<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/>Load Provider Data"]
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/>Save Provider Cache"]
n14["<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/code.svg' width='40' height='40' /></div><br/>Parse Provider"]
n15@{ icon: "mdi:swap-vertical", form: "rounded", label: "Provider", pos: "b", h: 48 }
n16@{ icon: "mdi:swap-vertical", form: "rounded", label: "Error Output1", pos: "b", h: 48 }
n17@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If Score", pos: "b", h: 48 }
n18@{ icon: "mdi:swap-vertical", form: "rounded", label: "Output w/ Score", pos: "b", h: 48 }
n19@{ icon: "mdi:swap-vertical", form: "rounded", label: "Output w/o Score", pos: "b", h: 48 }
n20@{ icon: "mdi:swap-horizontal", form: "rounded", label: "If Valid?", pos: "b", h: 48 }
n21@{ icon: "mdi:swap-vertical", form: "rounded", label: "Test Output", pos: "b", h: 48 }
n22@{ icon: "mdi:cog", form: "rounded", label: "Call Back", pos: "b", h: 48 }
n23@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Provider Cache Switch", pos: "b", h: 48 }
n5 --> n20
n5 --> n16
n1 --> n11
n4 --> n5
n4 --> n16
n17 --> n18
n17 --> n19
n15 --> n8
n10 --> n13
n10 --> n21
n20 --> n17
n20 --> n21
n9 -.-> n4
n3 --> n1
n0 --> n1
n2 --> n3
n16 --> n22
n14 --> n15
n11 --> n23
n18 --> n22
n8 --> n4
n19 --> n22
n6 -.-> n4
n12 --> n10
n7 -.-> n4
n13 --> n15
n23 --> n14
n23 --> n12
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 n4 ai
class n6 aiModel
class n9 ai
class n10,n17,n20,n23 decision
class n7,n8,n11,n12,n13 database
class n5,n14 code
classDef customIcon fill:none,stroke:none
class n5,n8,n11,n12,n13,n14 customIcon
Problemet: långsamma, inkonsekventa taxi-offerter som inte konverterar
Manuell offertgivning låter enkelt tills du gör det hela dagen. En körförfrågan kommer in i Telegram, du kopierar detaljerna, du letar upp rätt leverantör och sedan försöker du prissätta konsekvent (högtrafik, antaganden om sträcka, bagageregler, ”är det zon A eller B?”). Under tiden väntar kunden, och varje minut ökar risken att de skriver till ett annat bolag. Än värre: olika medarbetare ger olika svar, vilket skapar diskussioner vid upphämtning och återbetalningar senare. Och om bokningar inte loggas strukturerat blir morgondagens dispatch ett gissningsspel.
Friktionen byggs på. Här brukar det oftast fallera.
- En enda offert kan ta 10 minuter när du räknar in leverantörsuppslag, prissättning och att skriva ett korrekt formaterat svar.
- Val av leverantör baseras ofta på minnet, så fel bolag erbjuds (eller ett inaktivt).
- Bokningar ”spåras” i chatthistoriken, vilket gör att detaljer försvinner så fort någon scrollar förbi dem.
- När volymen ökar sjunker först svarskvaliteten, och sedan följer konverteringsgraden efter.
Lösningen: Telegram-förfrågningar matchas mot leverantörer, offereras och bokas
Det här flödet fungerar som en leverantörsnära hjärna för din taxiverksamhet. Det tar emot en körförfrågan (oftast vidarebefordrad från ett överordnat ”Taxi Service Workflow” via en Execute Sub-workflow Trigger, eller direkt från en chatt-trigger i demoläge). Därefter kontrollerar det Postgres för rätt leverantörsdetaljer och använder Redis som cachelager så att du inte belastar databasen med upprepade uppslag. När leverantörsdata är redo skapar en AI-agent (med en OpenAI Chat Model eller annan modell som stöds) en konsekvent offert- och bekräftelsetext baserat på leverantörens regler. Till sist skriver flödet en ny bokningspost tillbaka till Postgres och skickar svaret tillbaka till det anropande flödet för leverans.
Flödet startar med en meddelandepayload som kommer in från Telegram eller ett annat flöde. Det skickar förfrågan via cache eller databashämtning, validerar AI-utdata, kan vid behov poängsätta det och returnerar sedan ett korrekt formaterat svar samt en bokningsloggpost. Om leverantören är inaktiv gör det ingenting på ett säkert sätt i stället för att skapa felaktiga bokningar.
Det här får du: automation vs. resultat
| Vad flödet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut i praktiken
Säg att du hanterar 20 körförfrågningar via Telegram per dag. Manuellt, om varje offert tar cirka 10 minuter (leverantörsuppslag, prissättning, skriva svaret och sedan logga bokningen), blir det ungefär 3 timmar rutinjobb dagligen. Med det här flödet är triggern omedelbar, leverantörsuppslag går via cache och AI:n utkastar offerten på under en minut, så en dispatcher granskar mest och trycker skicka. Du får tillbaka cirka 2 timmar varje dag, och dina bokningar ligger redan i Postgres.
Det här behöver du
- n8n-instans (prova n8n Cloud gratis)
- Självhostat alternativ om du föredrar det (Hostinger fungerar bra)
- Telegram för att ta emot och skicka körmeddelanden
- Postgres för leverantörsdata och bokningsposter
- Redis för att cacha leverantörer och snabba upp routning
- OpenAI API-nyckel (hämta den i din OpenAI-dashboard)
Kunskapsnivå: Avancerad. Du konfigurerar credentials, SQL-tabeller och finjusterar AI-prompten så att den matchar dina pris- och bokningsregler.
Vill du inte sätta upp det här själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
En förfrågan träffar flödet. Körningen startar när ditt ”Taxi Service Workflow” anropar det här leverantörsflödet (Execute Sub-workflow Trigger), eller när en Telegram-chatt-trigger triggar i demoläge. Den inkommande payloaden mappas till konsekventa fält så att senare steg inte skapar fel.
Leverantörsdata hämtas snabbt. Först kontrolleras Redis (Provider Cache Read), vilket gör att vanliga leverantörer kan lösas utan en databastripp. Om cachen missar hämtar flödet leverantörsdetaljer från Postgres och sparar dem sedan tillbaka i Redis till nästa gång.
Offert- och bokningslogik körs. Flödet bekräftar att leverantören är aktiv, ökar ett leverantörsnummer i Redis för urval och skickar strukturerad kontext till en AI-agent. Ett kalkylatorverktyg finns tillgängligt för prisberäkningar, och agenten tar fram en offert samt bokningsdetaljerna som ska registreras.
Svar valideras och returneras. Utdata transformeras och kontrolleras, och kan vid behov poängsättas (så att du kan avgöra när kvalitetsbedömning ska ingå i svaret). Om det är giltigt skapas en bokningspost i Postgres och en slutlig payload skickas tillbaka till det anropande flödet för leverans via Telegram.
Du kan enkelt ändra reglerna för leverantörsmatchning för att stödja flera flottor, zoner eller servicenivåer utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: Konfigurera triggern Execute Workflow
Det här arbetsflödet kan starta från ett överordnat arbetsflöde eller via chatinmatning, så konfigurera båda ingångarna.
- Lägg till och konfigurera Workflow Start Trigger för att ta emot indata från ett överordnat arbetsflöde.
- Konfigurera Chat Demo Trigger för att möjliggöra chattbaserad testning och demos.
- Koppla Chat Demo Trigger till Map Demo Fields så att chatt-payloads normaliseras innan bearbetning.
- Säkerställ att Workflow Start Trigger skickar utdata direkt till Assign Input Fields.
Steg 2: Anslut Redis- och Postgres-tjänster
Det här arbetsflödet använder Redis för cache och Postgres för hämtning av leverantörsdata och skapande av bokningsposter.
- Öppna Provider Cache Read och anslut er Redis-instans.
- Öppna Lookup Provider ID och anslut samma Redis-inloggningsuppgifter för att slå upp leverantörs-ID:n.
- Öppna Store Provider Cache och anslut Redis-inloggningsuppgifter för att skriva tillbaka till cachen.
- Öppna Retrieve Provider Data och anslut era Postgres-databasinloggningsuppgifter.
Steg 3: Konfigurera AI Orchestrator
AI-lagret använder en agent med en Grok-språkmodell samt verktyg för matematik och databasinserts för bokningar.
- Öppna AI Orchestrator och konfigurera agentens instruktioner samt förväntade in-/utdatafält.
- Koppla Grok Chat Model som språkmodell för AI Orchestrator.
- Koppla Math Utility Tool och Generate Booking Record som AI-verktyg för AI Orchestrator.
- Bekräfta exekveringsflödet Lookup Provider ID → AI Orchestrator → Transform Script.
Steg 4: Konfigurera cachelagring och parsning av leverantörsdata
Arbetsflödet läser först från cache, faller tillbaka till Postgres och parsar samt mappar därefter leverantörsfält.
- Säkerställ att Assign Input Fields skickar utdata till Provider Cache Read.
- Konfigurera Cache Routing Switch för att routa cacheträffar eller cachemissar till Parse Provider Data respektive Retrieve Provider Data.
- Bekräfta att Retrieve Provider Data skickar utdata till Check Provider Active för filtrering på tillgänglighet.
- Koppla Store Provider Cache till Set Provider Fields så att nyhämtad data cachas och mappas.
- Validera att Parse Provider Data skickar utdata till Set Provider Fields.
Steg 5: Konfigurera transformering, validering och poängsättning
Efter AI-bearbetning transformeras, valideras och poängsätts svaren innan routning.
- Öppna Transform Script och bekräfta att det normaliserar AI-utdata för validering.
- Verifiera att Transform Script routar till Validate Response vid lyckat resultat och till Error Response Payload vid fel.
- Konfigurera Validate Response så att giltiga resultat skickas till Evaluate Score och ogiltiga till Demo Output Payload.
- Ställ in logiken i Evaluate Score för att välja mellan Respond With Score och Respond Without Score.
Steg 6: Konfigurera utskick av svar och körning av underarbetsflöde
Slutliga svar routas vidare till ett nedströms arbetsflöde för leverans.
- Bekräfta Respond With Score → Run Sub-Workflow (Configure Required).
- Bekräfta Respond Without Score → Run Sub-Workflow (Configure Required).
- Bekräfta Error Response Payload → Run Sub-Workflow (Configure Required).
- Öppna Run Sub-Workflow (Configure Required) och välj målarbetsflödet för leverans av svar.
Steg 7: Testa och aktivera ert arbetsflöde
Validera varje väg (cacheträff, cachemiss, felhantering och poängsättning) innan ni går live.
- Klicka på Execute Workflow med Workflow Start Trigger och verifiera att data når Provider Cache Read och Cache Routing Switch.
- Testa Chat Demo Trigger för att säkerställa att Map Demo Fields → Assign Input Fields skickar korrekta payloads.
- Verifiera att lyckade AI-utdata når Respond With Score eller Respond Without Score och kör Run Sub-Workflow (Configure Required).
- Kontrollera att fel i AI Orchestrator eller Transform Script flödar till Error Response Payload.
- Växla arbetsflödet till Active när testerna är lyckade.
Vanliga fallgropar
- Postgres-credentials kan löpa ut eller kräva specifika behörigheter. Om något slutar fungera, kontrollera dina n8n-credential-inställningar och bekräfta att användaren kan läsa leverantörstabeller och lägga in bokningsrader.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om noder längre fram fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in din tonalitet tidigt, annars kommer du att redigera utdata för alltid.
Vanliga frågor
Räkna med cirka 2 timmar om dina Postgres-tabeller och credentials är klara.
Nej, men det blir enklare om du kan läsa grundläggande SQL. Det mesta handlar om att koppla credentials, mappa fält och finjustera AI-prompten.
Ja. n8n har ett gratis självhostat alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in kostnader för OpenAI API, som vanligtvis ligger på några cent per konversation beroende på meddelandelängd.
Två alternativ: n8n Cloud (hanterat, enklast uppsättning) eller självhosting på en VPS. För självhosting är Hostinger VPS prisvärd och hanterar n8n bra. Självhosting ger dig obegränsade körningar men kräver grundläggande serverhantering.
Ja, och ärligt talat är det här mallen verkligen glänser. Du kan byta leverantörstabellen som flödet läser från (standard är en sys_provider-liknande setup) genom att justera Postgres-hämtningssteget och parsningen/kodmappningen som gör rader till prompt-klara fält. De flesta team anpassar AI-agentens instruktioner så att offertformat, tilläggsavgifter och bekräftelsetext matchar varumärket. Du kan också duplicera flödet per leverantör och använda Redis-mönstret ”provider number” för att rotera eller välja leverantörer utifrån din egen logik.
Oftast är det ett problem med bot-token, eller att boten inte får skicka meddelanden till chatten du testar med. Återanslut Telegram-credentials i n8n, bekräfta att boten är tillagd i gruppen (om du använder grupper) och kontrollera trigger-nodens behörigheter för uppdateringar.
Om du self-hostar finns ingen hård gräns för antal körningar; kapaciteten beror främst på din server och databas. På n8n Cloud beror dina månatliga körningar på plan, och team med hög volym uppgraderar vanligtvis när de ser en stabil efterfrågan.
För den här typen av flöde är n8n oftast ett bättre val eftersom du kan göra förgrenad logik, databasläsningar/skrivningar, cachning med Redis och orkestrering av AI-agent på ett ställe utan att bygga sköra kedjor av zaps. Det stödjer också självhosting, vilket spelar roll när du hanterar många förfrågningar och vill undvika överraskningar med per-uppgift-prissättning. Zapier och Make fungerar fortfarande om flödet verkligen är enkelt, som ”Telegram-meddelande → skicka ett standardsvar”, men det är inte offert och bokning. Om du tvekar, prata med en automationsexpert och beskriv din förfrågningsvolym och leverantörskomplexitet. Du får ett rakt svar.
Snabbare svar vinner körningar. Och när varje bokning landar i Postgres automatiskt slutar du slösa tid på administration som aldrig borde ha varit manuell.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.