HelpBot Ticket Desk + n8n: AI triage, MySQL i Slack routing za upite iz web forme i emaila
Ovaj case study opisuje “HelpBot Ticket Desk” pipeline: web forma i email ulaz, normalizacija podataka, AI klasifikacija (kategorija, prioritet, team i confidence), upis u MySQL te Slack notifikacije prema timu. Ključni dio je confidence gating: upiti s niskim povjerenjem idu u #triage na ručnu provjeru, a ostali se automatski routeaju u odgovarajući kanal.
Live test / Demo
Ovaj sustav moguće je testirati uživo na dva načina:
- putem kontakt forme: https://dariomijic.com/n8ncontactform/index.html
- slanjem emaila na: help_bot@dariomijic.com
Svaki upit prolazi isti intake → AI triage → database → Slack routing pipeline opisan u ovom case studyju.
Ticket Desk (UI)
Ticketi se mogu pregledati i uređivati u web sučelju:
https://ticketingbot.dariomijic.com/Pristupni podaci: user: admin@tb pass: 1234567890
Kontekst i problem
U tipičnom SMB okruženju upiti dolaze iz više izvora: kontakt forma, email, ponekad i različiti inboxi. Bez jasne strukture, agenti ručno čitaju poruke, klasificiraju ih (sales/support/tech), određuju prioritet i prosljeđuju dalje — često u Slacku.
Cilj je bio izgraditi pouzdan “intake + triage” sustav koji radi na shared hostingu (Hostinger), skalira se kroz n8n, i čuva podatke u bazi kako bi kasnije bilo moguće dodati UI (approve/edit) i audit trail.
Rješenje (overview)
Sustav je podijeljen na tri cjeline: (1) Intake (webhook + IMAP), (2) AI triage (OpenAI structured output), (3) Ops sloj (MySQL persistencija + Slack notifikacije). Svaki ulaz se prvo normalizira u isti JSON shape, zatim se radi AI triage i payload se sprema u bazu kao ticket.
AI schema: structured output (stabilno parsiranje)
Umjesto free-form teksta, OpenAI vraća strogi JSON prema dogovorenoj shemi. Time se izbjegavaju krhki regexovi i ručna obrada, a n8n workflow dobiva pouzdan contract za daljnje korake (DB, routing, Slack poruke).
{
"tenant_id": "demo",
"source": "webform|email",
"customer": { "name": "", "email": "", "company": "", "phone": "" },
"subject": "",
"summary": "",
"category": "sales|support|billing|partnership|other",
"priority": "low|medium|high|urgent",
"confidence": 0.0,
"key_fields": { "product": "", "order_id": "", "website": "", "deadline": "" },
"suggested_next_step": "",
"routing": { "team": "sales|support|tech", "assignee": "", "sla_hours": 24 },
"tags": []
}
Koraci detaljnije
1) Webhook intake: kontakt forma šalje JSON na n8n webhook (Header auth), uz osnovni security-hardening.
2) Email intake (IMAP): n8n čita mailbox, izvlači subject + body i normalizira polja u isti shape kao webform.
3) Strip signature: email potpis se uklanja kako AI ne bi “učio” krive informacije i kako bi ticket bio čistiji.
4) OpenAI triage: model vraća category/priority/team + confidence; output se parsira i validira u JS nodeu.
5) MySQL insert: ticket se sprema u bazu; vraća se insertId za link i daljnje akcije.
6) Merge by Position: spajanje payload-a (triage) i DB rezultata (insertId) u jedan item.
7) Confidence gate: ako je confidence < 0.6 → #triage; inače ide u #support/#sales/#tech kanal.
Slack output: routed vs triage
Slack poruke su dizajnirane da budu operativne: agent odmah vidi ticket ID, kategoriju, prioritet, confidence i link. Za low-confidence poruke cilj je “human-in-the-loop” potvrda prije routanja.
Tehnički izazovi i rješenja
- Payload preservation: MySQL node vraća samo SQL/metadata → rješenje: Merge by Position (payload + insertId).
- Stabilan parsing: strogi “raw JSON only” output bez markdowna → strict prompt + parse/validate korak.
- Confidence gating: low-confidence ide u triage, high-confidence ide direktno u team channel.
- Email signature noise: signature strip prije AI koraka.
- Shared hosting constraints: n8n u cloudu, MySQL na hostingu, UI spreman za kasniji “approve/edit”.
Zaključak
HelpBot Ticket Desk pipeline daje brz, konzistentan i proširiv način obrade upita: svaki input postaje strukturirani ticket u bazi, a operativni tim dobiva jasne Slack notifikacije. Confidence gating omogućuje sigurnu automatizaciju bez rizika od pogrešnog routanja, dok low-confidence slučajevi ulaze u kontrolirani triage proces.