Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
januari 22, 2026

Telegram + Postgres: ärende-ID och statustracking

Rickard Andersson Partner, Nodenordic.se

Dina supportärenden är troligen utspridda. Ett Telegram-meddelande här, en e-posttråd där, och ett “hann du ta den här?”-ping som dyker upp precis när du försöker få riktigt arbete gjort.

Här kommer Telegram Postgres tickets in. Småföretagare märker det först, men driftsansvariga och byråteam som kör kundsupport i chatten hamnar i samma röra. Du slutar tappa bort ärenden och får ett ticket-ID som folk kan hänvisa till utan att bråka om “vilket meddelande”.

Det här flödet gör Telegram till en lättviktig supportdesk som skapar strukturerade tickets i Postgres, bekräftar mottagandet direkt och låter vem som helst kontrollera status vid begäran. Du får se hur det fungerar, vad du behöver och var team vanligtvis går på minor.

Så här fungerar automationen

Hela n8n-flödet, från trigger till slutresultat:

n8n Workflow Template: Telegram + Postgres: ärende-ID och statustracking

Problemet: supportärenden försvinner i chatten

Telegram är snabbt, vilket är exakt varför det blir en fälla för support. Någon skickar en “snabb fråga”, du svarar när du hinner, och sedan begravs tråden under åtta andra konversationer. Två dagar senare följer samma person upp med “någon uppdatering?” och nu scrollar du, gissar och försöker komma ihåg vad du lovade. Det handlar inte bara om tid. Det är kontextbyten, missade överlämningar och den där ständiga låggradiga oron över att något viktigt halkade igenom.

Friktionen växer. Ett enkelt ärende blir en hel miniutredning.

  • Du kan inte hänvisa till ett ärende på ett tillförlitligt sätt, eftersom “det där meddelandet från i tisdags” inte är ett ticket-nummer.
  • Status finns i folks huvuden, så uppdateringar blir ping-pong i stället för en snabb kontroll.
  • Manuell kopiering till kalkylblad eller verktyg hoppas över när det blir mycket, vilket gör att ditt “system” faller isär precis när du behöver det.
  • När fler än en person hjälper till uppstår dubbelarbete, och ingen är säker på vad som redan är gjort.

Lösningen: gör Telegram-meddelanden till spårbara tickets

Det här n8n-flödet ger dig ett lättviktigt ticketsystem utan att betala full helpdesk-pris. En användare skickar ett kommando till en Telegram-bot (som /new) och flödet fångar upp ärendedetaljerna, normaliserar meddelandet och skapar en ticket-post i Postgres. Posten innehåller ett korrelations-ID, info om den som begär, en dedupe-nyckel (för att förhindra oavsiktliga dubbletter), plus status och tidsstämplar. Sedan svarar det direkt i Telegram med en kvittens och ticket-ID:t, så den som skickade in vet att det är registrerat. Senare kan vem som helst fråga efter status, och godkända operatörer kan uppdatera ticket-status på ett kontrollerat sätt med validering och behörighetskontroller.

Flödet börjar med intake i Telegram och en kommandorouter som avgör vad användaren försöker göra (skapa, kontrollera status, uppdatera eller adminåtgärder). Därefter blir Postgres “source of truth” och Telegram blir det strukturerade gränssnittet. Inget letande i chatthistorik.

Vad du får: automation vs. resultat

Exempel: så här kan det se ut

Säg att du får 15 supportärenden i veckan via Telegram. Manuellt är det lätt att lägga runt 10 minuter per ärende på att reda ut kontext, kopiera in detaljer i ett kalkylblad och senare hitta originalmeddelandet igen, vilket blir cirka 2,5 timmar per vecka. Med det här flödet tar registreringen ungefär en minut (skicka /new och svara på frågor), och statuskontroller tar sekunder eftersom de bara är databasuppslag. Även om du lägger lika mycket tid på att lösa problemen slutar du bränna de där extra timmarna på administration.

Det här behöver du

  • n8n-instans (prova n8n Cloud gratis)
  • Self-hosting-alternativ om du föredrar det (Hostinger fungerar bra)
  • Telegram för intake och svar
  • Postgres för att lagra tickets och revisionslogg
  • Telegram bot token (hämta den från @BotFather)

