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

Postgres + Stripe: churn-riskmejl via Gmail

Rickard Andersson Partner, Nodenordic.se

Din lista över “kunder i riskzonen” är troligen ett enda kaos. Användningsdata finns i Postgres. Faktureringskontexten finns i Stripe. Och den faktiska outreachen sker… när någon kommer ihåg att göra det.

Den här automatiseringen för Stripe churn-mejl träffar SaaS-grundare först, eftersom retention är syre. Men marknadschefer och kundnära ops-team känner också av det. Du får ett konsekvent flöde för churn-riskmejl som drivs av verkliga användningssignaler, inte magkänsla.

Den här guiden bryter ner exakt n8n-flöde: hämta kundmått från Postgres, berika med Stripe-data och skicka sedan rätt Gmail-meddelande till rätt segment automatiskt.

Så fungerar automatiseringen

Här är hela flödet du kommer att sätta upp:

n8n Workflow Template: Postgres + Stripe: churn-riskmejl via Gmail

Varför det här spelar roll: churn-signaler missas (tills det är för sent)

Churn händer sällan “på en gång”. Det visar sig som ett mönster: färre inloggningar, en nyckelfunktion slutar användas, antal platser minskar, fakturor börjar fallera eller en plan nedgraderas i det tysta. Det jobbiga är att du oftast har datan, bara inte på samma ställe vid samma tidpunkt. Så du jagar symptom i kalkylblad, plockar fram Stripe-detaljer vid begäran och skriver “ville bara kolla läget”-mejl som landar för sent för att göra skillnad. Och ärligt talat: när arbetssättet blir reaktivt är det svårt att ta sig ur.

Det blir mycket snabbt. Här är var det brister i riktiga team.

  • Någon måste manuellt hämta användningsmått från Postgres, vilket blir en veckoritual som ingen gillar.
  • Faktureringskontext kontrolleras kund för kund i Stripe, så outreach beror på hur stressig dagen är.
  • Segment glider eftersom definitionen av “i riskzonen” ändras, men filtret i kalkylbladet gör det aldrig.
  • Mejl skickas oregelbundet, vilket gör att du inte kan se vad som faktiskt förbättrade retention.

Vad du bygger: användnings- + faktureringsintelligens som skickar rätt mejl

Det här flödet körs enligt schema och gör jobbet du normalt gör i fragment. Först hämtar det kundernas användnings- och engagemangssignaler från Postgres (sånt som antyder att någon håller på att glida). Sedan kör det datan genom ett poängsteg för att avgöra vad varje konto behöver härnäst: en retention-insats, en upsell-puff eller en reaktiverings-check-in. För varje segment hämtar flödet kundens Stripe-kontext (så att du inte mejlar i blindo) och skickar ett riktat meddelande via Gmail. Resultatet är enkelt: rätt kund får rätt mejl vid rätt tidpunkt, utan att du bygger en ny lista varje vecka.

Flödet startar med en schemalagd genomgång och sedan ett konfigurationssteg som sätter tröskelvärden och regler. Efter analysen routar tre filter kunder till retention-, upsell- eller återengagemangsspår. Varje spår berikar kundposten med data från Stripe och skickar ett Gmail-mejl som matchar situationen.

Det du bygger

Förväntade resultat

Säg att du granskar churn-risk för 120 kunder varje vecka. Manuellt kan du lägga cirka 3 minuter på att hämta användning per kund från Postgres och ytterligare 2 minuter på att kolla Stripe, vilket blir ungefär 10 timmar innan du ens skriver ett mejl. Med det här flödet sker veckokörningen automatiskt och du kliver bara in för den handfull konton som behöver mänsklig uppmärksamhet (kanske 10–20). Det kan göra en halv dags retention-syssla till en snabb genomgång.

Innan du börjar

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
  • Postgres för kundernas användnings- och engagemangsmått.
  • Stripe för att hämta fakturering och kundkontext via API.
  • Gmail för att skicka retention-, upsell- och reaktiveringsmejl.
  • OpenAI API-nyckel (hämta den i OpenAI-dashboarden) för AI-stödd copy eller sammanfattningar.

Svårighetsgrad: Medel. Du kopplar credentials och bekräftar att din Postgres-fråga och dina Stripe-fält matchar din datamodell.

Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).

Steg för steg

En schemalagd genomgång startar allt. n8n kör det här flödet med den kadens du väljer (veckovis är vanligt). Då blir churn-övervakning ett system, inte en kalenderpåminnelse.

Användningssignaler hämtas från Postgres. Flödet frågar din databas efter kundmått som korrelerar med churn eller expansion. Det kan vara inloggningar, antal nyckelhändelser, feature adoption, ändringar av antal platser eller valfria “health score”-fält som du redan underhåller.

