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

Postgres + Google Sheets: leverantörsrisk poängsatt

Rickard Andersson Partner, Nodenordic.se

Din leverantörsdata finns överallt. KPI:er ligger i Postgres, finansiella signaler kommer från ett annat ställe, nyheter landar i inkorgen och “riskpoängsättning” blir till en panikartad uppdatering i kalkylark precis när du har minst utrymme för det.

Inköpschefer får meddelandet sent på kvällen: “vi är försenade”. Driftchefer märker det när en lina stannar. Och ekonomiteam får jaga förklaringar till oväntade kostnader. Den här automatiseringen för Postgres Sheets risk håller en löpande riskpoäng så att du slipper gissa.

Du får se hur flödet hämtar leverantörs-KPI:er, kontrollerar externa signaler, riskpoängsätter, loggar revisionsspåret i Google Sheets och mejlar rätt varning när trösklar passeras.

Så fungerar den här automatiseringen

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

n8n Workflow Template: Postgres + Google Sheets: leverantörsrisk poängsatt

Problemet: leverantörsrisk upptäcks för sent

De flesta team har egentligen ingen “process för leverantörsrisk”. De har en månadsvis genomgång, ett par dashboards och mycket tyst kunskap. Sprickorna syns när en leverantörs leveransprecision smyger ned under flera veckor, eller när en negativ nyhet slår till och ingen kopplar den till era öppna inköpsorder förrän det redan gör ont. Då får ni panik: plockar KPI:er från databasen, googlar leverantören, frågar runt efter sammanhang och försöker motivera beslut i efterhand. Det är tröttsamt och gör er mer reaktiva än ni vill vara.

Friktionen byggs på. Här är det som oftast fallerar:

  • Leverantörens prestationsmått ligger i Postgres, men riskgenomgången sker i Google Sheets, så någon sitter och kopierar siffror manuellt.
  • Finansiell hälsa och kreditsignaler kontrolleras sporadiskt, vilket gör att det “gröna ljuset” ni lutar er mot kan vara flera veckor gammalt.
  • Nyheter och händelser är ostrukturerade, så viktiga saker missas eller avfärdas som “förmodligen inte relevant”.
  • När ledningen frågar “varför fortsatte vi köpa från dem” saknar ni ett felfritt revisionsspår över vad ni visste vid tidpunkten.

Lösningen: riskpoängsätt leverantörer automatiskt och larma rätt personer

Det här flödet gör er leverantörsdatabas till en levande riskmonitor. Enligt schema hämtar det er aktiva leverantörslista från Postgres och samlar sedan in två typer av signaler: hårda siffror (finansiella hälsodata plus era prestations-KPI:er) och rörig kontext (nyheter och händelser). Indatan slås ihop och körs genom en riskberäkning, och en AI-agent kan hjälpa till att tolka externa signaler på klarspråk så att poängen inte blir en svart låda. Därefter kontrollerar flödet era tröskelvärden och skickar rätt mejl baserat på allvarlighetsgrad: medel, hög eller kritisk. Till sist loggas varje bedömning i Google Sheets så att ni får ett enkelt, läsbart revisionsspår som går att dela internt.

Flödet startar med en schemalagd riskkontroll. Därefter hämtar det leverantörs-KPI:er från Postgres, berikar dem med finansiella signaler och nyhetssignaler via HTTP-anrop (med AI-stöd för tolkning) och räknar fram ett enda riskindex. När en leverantör passerar en tröskel skickar Gmail ett larm och Google Sheets sparar resultatet.

Det du får: automatisering vs. resultat

Exempel: så här ser det ut

Säg att du följer 40 aktiva leverantörer. Manuellt innebär en “snabb veckokoll” ofta att hämta KPI:er från Postgres (cirka 2 minuter per leverantör), skanna efter nyheter (ytterligare 3 minuter) och skriva en anteckning någonstans (1 minut). Det är ungefär 4 timmar i veckan. Med det här flödet lägger du kanske 10 minuter på att sätta trösklar och mottagare, sedan kör det enligt schema, mejlar bara när en leverantör triggar medel/hög/kritisk risk och loggar varje poäng till Google Sheets automatiskt.