Kunskapsnivå: Medel. Du kopplar upp credentials och skapar en enkel Postgres-tabell, men du skriver ingen app.

Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).

Så fungerar det

Ett Telegram-kommando triggar flödet. Flödet startar när någon skickar ett meddelande till din Telegram-bot, vanligtvis med ett kommando som /new för att skapa en ticket eller ett statuskommando för att kolla progress.

Flödet routar och rensar input. En switch routar meddelandet baserat på kommando, sedan normaliserar flödet payloaden och skapar en hash-baserad dedupe-nyckel. Det gör att upprepade inskick eller “dubbeltryck” inte skapar skräpposter.

Postgres blir ticketsystemet. n8n gör upsert på ticket-posten (skapa eller uppdatera), skriver auditposter vid uppdateringar och hämtar ticket-ägarskap innan det svarar med känslig statusinformation. Behörighetskontroller hjälper till att förhindra att fel person redigerar eller ser en ticket.

Telegram förblir frontdörren. Den som skickar in får en kvittens med ticket-ID, status-svar returnerar på kommando, och admins kan lista nyligen skapade tickets direkt i Telegram utan att öppna ett separat verktyg.

Du kan enkelt ändra kommandon och statusvärden så att de matchar ditt arbetssätt. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: konfigurera Telegram-triggern

Konfigurera flödets startpunkt så att Telegram-meddelanden kan starta automatiseringen.

  1. Lägg till och öppna Telegram Intake Trigger.
  2. Ställ in Updatesmessage.
  3. Inloggningsuppgifter krävs: anslut era telegramApi-inloggningsuppgifter.
  4. Kopiera den genererade webhooken och slutför Telegram-botens setup i BotFather.

Steg 2: anslut centrala datatjänster (Postgres + Telegram)

Det här flödet använder flera Postgres- och Telegram-noder. Anslut inloggningsuppgifter en gång och återanvänd dem i alla noder.

  1. Öppna Upsert Ticket Record och anslut postgres-inloggningsuppgifter.
  2. Öppna Fetch Ticket Status, Modify Ticket Status, Fetch Ticket Owner, Insert Audit Entry, Log Workflow Error och List Recent Tickets och anslut samma postgres-inloggningsuppgifter.
  3. Anslut telegramApi-inloggningsuppgifter till alla Telegram-svarsnoder, till exempel Telegram Receipt Notice, Telegram Status Reply, Resolved Update Notice, Update Confirmation Message och Send Ticket List.

⚠️ Vanlig fallgrop: säkerställ att er Postgres-databas innehåller de tabeller/funktioner som krävs och som refereras i frågorna (t.ex. upsert_ticket, tickets, ticket_audit, workflow_errors).

Steg 3: konfigurera kommandorouting och välkomstflöde

Routern tolkar inkommande kommandon och skickar meddelandet till rätt flöde.

  1. Öppna Command Router Switch och bekräfta att kommandoreglerna använder {{ $json["message"]["text"].split(" ")[0].toLowerCase() }} för tolkning.
  2. Säkerställ att kommandoutgångarna mappar till /start, /status, /new, /update och /list, med fallback till Invalid Command Response.
  3. I Welcome Instructions, behåll Chat ID mappat till {{ $json.message.from.id }} och bekräfta att HTML-formatering är aktiverad.

Tips: om kommandon inte routas, kontrollera att inkommande text börjar med ett snedstreck och att Telegram-boten har rätt att läsa meddelanden.

Steg 4: sätt upp flödet för att skapa nya ärenden

Det här flödet normaliserar payloaden, genererar ett korrelations-id och gör en upsert av ärenderecorden.

  1. Öppna Normalize Payload & Hash och granska Python-kodens standardvärden, till exempel "requester_email": "[YOUR_EMAIL]" och "status": "new". Ersätt platshållarvärden vid behov.
  2. I Upsert Ticket Record, bekräfta att Query är inställd på funktionsanropet som infogar eller uppdaterar ärenden, och att query replacements mappar till värden som {{$json.correlation_id}} och {{$json.dedupe_key}}.
  3. I Telegram Receipt Notice, behåll Chat ID inställt på {{ $('Telegram Intake Trigger').item.json.message.from.id }} och verifiera att meddelandetexten innehåller {{ $json.correlation_id }}.