En analysdel poängsätter och routar konton. Ett bearbetningssteg utvärderar varje kund och skickar dem vidare i ett av tre spår: retention-risk, upsell-kandidater eller behöver reaktivering. De där “If”-filtren är där din riskdefinition faktiskt bor.

Stripe-berikning plus Gmail-outreach sker automatiskt. För varje spår anropar n8n Stripe via HTTP för att hämta kunddetaljer (plan, status, senaste faktureringshändelser) och skickar sedan ett Gmail-mejl med rätt meddelandemall för situationen.

Du kan enkelt ändra routningsreglerna så att de matchar din produkts verklighet och justera mejlinnehållet baserat på segment och plannivå. Se hela implementationsguiden nedan för anpassningsalternativ.

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

Steg 1: Konfigurera schematriggern

Ställ in arbetsflödet så att det körs enligt ett fast schema, så att intäktsengagemanget utvärderas automatiskt.

  1. Lägg till noden Scheduled Revenue Review som din trigger.
  2. Ställ in Rule till ett cron-uttryck med Field = cronExpression och Value = 0 6 * * *.
  3. Koppla Scheduled Revenue Review till Revenue Configurator.

Steg 2: Anslut PostgreSQL

Konfigurera intäktsinställningarna och ladda kundanalysdata från er databas.

  1. I Revenue Configurator lägger ni till numeriska värden för churnRiskThreshold = 0.7, upsellThreshold = 0.8 och retentionDiscount = 25.
  2. Öppna Retrieve Customer Metrics och ställ in Query till SELECT customer_id, usage_score, engagement_score, support_tickets, payment_history, plan_type, mrr FROM customer_analytics WHERE active = true.
  3. Credential Required: Anslut era Postgres-credentials i Retrieve Customer Metrics.
  4. Koppla Revenue Configurator till Retrieve Customer Metrics.

Steg 3: Konfigurera Revenue Opportunity Analyzer

Analysera varje kunds churn-risk och upsell-potential för att avgöra rätt engagemangsväg.

  1. Öppna Revenue Opportunity Analyzer och klistra in hela JavaScript-logiken för churn-risk och upsell-poängsättning (finns i arbetsflödet).
  2. Verifiera att noden refererar till $node['Revenue Configurator'].json för tröskelvärden.
  3. Koppla Retrieve Customer Metrics till Revenue Opportunity Analyzer.

Revenue Opportunity Analyzer skickar utdata parallellt till Retention Risk Filter, Upsell Candidate Filter och Reactivation Need Filter.

Tips: Se till att fältnamnen i databasfrågan stämmer överens med analyzerns kod (t.ex. usage_score, engagement_score, mrr), annars kommer poängsättningslogiken att använda noll som standardvärden.

Steg 4: Konfigurera grenvillkor och Stripe-uppslag

Routa varje kund till rätt engagemangskampanj och berika data från Stripe.

  1. I Retention Risk Filter ställer ni in villkoret till Left Value = {{ $json.recommended_action }} och Right Value = retention_campaign.
  2. I Upsell Candidate Filter ställer ni in villkoret till Left Value = {{ $json.recommended_action }} och Right Value = upsell_campaign.
  3. I Reactivation Need Filter ställer ni in villkoret till Left Value = {{ $json.recommended_action }} och Right Value = engagement_campaign.
  4. I Fetch Stripe Customer ställer ni in Method till GET, URL till https://api.stripe.com/v1/customers/{{ $json.customer_id }} och lägger till en Authorization-header med Bearer {{ $credentials.stripe.secretKey }}.
  5. Upprepa samma Stripe-inställningar för Fetch Stripe Customer 2 och Fetch Stripe Customer 3.
  6. Credential Required: Anslut era Stripe-credentials för HTTP Request-noderna (Stripe secret key refereras i Authorization-headern).

⚠️ Vanlig fallgrop: Om Stripe Authorization-headern saknas, eller om credential-namnet inte matchar $credentials.stripe.secretKey, kommer kunduppslaget att misslyckas och inga mejl skickas.

Steg 5: Konfigurera e-postutdata

Skicka personliga kampanjer baserat på routningsbesluten och kunddata berikad med Stripe.

  1. I Dispatch Retention Email ställer ni in Send To till {{ $json.email }} och Subject till Special Offer - We Value Your Business 💎.
  2. Säkerställ att mejltexten för retention innehåller uttrycken {{ $node['Revenue Configurator'].json.retentionDiscount }} och {{ $node['Revenue Opportunity Analyzer'].json.customer_id }}.
  3. I Dispatch Upsell Email ställer ni in Send To till {{ $json.email }} och Subject till Ready to Unlock More Value? 🚀.
  4. I Dispatch Reengagement Email ställer ni in Send To till {{ $json.email }} och Subject till We Miss You! Let's Get You Back on Track 🎯.
  5. Credential Required: Anslut era Gmail-credentials i alla tre e-postnoder: Dispatch Retention Email, Dispatch Upsell Email och Dispatch Reengagement Email.