Det här behöver du

  • n8n-instans (prova n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
  • Postgres för att lagra leverantörer och KPI-tabeller.
  • Google Sheets för att logga riskpoäng och tidsstämplar.
  • OpenAI API-nyckel (hämta den i din OpenAI-dashboard).

Kunskapsnivå: Medel. Du kopplar konton och justerar några frågor/fält så att de matchar ditt leverantörsschema.

Vill du inte sätta upp det här själv? Prata med en automatiseringsexpert (gratis 15-minuters konsultation).

Så fungerar det

En schemalagd kontroll startar allt. n8n kör “Scheduled Risk Check” automatiskt (dagligen eller varje timme, beroende på hur känslig din försörjningskedja är).

Leverantörsposter hämtas från Postgres. Flödet hämtar aktiva leverantörer först och tar sedan prestationsmått från databasen så att du poängsätter verkligheten, inte gamla exporter.

Externa signaler läggs till. HTTP-anrop hämtar finansiella hälsodata och skannar nyheter/händelser. En AI-agent som använder en OpenAI-chattmodell kan sammanfatta och klassificera det som är relevant (konkursindikatorer, geopolitisk risk, efterlevnadsproblem) så att poängen speglar sammanhanget.

Risk beräknas och routas. Steget “Compute Risk Index” väger ihop allt till ett enda värde, och därefter avgör If-grindar medel/hög/kritisk. Gmail skickar rätt larm och Google Sheets loggar bedömningen för spårbarhet.

Du kan enkelt justera risktrösklarna så att de matchar er policy utifrån era behov. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementation

Steg 1: Konfigurera schematriggern

Starta arbetsflödet enligt ett schema så att leverantörsriskkontroller körs automatiskt varje morgon.

  1. Lägg till och öppna Scheduled Risk Check.
  2. Ställ in schemaregeln till 0 6 * * * för att köra dagligen kl. 06:00.
  3. Verifiera kopplingen från Scheduled Risk Check till Configure Risk Thresholds.

Sticky note Flowpast Branding är valfri och enbart informativ.

Steg 2: Anslut Postgres-datakällor för leverantörer

Hämta aktiva leverantörer och deras senaste prestationsmått från Postgres.

  1. Öppna Fetch Active Suppliers och ställ in Query till SELECT supplier_id, supplier_name, category, criticality_level, last_delivery_date, quality_score, payment_terms, country FROM suppliers WHERE status = 'active'.
  2. Öppna Pull Performance Metrics och ställ in Query till SELECT AVG(delivery_score) as avg_delivery, AVG(quality_score) as avg_quality, COUNT(late_deliveries) as late_count FROM supplier_performance WHERE supplier_id = '{{ $json.supplier_id }}' AND date >= NOW() - INTERVAL '30 days'.
  3. Bekräfta att Fetch Active Suppliers skickar utdata till Retrieve Financial Health, Scan News & Events och Pull Performance Metrics parallellt.

Credential Required: Anslut era Postgres-inloggningsuppgifter för Fetch Active Suppliers och Pull Performance Metrics innan ni testar.

Steg 3: Sätt upp risktrösklar och beräkna riskindex

Definiera risktrösklar och beräkna den slutliga leverantörsriskpoängen med kombinerade datakällor.

  1. Öppna Configure Risk Thresholds och ställ in mediumRiskThreshold till 31, highRiskThreshold till 61 och criticalRiskThreshold till 81.
  2. I Configure Risk Thresholds, ställ in procurementEmail till [YOUR_EMAIL] och riskManagerEmail till [YOUR_EMAIL].
  3. Öppna Compute Risk Index och behåll den angivna JavaScript-logiken intakt, eftersom den refererar till Retrieve Financial Health, Scan News & Events och Pull Performance Metrics.
  4. Bekräfta att Compute Risk Index skickar utdata till Critical Risk Gate, High Risk Gate, Medium Risk Gate och Log Risk Assessment parallellt.

Steg 4: Konfigurera databerikning och aviseringar

Hämta externa risksignaler, routa resultat efter allvarlighetsgrad och skicka aviseringar till rätt mottagare.

  1. Öppna Retrieve Financial Health och ställ in URL till https://api.dnb.com/v1/companies/{{ $json.supplier_id }}/creditAssessment med Method GET.
  2. I Retrieve Financial Health, ställ in headers till Content-Type application/json och Authorization till Bearer {{ $credentials.dnb.apiKey }}.
  3. Öppna Scan News & Events och ställ in URL till https://api.newsapi.org/v2/everything med Method GET.
  4. I Scan News & Events, ställ in query string-värden: q till {{ $json.supplier_name }}, from till {{ new Date(Date.now() - 7*24*60*60*1000).toISOString().split('T')[0] }}, sortBy till publishedAt och language till en.
  5. Ställ in headern X-API-Key i Scan News & Events till {{ $credentials.newsapi.apiKey }}.
  6. Öppna varje gate-nod och verifiera villkor: Critical Risk Gate använder {{ $json.risk_level }} lika med critical, High Risk Gate lika med high och Medium Risk Gate lika med medium.
  7. I Dispatch Critical Email, ställ in Send To till {{ $node['Configure Risk Thresholds'].json.riskManagerEmail }} och behåll Content Type inställt på HTML.
  8. I Dispatch High Risk Email och Dispatch Medium Risk Email, ställ in Send To till {{ $node['Configure Risk Thresholds'].json.procurementEmail }} och behåll Content Type inställt på HTML.
  9. Öppna Log Risk Assessment och ställ in Document ID till [YOUR_ID], Sheet Name till Supplier Risk Tracking och Operation till appendRow.

Credential Required: Lägg till API-inloggningsuppgifter för Retrieve Financial Health och Scan News & Events eftersom headers refererar till $credentials.dnb.apiKey och $credentials.newsapi.apiKey.

Credential Required: Anslut era Gmail-inloggningsuppgifter för Dispatch Critical Email, Dispatch High Risk Email och Dispatch Medium Risk Email, samt era Google Sheets-inloggningsuppgifter för Log Risk Assessment.

Steg 5: Testa och aktivera ert arbetsflöde

Kör ett manuellt test för att bekräfta att datahämtning, riskpoängsättning, routing och loggning fungerar som förväntat.

  1. Klicka på Execute Workflow för att köra ett manuellt test från Scheduled Risk Check.
  2. Verifiera att Fetch Active Suppliers returnerar aktiva leverantörer och att alla tre berikningsnoder körs parallellt.
  3. Bekräfta att Compute Risk Index ger utdata i risk_level och att endast den matchande gate-noden routar till rätt e-postnod.
  4. Kontrollera att Log Risk Assessment lägger till en ny rad med leverantörsdata och tidsstämplar.
  5. Aktivera arbetsflödet genom att slå på Active för att starta schemalagda dagliga kontroller.
🔒

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

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • Postgres-inloggning kan löpa ut eller kräva specifika behörigheter. Om något slutar fungera: kontrollera först dina n8n-inloggningsinställningar och databas-användarens SELECT-behörighet.
  • Om du använder Wait-noder eller extern rendering varierar processtider. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du redigera utdata för alltid.

Vanliga frågor

Hur lång tid tar det att sätta upp den här automatiseringen för Postgres Sheets risk?

Cirka 45 minuter om dina Postgres-tabeller och ditt Google Sheet är redo.

Behöver jag kodkunskaper för att automatisera riskpoängsättning av leverantörer?

Nej. Du kopplar främst konton och mappar fält i n8n. Du kan behöva justera en Postgres-fråga om ditt schema är anpassat.

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

Ja. n8n har ett gratis self-hosted-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 även räkna in OpenAI API-kostnader (ofta några cent per körning, beroende på hur mycket nyhetstext du analyserar).

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

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 hanterar n8n bra. Self-hosting ger dig obegränsade exekveringar men kräver grundläggande serveradministration.

Kan jag anpassa det här Postgres Sheets risk-flödet för Slack-larm istället för mejl?

Ja, och det är en vanlig justering. Du behåller samma kärna för riskpoängsättning (“Compute Risk Index” plus If-grindarna) och byter sedan ut Gmail-sändnoderna mot Slack-meddelandenoder för medel/hög/kritisk. Många team anpassar också set-noden “Configure Risk Thresholds” så att varje kategori routas till en annan kanal eller ansvarig. Om du vill ha renare loggar kan du lägga till en andra Google Sheets-flik för “larm skickade” jämfört med “poäng beräknade”.

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

Oftast beror det på felaktiga inloggningsuppgifter eller att nätverket blockerar mellan n8n och din databas. Bekräfta att host/port går att nå från där n8n körs och verifiera sedan att databasanvändaren har behörighet att läsa leverantörs- och KPI-tabellerna. Om det fungerar i en nod men misslyckas i en annan, kontrollera att du inte råkat peka olika noder mot olika inloggningsuppgifter.

Hur många leverantörer klarar den här automatiseringen för Postgres Sheets risk?

Hundratals, vanligtvis.

Är den här automatiseringen för Postgres Sheets risk bättre än att använda Zapier eller Make?

Ofta, ja, eftersom logiken här inte bara är “skicka en notifiering”. Du slår ihop flera datakällor, räknar fram en poäng och förgrenar till olika spår baserat på allvarlighetsgrad, och där förblir n8n hanterbart och kostnadseffektivt. Self-hosting spelar också roll om du vill köra täta kontroller utan att räkna varje körning. Zapier eller Make kan däremot fungera bra för en enklare variant (en datakälla, ett larm). Prata med en automatiseringsexpert om du vill ha hjälp att välja den enklaste lösningen som ändå håller i längden.

Det här är vad “proaktivt” faktiskt betyder i leverantörsstyrning: signaler hämtas automatiskt, en konsekvent poäng och larm som dyker upp innan störningen gör det. Sätt upp det en gång och låt sedan flödet sköta bevakningen.

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