⚠️ Vanlig fallgrop: om ert meddelandeformat inte innehåller ”Name:”, ”Email:”, ”Subject:”, osv. kommer standardvärdena i Normalize Payload & Hash att användas. Uppdatera regex-mönstren om ni använder ett annat format.

Steg 5: konfigurera flödet för statusuppslag

Det här flödet validerar korrelations-id, hämtar status, kontrollerar ägarskap och svarar den som begärde ärendet.

  1. I Parse Status Request, bekräfta att den outputar correlation_id och chat_id från meddelandet.
  2. I Validate Correlation Format, behåll regex-kontrollen som ^[0-9a-fA-F-]{36}$.
  3. Konfigurera Check Correlation Present så att saknade id:n routas till Status ID Missing Alert och befintliga id:n till Fetch Ticket Status.
  4. I Fetch Ticket Status, behåll frågeparametern som {{ $json.correlation_id }}.
  5. I Confirm Ticket Ownership, verifiera jämförelsen mellan {{ $json["chat_id"] }} och {{ $('Telegram Intake Trigger').item.json.message.chat.id }} innan Telegram Status Reply skickas.

Varning: om korrelations-id är ogiltigt kommer Correlation Format Warning att triggas. Säkerställ att användare sparar korrelations-id som tillhandahålls av Telegram Receipt Notice.

Steg 6: konfigurera flödet för ärendeuppdatering med behörigheter och parallella notifieringar

Det här flödet verifierar operatörsbehörigheter, validerar statusvärden, uppdaterar ärendet och notifierar både operatören och ärendeägaren.

  1. I Parse Update Request, verifiera att den outputar correlation_id, new_status och chat_id.
  2. I Operator Permission Check, ersätt den hårdkodade [YOUR_ID] med den behöriga operatörens Telegram-id.
  3. I Validate New Status, behåll tillåtna värden new, in_progress och resolved.
  4. I Modify Ticket Status, bekräfta att query replacement är {{ $json.correlation_id }},{{ $json.new_status }}.
  5. Efter Insert Audit Entry, notera att Fetch Ticket Owner outputar till både Resolved Status Check och Update Confirmation Message parallellt.
  6. Säkerställ att Resolved Status Check routar till Resolved Update Notice eller In-Progress Update Notice baserat på status.

Tips: behåll Update Confirmation Message formaterat med {{ new Date($("Modify Ticket Status").item.json.updated_at).toLocaleString() }} så att operatörer ser en läsbar tidsstämpel.

Steg 7: konfigurera adminlistning av ärenden

Administratörer kan lista senaste ärenden via kommandot /list.

  1. I Admin Permission Check, ersätt [YOUR_ID] med adminens Telegram-id.
  2. Bekräfta att List Recent Tickets är inställd på frågan som returnerar de 10 senaste ärendena.
  3. I Format Ticket List, behåll JS-koden som formaterar listan och använder {{ $("Telegram Intake Trigger").item.json.message.from.id }} för chat-id.
  4. Säkerställ att Send Ticket List använder {{ $json.text }} för meddelandet och {{ $json.chat_id }} för mottagaren.

Steg 8: lägg till felhantering och felloggning

Dessa noder upptäcker misslyckade notifieringar eller databasfel och loggar dem till Postgres.

  1. I Status DB Error Check, behåll den booleska kontrollen {{ !!$json.error }} och routa till Status DB Error Reply om den är true.
  2. I Operator Reply Error Check och Notify Failure Check, behåll felkontrollerna och skicka larm eller logga fel enligt konfiguration.
  3. I Log Workflow Error, verifiera att query replacement inkluderar {{ $workflow.id }}, {{ $execution.id }} och {{ JSON.stringify($json) }}.

Varning: flödet har ingen global error trigger, så dessa kontroller är ert enda skyddsnät. Ta inte bort Log Workflow Error om ni inte lägger till en annan loggningsmetod.

