Att hålla ingredienskostnaderna under kontroll är frustrerande eftersom jobbet aldrig tar slut. Priser rör sig, leverantörer ändras, någon skärmdumpar ett kalkylblad, och du upptäcker för sent att du borde ha köpt förra veckan.
Den här uppsättningen för Postgres Slack alerts träffar restaurangoperatörer och inköpsansvariga hårdast. Men analytiker på byråer som bygger rapportering åt kunder inom hospitality hanterar samma kaos. Resultatet är enkelt: daglig uppföljning, trendkontext och ett tydligt “köp nu / vänta / fyll på lager”-budskap levererat automatiskt.
Du får se hur detta n8n-flöde samlar in priser, bygger en verklig historik i PostgreSQL, genererar rekommendationer och skickar rätt insikt till Slack (plus en e-postdashboard).
Så fungerar automationen
Hela n8n-flödet, från trigger till slutresultat:
n8n Workflow Template: PostgreSQL till Slack: smartare inköpslarm
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n0@{ icon: "mdi:cog", form: "rounded", label: "Scheduled Price Scan", pos: "b", h: 48 }
n1["<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/httprequest.dark.svg' width='40' height='40' /></div><br/>Retrieve API Costs"]
n2["<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/>Persist Price Records"]
n3["<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/>Compute Trend Metrics"]
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/code.svg' width='40' height='40' /></div><br/>Build Buying Guidance"]
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/postgres.svg' width='40' height='40' /></div><br/>Save Guidance Results"]
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/>Retrieve Dashboard Info"]
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/code.svg' width='40' height='40' /></div><br/>Compose Dashboard Markup"]
n8@{ icon: "mdi:message-outline", form: "rounded", label: "Dispatch Email Report", pos: "b", h: 48 }
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/httprequest.dark.svg' width='40' height='40' /></div><br/>Post Slack Notification"]
n10["<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/>Initialize Database Tables"]
n10 --> n2
n3 --> n4
n1 --> n2
n2 --> n3
n0 --> n1
n0 --> n10
n6 --> n7
n5 --> n6
n7 --> n8
n7 --> n9
n4 --> n5
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 n2,n3,n5,n6,n10 database
class n1,n9 api
class n4,n7 code
classDef customIcon fill:none,stroke:none
class n1,n2,n3,n4,n5,n6,n7,n9,n10 customIcon
Problemet: ingredienspriser ändras snabbare än din process
Om du köper in till en restaurang (eller rådgör åt en) känner du redan igen mönstret. Någon kollar en leverantörsportal, kopierar en siffra till ett ark och kallar det “uppföljning”. Sedan sticker priset, du missar läget att låsa en lägre nivå och veckans marginal får en smäll utan att någon riktigt märker det. Det värsta är den mentala belastningen. Du bevakar inte bara en ingrediens; det är dussintals, över enheter, leverantörer och tidslinjer. Även ett litet fel (fel enhet, fel datum, gammalt pris) gör din “trend” värdelös.
Det växer snabbt. Här är var det faller isär i verkligheten.
- Manuella stickprov gör att du reagerar sent, ofta först när fakturorna kommer.
- Utan en riktig databashistorik kan du inte säkert avgöra om dagens pris är en tillfällig avvikelse eller början på en uppgång.
- Team hamnar i Slack-diskussioner om inköp utan full kontext, vilket leder till “vi avvaktar”-beslut som kostar mer senare.
- Kalkylbladsbaserad uppföljning driver ofta iväg, och felen syns exakt när du behöver korrekt formaterade siffror.
Lösningen: daglig prisuppföljning med trendbaserade köpsignaler
Det här flödet kör en schemalagd scan varje dag, hämtar senaste ingredienspriserna från ett externt prissättnings-API (eller valfri källa du pekar ut) och lagrar varje snapshot i PostgreSQL. Därefter frågar det ut de senaste 30 dagarnas historik för att beräkna trendriktning och senaste rörelse, och skapar sedan en praktisk rekommendation som BUY_NOW, WAIT eller STOCK_UP med en etikett för brådska. Till sist bygger det en enkel HTML-dashboard för helhetsbilden, mejlar den till intressenter och postar de viktigaste varningarna i Slack så att teamet ser beslutet i rätt tid. Du sätter upp det en gång, sedan blir din “uppföljning” ett faktiskt system.
Flödet startar på ett dagligt Cron-schema och gör en HTTP-förfrågan för att hämta aktuella priser. PostgreSQL sköter lagring och 30-dagarsanalys, och sedan sparas vägledningen och återanvänds för att generera både e-postdashboarden och Slack-notisen.
Det du får: automation vs. resultat
| Vad detta flöde automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att du följer 20 kärningredienser hos 2 leverantörer. Manuell hantering är ungefär 2 minuter för att kontrollera och logga varje pris, vilket blir runt 80 minuter per dag om du faktiskt är konsekvent (det är de flesta team inte). Med det här flödet är “arbetet” i princip noll: Cron-triggern kör, API-hämtningen sker, PostgreSQL lagrar snapshoten och Slack får köp-/vänta-uppmaningen. Du kanske lägger 5 minuter på att skumma dashboard-mejlet och går sedan vidare med dagen.
Det du behöver
- n8n-instans (testa n8n Cloud gratis)
- Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
- PostgreSQL för att lagra prishistorik och rekommendationer
- Slack för att ta emot köp-/vänta-varningar i en kanal
- API-nyckel för ingredienspriser (hämta den från din leverantör av prisdata)
Kunskapsnivå: Medel. Du kopplar konton, klistrar in inloggningsuppgifter och verifierar ett par databasfrågor och webhook-inställningar.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
Dagligt schema startar allt. En Cron-trigger kör en gång per dag så att du bygger konsekvent historik utan att behöva komma ihåg det.
Nya priser hämtas och normaliseras. n8n hämtar aktuella ingredienspriser via HTTP Request och förbereder sedan fält som ingrediensnamn, enhet, leverantör och tidsstämpel så att de hamnar strukturerat i PostgreSQL.
Trender och vägledning skapas från verklig historik. PostgreSQL frågar ut de senaste 30 dagarna för att beräkna trendmått, sedan bygger flödet inköpsvägledning och lagrar den i en rekommendationstabell för rapportering.
Slack + e-post levererar beslutet. Flödet skapar en HTML-dashboard och skickar den via e-post, medan Slack får en fokuserad varning som lyfter vad som ändrats och vad ni ska göra härnäst.
Du kan enkelt ändra 30-dagarsfönstret till 14 dagar (mer reaktivt) eller 60 dagar (stabilare) beroende på behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: Konfigurera den schemalagda triggern
Ställ in arbetsflödet så att det körs enligt ett schema och startar både datainhämtningen och databasiniteringen parallellt.
- Öppna Scheduled Price Scan och definiera ert föredragna cron-schema (t.ex. dagligen vid en specifik tid).
- Bekräfta exekveringsflödet så att Scheduled Price Scan skickar utdata till både Retrieve API Costs och Initialize Database Tables parallellt.
- Lämna Flowpast Branding som en referensnotering (valfritt för körningen).
Steg 2: Koppla API- och databaslagret
Konfigurera HTTP-anropet för att hämta ingredienspriser och säkerställ att alla Postgres-noder är anslutna till samma databas.
- I Retrieve API Costs ställer ni in URL till
https://api.example-food-prices.com/ingredients. - Öppna Initialize Database Tables och verifiera att Operation är inställt på executeQuery med den medföljande SQL:en för att skapa tabellerna.
- Anslut Postgres-inloggningsuppgifter till alla databasnoder (5 totalt): Initialize Database Tables, Persist Price Records, Compute Trend Metrics, Save Guidance Results och Retrieve Dashboard Info.
Autentiseringsuppgifter krävs: Anslut era postgres-inloggningsuppgifter
Steg 3: Sätt upp trendanalys och köprekommendationer
Det här steget beräknar trendmått för 30 dagar och genererar lättlästa köprekommendationer.
- I Persist Price Records ställer ni in Table till
price_historyoch behåller mappningen inställd på automatisk mappning av indata. - Öppna Compute Trend Metrics och bekräfta att Operation är executeQuery med hela SQL-frågan inkluderad i arbetsflödet (30-dagars trendfönster).
- I Build Buying Guidance behåller ni JavaScript-logiken som den är för att mata ut rekommendationsfält som
BUY NOW,WAIToch angelägenhetsgrad.
Steg 4: Spara och förbered data för dashboard
Spara rekommendationer och sätt ihop dashboard-data som används för meddelanden och rapportering.
- I Save Guidance Results ställer ni in Table till
buying_recommendationsoch låter automatisk mappning vara aktiverad. - Öppna Retrieve Dashboard Info och verifiera att Operation är executeQuery med den angivna sorteringslogiken för angelägenhet.
- I Compose Dashboard Markup behåller ni HTML-mallen intakt för att generera en fullständig dashboard i
$json.html.
Steg 5: Konfigurera utleverans av rapporter
Skicka HTML-dashboarden via e-post och posta en Slack-sammanfattning parallellt.
- I Dispatch Email Report ställer ni in To Email till
[YOUR_EMAIL]och From Email till[YOUR_EMAIL]. - Ställ in Subject till
Daily Price Fluctuation Report - {{ $now.format('YYYY-MM-DD') }}. - I Dispatch Email Report behåller ni bilagan inställd på
data:text/html;base64,{{ $json.html | base64 }}så att HTML-dashboarden renderas korrekt. - I Post Slack Notification ställer ni in URL till
https://hooks.slack.com/services/[YOUR_ID]och behåller Send Body aktiverat. - Verifiera att Slack-meddelandet använder uttrycken:
🍽️ Daily Price Update: {{ $('Retrieve Dashboard Info').all().filter(item => item.json.urgency === 'HIGH').length }} high priority items need attention!och bilageuttrycket={{ $('Retrieve Dashboard Info').all().filter(item => item.json.urgency === 'HIGH').map(item => ({ color: item.json.recommendation === 'BUY NOW' ? 'good' : 'danger', fields: [{ title: item.json.ingredient, value: `${item.json.recommendation} - ${item.json.reason}`, short: false }] })) }}. - Bekräfta att Compose Dashboard Markup skickar utdata till både Dispatch Email Report och Post Slack Notification parallellt.
Autentiseringsuppgifter krävs: Anslut era smtp-inloggningsuppgifter
Steg 6: Testa och aktivera ert arbetsflöde
Validera processen end-to-end och aktivera schemat för användning i produktion.
- Klicka på Execute Workflow för att köra ett manuellt test från Scheduled Price Scan.
- Bekräfta att Persist Price Records lägger in data i
price_historyoch att Save Guidance Results skriver tillbuying_recommendations. - Verifiera att e-posten kommer fram med HTML-dashboarden som bilaga och att Slack-meddelandet innehåller högprioriterade objekt.
- När ni är nöjda växlar ni Active för att aktivera de schemalagda körningarna.
Vanliga fallgropar
- PostgreSQL-inloggningar kan löpa ut eller kräva specifika behörigheter. Om det skapar fel, kontrollera din n8n-credential och bekräfta att databasanvändaren kan CREATE/INSERT/SELECT först.
- Om du använder Wait-noder eller extern rendering varierar bearbetningstiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
- Slack-webhooks och bot-tokens roteras i vissa organisationer. Om varningarna plötsligt slutar, kontrollera Slack-credentialen igen och bekräfta att kanalen fortfarande tillåter inkommande inlägg.
Vanliga frågor
Cirka 45 minuter om din åtkomst till PostgreSQL och Slack är klar.
Nej. Du klistrar mest in inloggningsuppgifter och justerar några fält och tröskelvärden. Den enda “tekniska” delen är att bekräfta att din databasanslutning fungerar.
Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volymer. Du behöver också räkna med kostnaden för ditt API för ingredienspriser (varierar mellan leverantörer).
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger dig obegränsat antal körningar men kräver grundläggande serveradministration.
Ja, men du bör ändra två saker. Uppdatera Cron-schemat så att det kör veckovis och justera sedan fönstret i trendfrågan i delen Compute Trend Metrics så att den fortfarande använder tillräckligt med data för att vara meningsfull. Vanliga justeringar är också att ändra tröskeln för “brådska”, lägga till leverantörsspecifika regler och begränsa Slack-pingar till enbart HIGH-brådskande poster.
Oftast handlar det om användarbehörigheter i databasen eller fel host/port i dina n8n-credentials. Bekräfta att användaren kan skapa tabeller (för den initiala uppsättningen) och infoga/selekttera rader (för dagliga körningar). Om du använder en hanterad Postgres-tjänst, kontrollera även IP-allowlists och SSL-krav eftersom de inställningarna tyst blockerar anslutningar.
Väldigt många. De flesta restauranger kan lagra månader (eller år) av dagliga priser utan att belasta PostgreSQL, och 30-dagars trendfrågan förblir snabb om du har index aktiverade. På n8n Cloud är den praktiska gränsen dina månatliga körningar; om du kör själv beror det främst på serverstorlek och hur många ingredienser du följer.
För det här användningsfallet, oftast ja. Flödet bygger på en riktig databashistorik och SQL-frågor, vilket är krångligt (och ofta dyrt) att modellera med Zapier-liknande stegbegränsningar. n8n gör det också enklare att förgrena logik, spara mellanresultat och skapa en dashboard utan att göra allt till en skör kedja av zaps. Zapier eller Make kan fortfarande fungera om du bara behöver en enkel “priset ändrades, skicka meddelande”-notis och du inte bryr dig om trendkontext. Om du är osäker, prata med en automationsexpert och beskriv hur många ingredienser du har och hur ofta du köper.
När detta väl rullar slutar du jaga priser och börjar agera på dem. Flödet tar hand om det repetitiva, och teamet får tydligare inköpsbeslut i Slack utan det dagliga kaoset.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.