Tips: E-postnoderna förlitar sig på $json.email som returneras från Stripe. Se till att era Stripe-kundobjekt innehåller en e-postadress.

Steg 6: Testa och aktivera ert arbetsflöde

Kör ett manuellt test för att validera hela flödet från början till slut innan ni slår på schemat.

  1. Klicka på Execute Workflow och bekräfta att Retrieve Customer Metrics returnerar rader för aktiva kunder.
  2. Verifiera att Revenue Opportunity Analyzer ger utdata med fält som recommended_action, churn_risk och upsell_potential.
  3. Bekräfta att varje väg körs: kunder ska passera genom rätt filternod och vidare till motsvarande Stripe-uppslag och e-postnod.
  4. Kontrollera inkorgen efter testmejl som skickats av Dispatch Retention Email, Dispatch Upsell Email eller Dispatch Reengagement Email.
  5. När resultaten ser korrekta ut, växla arbetsflödet till Active så att Scheduled Revenue Review körs dagligen kl. 06:00.
🔒

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

Få den kompletta implementeringsguiden + nedladdningsbar mall

Felsökningstips

  • Stripe HTTP-credentials kan fallera för att API-nyckeln är fel eller begränsad. Kontrollera Stripe Developers → API keys och bekräfta sedan att nyckeln i n8n är för samma miljö (test vs live).
  • Om din Postgres-fråga inte returnerar några rader kan efterföljande filter bete sig som att “inget är i riskzonen”, vilket är missvisande. Börja med att validera SQL-frågan i din databasklient och klistra sedan in den i Postgres-noden.
  • Gmail-skick kan i tysthet slå i gränser eller kräva rätt OAuth-behörigheter. Om mejl slutar skickas, inspektera exekveringsutdata i Gmail-noden och autentisera om Gmail-credential i n8n.

Snabba svar

Hur lång är uppsättningstiden för den här automatiseringen för Stripe churn-mejl?

Cirka en timme om dina Postgres- och Stripe-fält är okomplicerade.

Krävs kodning för den här automatiseringen av churn-riskmejl?

Nej. Du kopplar främst konton, klistrar in/justerar en Postgres-fråga och redigerar din mejltext.

Är n8n gratis att använda för det här Stripe churn-mejlflödet?

Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på $20/månad för högre volym. Du behöver också räkna in kostnader för OpenAI API (ofta bara några dollar i månaden vid måttlig volym) om du använder AI-agenten för text eller sammanfattningar.

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

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

Kan jag anpassa det här Stripe churn-mejlflödet för andra use cases?

Ja, och det bör du. De flesta anpassningar sker i Postgres-steget “Retrieve Customer Metrics” och i de tre filtren (Retention Risk Filter, Upsell Candidate Filter, Reactivation Need Filter). Du kan också byta Stripe HTTP-requesten för att hämta andra faktureringsfält och sedan anpassa Gmail-ämnesrad och brödtext för olika plannivåer, regioner eller kundsegment.

Varför misslyckas min Stripe-anslutning i det här flödet?

Oftast är det en ogiltig eller utgången Stripe API-nyckel, eller att anropet pekar mot fel miljö. Skapa om nyckeln i Stripe, uppdatera den i credential för HTTP Request och kör om en enskild exekvering för att bekräfta. Om det fortfarande misslyckas, kontrollera saknade behörigheter, felaktiga kund-id:n från Postgres eller rate limits om du hämtar många kunder i en körning.

Vilken volym kan det här Stripe churn-mejlflödet hantera?

Några hundra kunder per körning är typiskt, och mer är möjligt. I n8n Cloud beror din månatliga exekveringsgräns på plan, medan self-hosting inte har något hårt exekveringstak (din server blir begränsningen). Om du mejlar i stor skala är Gmails sändningsgränser oftast den första flaskhalsen, så många team stryper utskick eller delar upp segment över flera dagar.

Är den här automatiseringen för Stripe churn-mejl bättre än att använda Zapier eller Make?

Ofta ja, eftersom den här typen av churn-flöde behöver förgreningslogik och datatillrättaläggning, och n8n hanterar det utan att göra det till ett prissättningspussel. Att hämta från Postgres, poängsätta konton och sedan routa till tre olika mejlspår går i Zapier/Make, men det kan bli skört när regler ändras. n8n ger dig också ett self-hosted-alternativ, vilket spelar roll när körningar blir frekventa. Om du bara behöver “Stripe-händelse → skicka mejl” kan enklare verktyg gå snabbare. Prata med en automationsexpert om du vill ha hjälp att välja.

När det här väl rullar slutar churn-signaler att leva i dashboards som ingen kollar. Flödet sköter den repetitiva outreachen så att du kan fokusera på samtalen som faktiskt räddar konton.

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