Steg 9: testa och aktivera ert flöde

Kör ett fullständigt end-to-end-test innan ni aktiverar flödet för produktionsanvändning.

  1. Klicka på Execute Workflow och skicka ett /new-meddelande i Telegram för att skapa ett ärende.
  2. Bekräfta att Telegram Receipt Notice returnerar ett korrelations-id och att Upsert Ticket Record infogar ett ärende i Postgres.
  3. Skicka /status och verifiera att Telegram Status Reply innehåller status och tidsstämplar.
  4. Skicka /update resolved som operatör och bekräfta att Update Confirmation Message och Resolved Update Notice levereras.
  5. När allt är validerat, slå på flödet till Active för produktionsanvändning.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • Telegram-credentials kan löpa ut eller få fel scope. Om svar slutar fungera, kontrollera bot-token i n8n Credentials och bekräfta att boten fortfarande finns i @BotFather.
  • Om du använder Wait-noder eller extern rendering varierar processtider. Öka väntetiden om efterföljande noder fallerar på tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du redigera outputs i all evighet.

Vanliga frågor

Hur lång tid tar det att sätta upp den här automationen för Telegram Postgres tickets?

Cirka 45 minuter om Postgres redan är på plats.

Behöver jag kunna koda för att automatisera Telegram Postgres tickets?

Nej. Du kommer främst koppla konton och klistra in det medföljande Postgres-tabellschemat.

Är n8n gratis att använda för det här Telegram Postgres tickets-flödet?

Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer startar på 20 USD/månad för högre volym. Du behöver också räkna in hostingkostnader för Postgres, som ofta ligger på 5–20 USD/månad för en liten VPS.

Var kan jag hosta n8n för att köra den här automationen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och klarar n8n bra. Self-hosting ger dig obegränsade exekveringar men kräver grundläggande serverhantering.

Kan jag anpassa det här Telegram Postgres tickets-flödet för intake via e-post i stället för Telegram?

Ja, och det är en vanlig uppgradering. Du kan lägga till noden Gmail Trigger som en andra intake-väg, mappa avsändare/ämne/brödtext in i samma steg “Normalize Payload” och behålla Postgres-upsert exakt som den är. Många team skickar också kvittensen via Gmail, samtidigt som de fortfarande tillåter statuskontroller i Telegram.

Varför fungerar inte min Telegram-anslutning i det här flödet?

Oftast är det bot-token eller att fel Telegram-credential är vald i en nod. Generera om token i @BotFather, uppdatera den i n8n Credentials och bekräfta att boten kan ta emot meddelanden i chatten du testar. Om status-svar fallerar men ticket-skapande fungerar, kontrollera att chat_id sparas i Postgres och returneras korrekt för svar. Håll också koll på Telegrams rate limits om du börjar skicka admin-notiser till stora grupper.

Hur många tickets klarar den här automationen för Telegram Postgres tickets?

För ett litet team: i praktiken många; Postgres hanterar tusentals tickets utan problem, och n8n-kapaciteten beror på din plan eller serverstorlek.

Är den här automationen för Telegram Postgres tickets bättre än att använda Zapier eller Make?

Ofta, ja, eftersom det här flödet inte bara är “skapa en rad”. Det innehåller grenad kommandohantering, dedupe-logik, behörighetskontroller och flera Postgres-läsningar/skrivningar, vilket är den typen av logik som snabbt blir pillig (och dyr) i enklare automationsverktyg. n8n låter dig också self-hosta, så du slipper bevaka task-volymer varje gång statuskontrollerna sticker iväg. Zapier eller Make kan fortfarande fungera om du bara vill ha envägs-intake till ett kalkylblad och inte behöver säkra statusuppdateringar. Om din process inkluderar operatörer, ägarskap och en riktig audit trail är n8n en mer naturlig match. Prata med en automationsexpert om du vill ha hjälp att välja.

När detta är live slutar du behandla support som en skattjakt. Flödet gör ärenden spårbara, sökbara och enkla att uppdatera, så teamet kan fokusera på att lösa problem i stället för att jaga dem.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Launch login modal Launch register modal