Hogyan építettünk fel egy AI lead-osztályozó rendszert egy közép-európai autóipari KKV-nak. Architektúra, tech döntések, és a 4 hónap valós tanulságai.
Lead pipeline
A weboldal lead-űrlapja n8n webhookot hív. Honeypot, rate-limit, validáció a kapun belül.
Few-shot promppt + magyar üzleti kontextus 4 kategóriába sorol + 0-100 urgency score-t ad.
Kategória szerint 4 külön pipeline-ba kerül a deal, follow-up draft az értékesítőnek.
Urgency >= 80 esetén Twilio SMS a sales-asszisztensnek. Minden classification Postgres audit-logba.
Az egyik korábbi projektünk: egy autóipari KKV-nak építettünk lead-osztályozó és asszisztens rendszert n8n + OpenAI alapokon. A go-live után 3 hónappal a számokon mérhető volt a javulás: a lead-response idő mediánja 18 óráról 4 órára csökkent, a sales-csapat napi 35-40 percet nyert vissza az email-triage-on. Ez a cikk belülről nézi a 4 hónapos projektet — architektúra, tech-döntések, kihívások, és mit csináltunk volna másképp.
Az ügyfél anonimizált. Az iparág és a méret a jellemző: autóipari beszállító B2B katalógussal, 25-30 fős csapat, magyar piac. A projekt 2026 január-április között futott.
Az ügyfél egy autóipari B2B beszállító — alkatrész-katalógus és tanácsadási szolgáltatás. A piacon erős pozíció (15+ év a területen), a sales-csapat 4 fő, jól ismerik a termékeket. A vásárlói bázis két nagy szegmensre oszlik:
A digitális oldal viszont elmaradott volt: weboldal WordPress alapon (még 2019-es theme-en), katalógus PDF-ekben, leadek emaileken jönnek info@ címre. A back-office csapat (3 fő) napi átlag 80-120 emailt szortírozott és kapcsolt át a sales-asszisztenshez.
Az első call-on a managing director három problémát említett:
Ezek tipikus „workflow túlfutott a manuális kapacitáson" jelek. A managing director egy konkrét számot is mondott: az utolsó 6 hónapban legalább 8 olyan üzlet veszett el, ahol a versenytárs 2-3 órán belül megküldte az ajánlatát, és az ügyfél csak utána ért hozzájuk.
A discovery elején egy mérést kértünk: ne mondja a CEO, hogy „sok" — mutassa a számokat. Két hét alatt manuálisan végigmentünk az utolsó 3 hónap 800+ lead-emailén, és lemértük:
| Metrika | Baseline (2025 Q4) |
|---|---|
| Beérkező lead / hét | 80-120 |
| Válaszadási idő mediánja | 18 óra |
| <90 perces válasz aránya | 12% |
| 24 órán belüli válasz aránya | 53% |
| 72 óránál is hosszabb válasz | 22% |
| Sales-asszisztens napi triage-idő | 35-40 perc |
| Sales-csapat email-első-érintése | 18-22 perc / lead |
A „47% elmaradt follow-up" szám az ügyfél belső riportjából jött (CRM-data); a mi mérésünk ennél kicsit alacsonyabbat mutatott (44%), de a nagyságrend stimmelt.
A 800 emailt mind a 4 sales-tag és egy mi-team-tag manuálisan címkézte. A leadek 4 típusra szegmentálódtak:
Mindegyik típusnak más SLA-t igényelne a sales — a meglévő egységes flow viszont mindenkit ugyanúgy kezelt. Egy „kereskedelmi érdeklődés flotta-üzemeltetőtől" ugyanúgy várt 18 órát, mint egy „panasz visszatérítésre" — pedig a sürgősség teljesen más.
Megjegyzés: A discovery-mérés a teljes projekt egyik legfontosabb invesztíciója volt. A „nincs follow-up" érzet és a tényleges 47% adat közti különbség adta a csapatnak a motivációt — és a CFO-nak az alapot a budget-jóváhagyásra.
Két párhuzamos szál:
A teljes architektúra 7 fő komponensből áll:
A platform-választás a discovery 2. hetében zajlott. Mindhármat értékeltük:
| Szempont | Zapier | Make | n8n self-hosted |
|---|---|---|---|
| Adat-residency (GDPR) | Enterprise | EU host opció | Full control |
| Workflow-git-version | Nem | Nem | Igen |
| Havi cost 100K event-en | $389 | $99 | $20 (VPS) |
| Setup-idő | 2 nap | 3 nap | 5 nap |
| Csapat-skill (mi) | Mid | Mid | High |
n8n self-hosted nyert, mert (1) a saját DigitalOcean VPS-en futott eddig egy másik integráció — kapacitás megosztható, (2) a workflow JSON-t git-be tudjuk verzionálni, ami fontos volt a prompt-iterations miatt, (3) GDPR-szempontból tisztább (személyes adat soha nem hagyja el a saját szervert), (4) hosszú távon olcsóbb.
Részletes platform-összehasonlítás: n8n vs Zapier vs Make 2026.
A 4. hét eval-mérésén:
| Metrika | GPT-4o | Claude Sonnet 4 |
|---|---|---|
| Eval-szet accuracy (60 case) | 94% | 91% |
| Magyar nyelvi minőség | Jó | Jó |
| Cost / 1M input token | $2.5 | $3.0 |
| JSON-mode strictness | Excellent | Jó (tool use) |
| Latency p95 | 1.8s | 2.2s |
OpenAI nyert szűk margóval. A magyar nyelvű lead-szövegekre kicsit jobb pontosságot adott, és a JSON-mode szigorúbb a Claude tool use-nál. Claude alternatívaként benn maradt a fallback-logikában — ha OpenAI 503-mal válaszol, automatikus átkapcsolás Claude-ra.
Tipp: A magyar nyelvre nincs egyértelmű „best LLM". Próbáld ki saját eval-szettel. Az eval-szett 50-100 valós lead-szövegből álljon, kategorikus címkékkel — egy nap munka, és pontosan tudni fogod, melyik modell jobb az adott domain-en.
Az első call-on a managing director felvetette, hogy „rakjunk valami modernebbet a WooCommerce helyett". Mi visszafogtuk: a WooCommerce katalógus a back-office csapat (3 fő) napi munkaeszköze, évek óta tanulták. Az átállás:
A scope-on belül a WooCommerce maradt, és Next.js a frontend, WooCommerce a backend felállás működött. A WooCommerce REST API-ja jó (limited rate limit volt az egyetlen kihívás, lásd lejjebb).
A discovery-ben gyűjtött 800 lead-emailből 60-at választottunk eval-szettre. Random kiválasztott + balansolt a 4 kategóriára (15-15-15-15). Minden push-ra (a prompt git-repóban) lefutott az eval-szet — ha az accuracy 92% alá esett, a deploy blokkolva.
A 60-as méret kompromisszum. Kisebb (30-40) gyengébb statisztikai szignifikanciát ad, nagyobb (100+) több discovery-időt és karbantartást igényel. Egy projekt-szintű minimumot 50-nél húztunk be.
A workflow logikája egyszerűbb, mint amilyennek hangzik:
# n8n workflow (egyszerűsített, 14 node)
1. Webhook trigger (n8n)
↓
2. Input validation (email format, required fields, length check)
↓
3. Honeypot check (spam-szűrés — rejtett mező nem lehet kitöltve)
↓
4. Rate limit check (Redis-cache: max 5 submission / IP / óra)
↓
5. OpenAI call (GPT-4o)
- System prompt: "Te egy lead-osztályozó vagy..."
- User prompt: form content + product context
- Response format: JSON (category, urgency, follow_up_draft)
- Temperature: 0.2 (low for classification)
↓
6. JSON validation (Pydantic schema)
↓
7. Confidence check:
- urgency >= 80 → SMS trigger (Twilio webhook)
- urgency < 50 → human-review queue
↓
8. HubSpot pipeline routing:
- "technical" → Műhely pipeline
- "commercial" → Flotta pipeline
- "complaint" → Panasz pipeline
- "partnership" → Partner pipeline
↓
9. HubSpot create deal + create contact
↓
10. Send follow-up email draft to sales rep (NOT to lead automatically)
↓
11. Audit log: Postgres insert (input, output, model, latency, cost, urgency)
↓
12. PostHog event tracking
↓
13. Error handling (Sentry on any 5xx, fallback to Claude on OpenAI 503)
↓
14. Webhook response 200 OK
A teljes workflow 14 node-ból áll. A prompt verziókövetett a git repóban, és az eval-szet minden push-ra lefut.
Te egy autóipari B2B alkatrész-beszállító lead-osztályozó AI-ja vagy.
A bejövő üzeneteket 4 kategóriába kell sorolnod, és sürgősségi
score-t kell adnod (0-100).
KATEGÓRIÁK:
- technical: alkatrész-illeszkedés, kompatibilitás, műszaki kérdés
- commercial: ár, kedvezmény, készlet-érdeklődés, ajánlatkérés
- complaint: visszatérítés, csere, garancia-igény, panasz
- partnership: beszállítói, viszonteladói, együttműködési ajánlat
URGENCY SCORING:
- 90-100: konkrét vételi szándék, sürgős időkerettel ("ma kell")
- 70-89: aktív érdeklődés, 1-3 napos döntési ciklus
- 50-69: általános kérdés, hosszabb ciklus
- 30-49: információkérés, alacsony intent
- 0-29: spam, off-topic, irreleváns
FORMÁTUM (JSON):
{
"category": "technical" | "commercial" | "complaint" | "partnership",
"urgency": 0-100,
"confidence": 0-100,
"follow_up_draft": "200-400 karakteres válasz-vázlat magyarul",
"reasoning": "1-2 mondatos indoklás a kategorizálásra"
}
FEW-SHOT PÉLDÁK:
PÉLDA 1:
Input: "Üdv, az ABC-123 motorblokkhoz kerestünk PQR-456-os csere alkatrészt.
Holnap reggel 8-ra kellene. Tudtok ma kiszállítani?"
Output: {"category": "technical", "urgency": 92, "confidence": 90, ...}
PÉLDA 2:
Input: "Jó napot, 50 db DEF-789-es szűrőre kérnék ajánlatot,
flottánknak. Mennyi a mennyiségi kedvezmény?"
Output: {"category": "commercial", "urgency": 75, "confidence": 95, ...}
[... további 8 példa, 2-3 / kategória ...]
Most osztályozd a következőt:
INPUT: {user_form_content}
PRODUCT CONTEXT: {product_metadata}
A prompt 8 few-shot példát tartalmazott végül (2 / kategória). A kezdeti 4 példánál 89%-os eval-accuracy-t kaptunk, a 8 példánál 94%-ot.
A prompt nem első nekifutásra állt össze. 5 iteráció a discovery + build fázisban:
Egyszerű prompt 4 példával. Eval-accuracy: 78%. Fő hibák:
Pontosabb definíciók a system promptban, plus 2 új few-shot példa az edge case-ekre. Eval-accuracy: 86%.
A kezdeti urgency-skála (low/medium/high) túl durva volt. Átálltunk 0-100 score-ra részletes példákkal. Eval-accuracy: 90% (de a urgency-mérés még pontatlan).
A modell explicit confidence-t és reasoning-et adott. Ez két dolgot eredményezett: (1) low-confidence case-ek auto-flag-elődnek human-review-ra, (2) a debugging sokkal gyorsabb (a reasoning megmondja, miért tévesztett).
Eval-accuracy: 92%.
8 few-shot példa minden kategóriára 2, plus a termék-kontextus (cikk-szám, kategória) hozzáadva a promptba. Eval-accuracy: 94%.
Tipp: A prompt-finomhangolás nem lineáris. Iter 1 → 4 minden lépésnél meglepetés volt — az „okosabb" prompt sokszor rontott. Eval-szet nélkül ezt nem mértük volna.
Minden push (git commit a prompt JSON-ra) lefuttatta a 60-elemes eval-szettet egy GitHub Action-ben. Ha az accuracy < 92%, a PR blocked. Ezt később 90%-ra állítottuk, mert a 92%-os threshold túl szigorú volt az új edge case-ek miatt.
| Hét | Fázis | Output |
|---|---|---|
| 1-3 | Discovery | Folyamat-mapping, eval-szet, scope dokumentum, mérési baseline |
| 4-5 | Design | Frontend Figma, n8n workflow vázlat, prompt v1 + few-shot példák |
| 6-9 | Build | Next.js fejlesztés, n8n workflow, OpenAI integráció, prompt iter 1-5 |
| 10-11 | Internal test | Eval-szet accuracy 94%, sales UAT-feedback |
| 12 | Soft launch | Csak technikai kérdéskategória élesben, 1 hét monitoring |
| 13 | Full launch | Mind a 4 kategória, dashboard sales-nak |
| 14-17 | Hyper-care | Heti monitoring, prompt-finomhangolás, edge case-ek beemelése az eval-szetbe |
Probléma: Az első 2 hétben a workflow csak vázolta a kategóriát, de a sales-asszisztens manuálisan ellenőrizte. Csak 80 lead után, amikor a pontosság stabilan 94% volt, kezdte el a csapat automatikusan kezelni.
A managing director eleinte kérdezte: „És ha rosszul kategorizál? Ha egy panaszt commercial-be tesz?" — jogos félelem. Az autóiparban a panasz mismanagement márka-szintű reputációkockázat.
Megoldás: Az első 2 hétben a system 4 dolgot csinált: (1) kategorizált, (2) javasolt follow-up draft-ot, (3) a CRM-be NEM tette be, csak Slack-üzenetben küldte a sales-asszisztensnek, (4) az asszisztens kézzel validálta. 80 lead után a sales-vezető engedélyezte az auto-CRM-ingestion-t.
Tanulság: trust-building az AI-projektekben fontosabb, mint a tech. Egy 2-hetes manual-verification fázis a soft launch előtt érdemes — és tegyük be a budget-be.
Probléma: Peak órákban (reggel 9-10, délután 14-15) a 60-90 termékoldali request elérte a Woo throttle-t. A WooCommerce default rate limit ~50 req / min, és peak-en ezt egyszerűen meghaladtuk.
Megoldás: Vercel KV cache 10 perces TTL-lel. A B2B vásárlóknak nem kritikus a real-time stock — 10 perc késleltetés elfogadható. A cache 95%-os hit-rate-et adott peak-en.
// Egyszerűsített cache logika
async function getProductData(sku: string) {
const cached = await kv.get(`product:${sku}`);
if (cached) return cached;
const data = await wooCommerceApi.fetch(sku);
await kv.set(`product:${sku}`, data, { ex: 600 }); // 10 min
return data;
}
Tanulság: rate limit-tesztelés a discovery-be tartozik, nem a launch utáni hyper-care-be. Ha most ismerném, az első hét load-tesztet futtatnék.
Probléma: Az OpenAI GPT-4o jó magyarul, de a few-shot példákat kelet-európai üzleti kontextusban kellett megírni. A „árajánlat" szó például technikai vagy kereskedelmi kategória is lehet a kontextustól függően. A „műszaki info kérem" lehet sima kérdés (technical), de lehet konkrét beszerzési érdeklődés indítása (commercial).
Megoldás: few-shot példa minden kategóriára min. 2 (összesen 8), valós példákból a 800-as discovery-archívumból. Minden példa magyar nyelvű, magyar autóipari szlenggel.
Tanulság: few-shot példa minden kategóriára min. 3-5 valós példából (lehetőleg többről). A kapcsolódó eval-szet 60 elemnél nem alacsonyabb.
Probléma: Az első hetekben az urgency-küszöb 70-en volt. Ez azt jelentette, hogy a sales-asszisztens napi 8-12 SMS-t kapott. A 3. nap után jelezte, hogy ez „szerencsétlen".
Megoldás: Küszöböt feljebb húztuk 80-ra, plus „SMS csak munkanap 8-18 között" korlát az n8n workflow-ban. Hétvégén / éjszaka a high-urgency csak email-flag-elve.
Tanulság: notification-flow tervezésekor gondold át a fogadó oldal stress-szintjét, ne csak a sender ROI-t.
Probléma: A 4 pipeline a 4 kategóriához logikus, de a sales-csapat felfedezte, hogy egy „kereskedelmi érdeklődés" gyakran végül „panasz" lett, ha a flotta-üzemeltető nem kapott elég gyors választ. A pipeline-rotáció rugalmatlan volt.
Megoldás: Manual override gomb a HubSpot UI-ban. Egy deal bármikor másik pipeline-ba mozgatható, az n8n nem írja vissza automatikusan.
Tanulság: AI-rendszer ne legyen önfejű. A human-override option kötelező.
| Metrika | Baseline | 90 nap után |
|---|---|---|
| Lead-response idő (medián) | 18 óra | 4 óra |
| <90 perces response arány | 12% | 41% |
| 24 órán belüli válasz | 53% | 89% |
| Sales napi email-triage | 35-40 perc | 5 perc |
| Eval-szet pontosság | n/a | 94% |
| Webshop mobil LCP | 4.2s | 1.6s |
| Organikus search forgalom | baseline | +22% |
| High-urgency SMS-akció | n/a | 8-12 / hét |
A számok közelítések, de a trend egyértelmű. A konkrét üzleti eredmény: a 4. hónap végén 3 olyan üzletet zártak, amit a régi flow-ban biztos elvesztettek volna — egy versenytárs gyors-ajánlatos szegmensben. Ez konkrét forint-szám, amit a CFO igazolt, és önmagában fedezte a projekt-cost ~40%-át.
A managing director feedback-je (a project lezárása után, a case study quote-ra adott engedéllyel):
„A legjobb döntés az volt, hogy nem akartuk lecserélni a teljes folyamatot. A kis lépéseket mérni tudtuk, és az AI-bevezetést a csapat akkor fogadta el, amikor saját szemmel látták hogy működik. A 80 manuális validálás a soft launch alatt ijesztőnek tűnt, de utólag ez volt a legjobb beruházás."
| Tétel | Költség |
|---|---|
| Discovery (3 hét, fix) | 600k Ft |
| Build (8 hét, fix) | 2.4M Ft |
| Hyper-care (4 hét, included) | benne |
| OpenAI API token-cost (havi 80-120k Ft) | 100k Ft / hó |
| n8n self-host VPS (DigitalOcean) | 8k Ft / hó |
| HubSpot Starter (meglévő) | 0 (volt) |
| Twilio SMS (~500 SMS / hó) | 15k Ft / hó |
| Build-cost total | 3M Ft |
| Havi operating cost | ~125k Ft |
ROI-becslés: 3 elveszett üzlet visszanyerése + sales-time savings = ~6-8M Ft / év érték. ROI 12 hónapon belül.
A 3 hetes discovery hosszúnak tűnt, de a 800-elemes manuális címkézés enélkül nem ment volna. Az eval-szet a projekt gerinc — és eval-szet manuális adat nélkül nem létezik. Ne nyomd le a discovery hosszát csak azért, mert a kliens „pénzt akar látni".
A 4 kategóriát nem egyszerre kapcsoltuk élesbe. Először a technical (legkönnyebb), 1 hét monitor, utána a commercial, a complaint és a partnership csak a 13. héten ment élesbe. Ez 2 hét „lassúság", de drámaian csökkentette a kockázatot.
A 60-elemes eval-szet a launch napján stimmt, de az új edge case-ek folyamatosan jönnek. A hyper-care alatt heti 5-10 új case-t adtunk hozzá. A 17. héten a eval-szet 110 elem volt.
Az AI-rendszer csak akkor hatékony, ha a sales-csapat használja, nem ignorálja. Az első hetek manual-validation fázisa pont erről szólt: a csapat hozzászokjon a flow-hoz, javaslatokat tegyen, és tulajdonosi érzettel kezelje a rendszert.
Az OpenAI API token-cost könnyen kicsúszik. A audit_log táblában minden classification cost-jét rögzítettük, és napi dashboard mutatta. Ha 1 nap >$5 volt, alert. (Tipikus napi cost: $1-3.)
Témához kapcsolódó saját cikkeink: RAG chatbot építése — a vector-DB és LLM-kontextus oldal mélyebb tárgyalása. LLM hallucinációk elleni védekezés — a confidence-scoring és output-validation technikák. AI implementáció magyar KKV-knál — KKV-specifikus ROI-számítás.
Egy AI-projekt sikere nem a modell pontosságán múlik, hanem a discovery minőségén, a sales-csapat bevonásán, és az iteratív launch-on. A 94%-os eval-szet pontosság a célállomás, nem a starting point.
A teljes projekt 4 hónap volt, a build-cost 3M Ft. A havi üzemeltetés 125k Ft. Az ROI 12 hónapon belül zárt — főleg a 3 visszanyert üzlet és a sales-time savings miatt.
Ha AI lead-asszisztenst tervezel, beszéljük át egy 30 perces hívásban. A discovery-cost (200-600k Ft) tipikusan elveszik a megtakarított elveszett üzletek között az első hónapban — ha a probléma valós.
A szerzőről
Corevanix Kft.
Tech partner
Modern tech partner — SAP/ERP, webfejlesztés, AI automatizáció és mobil app fejlesztés egy szakmai csapatban. KKV-tól enterprise projektig.
LinkedIn →
Hogyan építs RAG chatbotot vállalati dokumentumokra úgy, hogy ne találjon ki dolgokat. Architektúra, stack-választás, költségbecslés és deploy.
Három workflow-automatizációs platform mélyebb elemzése. Pricing, self-hosting, integration count, vendor lock-in és 5 konkrét use case ajánlás.
Az LLM-ek hallucinálnak — ez nem hiba, hanem a modellek természetes velejárója. Hét bevett technika a produkciós AI-rendszerek precíziójának növelésére.