How we built an AI lead-classification system for a Central European automotive SMB: architecture, tech decisions and the real lessons of four months.
Lead pipeline
The site form hits an n8n webhook. Honeypot, rate-limit and schema validation run at the gateway.
Few-shot prompt with Hungarian B2B context returns one of four categories plus a 0-100 urgency score.
Each category lands in its own HubSpot pipeline. The sales rep gets a draft follow-up email attached.
Urgency ≥ 80 triggers a Twilio SMS to the on-call rep. Every classification is logged to Postgres.
One of our earlier projects: we built a lead-classification and assistant system for an automotive SMB on n8n and OpenAI. Three months after go-live, the improvement was measurable in the numbers: median lead-response time dropped from 18 hours to 4 hours, and the sales team got back 35-40 minutes a day that used to go into email triage. This article looks at the 4-month project from the inside — architecture, tech decisions, challenges, and what we would do differently.
The client is anonymized. The industry and size are representative: an automotive supplier with a B2B catalog, a team of 25-30 people, Hungarian market. The project ran from January to April 2026.
The client is an automotive B2B supplier offering a parts catalog and advisory services. Strong market position (15+ years in the field), a 4-person sales team who know the products well. The customer base splits into two large segments:
The digital side, however, was outdated: a WordPress site (still running a 2019 theme), catalogs in PDFs, and leads arriving by email at the info@ address. The back-office team (3 people) sorted and routed 80-120 emails a day to the sales assistant.
On the first call, the managing director named three problems:
These are classic signs of a workflow that has outgrown manual capacity. The managing director also had a concrete figure: in the last six months, at least 8 deals were lost because a competitor sent a quote within 2-3 hours, and the client only got to the lead afterward.
At the start of discovery, we asked for a measurement: don't tell us the CEO thinks it's "a lot" — show us the numbers. Over two weeks we manually went through 800+ lead emails from the previous three months and measured:
| Metric | Baseline (Q4 2025) |
|---|---|
| Incoming leads / week | 80-120 |
| Median response time | 18 hours |
| Response under 90 minutes | 12% |
| Response within 24 hours | 53% |
| Response later than 72 hours | 22% |
| Sales assistant daily triage time | 35-40 minutes |
| Sales team's first email touch | 18-22 minutes / lead |
The "47% missed follow-up" figure came from the client's internal report (CRM data); our own measurement showed a slightly lower number (44%), but the order of magnitude held.
All 800 emails were manually labeled by all 4 sales reps plus one of our team members. The leads segmented into four types:
Each type needs a different SLA from sales — but the existing one-size-fits-all flow treated everyone the same way. A "commercial inquiry from a fleet operator" waited the same 18 hours as a "complaint about a refund" — even though the urgency is completely different.
Note: The discovery measurement was one of the most valuable investments in the whole project. The gap between the feeling of "no follow-up" and the actual 47% figure gave the team the motivation — and gave the CFO the basis for approving the budget.
Two parallel tracks:
The full architecture consists of 7 main components:
The platform choice happened in week 2 of discovery. We evaluated all three:
| Criterion | Zapier | Make | n8n self-hosted |
|---|---|---|---|
| Data residency (GDPR) | Enterprise plan | EU hosting option | Full control |
| Workflow version control (git) | No | No | Yes |
| Monthly cost at 100K events | $389 | $99 | $20 (VPS) |
| Setup time | 2 days | 3 days | 5 days |
| Team skill (ours) | Mid | Mid | High |
n8n self-hosted won, because (1) another integration was already running on our own DigitalOcean VPS, so capacity could be shared, (2) we could version the workflow JSON in git, which mattered for prompt iteration, (3) it's cleaner from a GDPR standpoint (personal data never leaves our own server), and (4) it's cheaper long-term.
For a detailed platform comparison, see n8n vs Zapier vs Make 2026.
In the week 4 evaluation:
| Metric | GPT-4o | Claude Sonnet 4 |
|---|---|---|
| Eval-set accuracy (60 cases) | 94% | 91% |
| Hungarian language quality | Good | Good |
| Cost / 1M input tokens | $2.5 | $3.0 |
| JSON-mode strictness | Excellent | Good (tool use) |
| Latency p95 | 1.8s | 2.2s |
OpenAI won by a narrow margin. It gave slightly better accuracy on Hungarian-language lead text, and its JSON mode is stricter than Claude's tool use. Claude stayed in as an alternative in the fallback logic — if OpenAI returns a 503, the system automatically switches to Claude.
Tip: There's no clear "best LLM" for Hungarian. Test it with your own eval set. Build an eval set of 50-100 real lead texts with categorical labels — it's a day's work, and you'll know exactly which model performs better on your domain.
On the first call, the managing director raised the idea of "putting something more modern in instead of WooCommerce." We pushed back: the WooCommerce catalog is the back-office team's (3 people) daily tool, and they'd learned it over years. A migration would mean:
WooCommerce stayed within scope, and the Next.js frontend / WooCommerce backend setup worked well. WooCommerce's REST API is solid (a limited rate limit was the only challenge, see below).
From the 800 lead emails collected during discovery, we selected 60 for the eval set — randomly chosen and balanced across the four categories (15-15-15-15). On every push (the prompt lives in a git repo), the eval set ran automatically; if accuracy fell below 92%, the deploy was blocked.
Sixty was a compromise. A smaller set (30-40) gives weaker statistical significance; a larger one (100+) needs more discovery time and maintenance. We set a project-level minimum at 50.
The workflow logic is simpler than it sounds:
# n8n workflow (simplified, 14 nodes)
1. Webhook trigger (n8n)
↓
2. Input validation (email format, required fields, length check)
↓
3. Honeypot check (spam filter — hidden field must stay empty)
↓
4. Rate limit check (Redis cache: max 5 submissions / IP / hour)
↓
5. OpenAI call (GPT-4o)
- System prompt: "You are a lead classifier..."
- 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" → Workshop pipeline
- "commercial" → Fleet pipeline
- "complaint" → Complaint 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
The full workflow has 14 nodes. The prompt is version-controlled in the git repo, and the eval set runs on every push.
You are a lead-classification AI for an automotive B2B parts supplier.
You must sort incoming messages into one of 4 categories and assign
an urgency score (0-100).
CATEGORIES:
- technical: part fit, compatibility, technical question
- commercial: price, discount, stock inquiry, quote request
- complaint: refund, exchange, warranty claim, complaint
- partnership: supplier, reseller, collaboration offer
URGENCY SCORING:
- 90-100: concrete purchase intent, urgent timeframe ("need it today")
- 70-89: active interest, 1-3 day decision cycle
- 50-69: general question, longer cycle
- 30-49: information request, low intent
- 0-29: spam, off-topic, irrelevant
FORMAT (JSON):
{
"category": "technical" | "commercial" | "complaint" | "partnership",
"urgency": 0-100,
"confidence": 0-100,
"follow_up_draft": "a 200-400 character response draft, in Hungarian",
"reasoning": "a 1-2 sentence justification for the categorization"
}
FEW-SHOT EXAMPLES:
EXAMPLE 1:
Input: "Hi, we're looking for a PQR-456 replacement part for the ABC-123
engine block. We need it by 8am tomorrow. Can you deliver today?"
Output: {"category": "technical", "urgency": 92, "confidence": 90, ...}
EXAMPLE 2:
Input: "Hello, could you quote us on 50 units of the DEF-789 filter
for our fleet? What's the volume discount?"
Output: {"category": "commercial", "urgency": 75, "confidence": 95, ...}
[... 8 more examples, 2-3 per category ...]
Now classify the following:
INPUT: {user_form_content}
PRODUCT CONTEXT: {product_metadata}
The prompt ended up with 8 few-shot examples (2 per category). With the initial 4 examples we got 89% eval accuracy; with 8, it rose to 94%.
The prompt didn't come together on the first try. Five iterations across the discovery and build phases:
A simple prompt with 4 examples. Eval accuracy: 78%. Main errors:
More precise definitions in the system prompt, plus 2 new few-shot examples for the edge cases. Eval accuracy: 86%.
The initial urgency scale (low/medium/high) was too coarse. We switched to a 0-100 score with detailed examples. Eval accuracy: 90% (though urgency measurement was still inaccurate).
The model now returned explicit confidence and reasoning fields. This did two things: (1) low-confidence cases got auto-flagged for human review, and (2) debugging got much faster, since the reasoning field explains why the model got it wrong.
Eval accuracy: 92%.
8 few-shot examples, 2 per category, plus product context (SKU, category) added to the prompt. Eval accuracy: 94%.
Tip: Prompt tuning isn't linear. From iteration 1 through 4, every step brought a surprise — the "smarter" prompt often made things worse. Without an eval set, we wouldn't have caught it.
Every push (a git commit to the prompt JSON) ran the 60-item eval set in a GitHub Action. If accuracy fell below 92%, the PR was blocked. We later lowered this to 90%, because the 92% threshold turned out too strict once new edge cases started showing up.
| Week | Phase | Output |
|---|---|---|
| 1-3 | Discovery | Process mapping, eval set, scope document, baseline measurement |
| 4-5 | Design | Frontend Figma, n8n workflow draft, prompt v1 + few-shot examples |
| 6-9 | Build | Next.js development, n8n workflow, OpenAI integration, prompt iterations 1-5 |
| 10-11 | Internal testing | Eval-set accuracy at 94%, sales UAT feedback |
| 12 | Soft launch | Only the technical category live, 1 week of monitoring |
| 13 | Full launch | All 4 categories live, dashboard for sales |
| 14-17 | Hyper-care | Weekly monitoring, prompt tuning, adding edge cases to the eval set |
Problem: In the first two weeks, the workflow only suggested a category, and the sales assistant checked it manually. Only after 80 leads, once accuracy had held steady at 94%, did the team start handling it automatically.
The managing director's early question was: "What if it misclassifies something? What if it puts a complaint into commercial?" — a fair concern. In the automotive industry, mishandling a complaint is a brand-level reputation risk.
Solution: For the first two weeks, the system did four things: (1) classified the lead, (2) drafted a follow-up, (3) did NOT write it into the CRM — it only sent a Slack message to the sales assistant, and (4) the assistant validated it by hand. After 80 leads, the sales lead approved automatic CRM ingestion.
Lesson: trust-building matters more than the tech in AI projects. A two-week manual-verification phase before soft launch is worth it — and it belongs in the budget.
Problem: During peak hours (9-10am, 2-3pm), 60-90 product-page requests hit the Woo throttle. WooCommerce's default rate limit is ~50 req/min, and at peak we simply exceeded it.
Solution: A Vercel KV cache with a 10-minute TTL. Real-time stock isn't critical for B2B buyers — a 10-minute lag is acceptable. The cache gave a 95% hit rate at peak.
// Simplified cache logic
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;
}
Lesson: rate-limit testing belongs in discovery, not in post-launch hyper-care. Knowing what we know now, we'd run a load test in week one.
Problem: OpenAI's GPT-4o is good at Hungarian, but the few-shot examples had to be written within an Eastern European business context. The Hungarian word for "quote," for instance, can fall under either the technical or the commercial category depending on context. "Please send technical info" can be a plain question (technical), or it can be the opening move of a concrete purchasing inquiry (commercial).
Solution: at least 2 few-shot examples per category (8 total), drawn from real messages in the 800-email discovery archive. Every example was in Hungarian, using Hungarian automotive-industry phrasing.
Lesson: use at least 3-5 real examples per category as few-shot (more if you can). Keep the accompanying eval set at 60 items or more.
Problem: In the first weeks, the urgency threshold sat at 70. That meant the sales assistant received 8-12 SMS messages a day. After day 3, they flagged this as untenable.
Solution: we raised the threshold to 80, and added an "SMS only on weekdays, 8am-6pm" rule in the n8n workflow. On weekends and at night, high-urgency leads are only flagged by email.
Lesson: when designing a notification flow, think about the stress level on the receiving end, not just the sender's ROI.
Problem: four pipelines for four categories made sense on paper, but the sales team found that a "commercial inquiry" often turned into a "complaint" if the fleet operator didn't get a fast enough response. The pipeline structure was too rigid.
Solution: a manual override button in the HubSpot UI. A deal can be moved to a different pipeline at any time, and n8n never writes it back automatically.
Lesson: an AI system shouldn't be stubborn. A human-override option is mandatory.
| Metric | Baseline | After 90 days |
|---|---|---|
| Lead response time (median) | 18 hours | 4 hours |
| Response under 90 minutes | 12% | 41% |
| Response within 24 hours | 53% | 89% |
| Sales daily email triage | 35-40 minutes | 5 minutes |
| Eval-set accuracy | n/a | 94% |
| Webshop mobile LCP | 4.2s | 1.6s |
| Organic search traffic | baseline | +22% |
| High-urgency SMS actions | n/a | 8-12 / week |
The numbers are approximations, but the trend is clear. The concrete business outcome: by the end of month four, the team closed 3 deals they would certainly have lost under the old flow — in a segment where a competitor moves fast with quotes. That's a real revenue figure, confirmed by the CFO, and on its own covered roughly 40% of the project cost.
The managing director's feedback (given after project close-out, with permission for this case study quote):
"The smartest decision was that we didn't try to replace the entire process. We could measure the small steps, and the team accepted the AI rollout once they saw with their own eyes that it worked. The 80 manual validations during soft launch felt daunting at the time, but in hindsight it was the smartest investment we made."
| Item | Cost |
|---|---|
| Discovery (3 weeks, fixed price) | 600,000 HUF |
| Build (8 weeks, fixed price) | 2.4M HUF |
| Hyper-care (4 weeks, included) | included |
| OpenAI API token cost (80,000-120,000 HUF/month) | 100,000 HUF/month |
| n8n self-host VPS (DigitalOcean) | 8,000 HUF/month |
| HubSpot Starter (already in place) | 0 (pre-existing) |
| Twilio SMS (~500 SMS/month) | 15,000 HUF/month |
| Total build cost | 3M HUF |
| Monthly operating cost | ~125,000 HUF |
ROI estimate: recovering 3 previously-lost deals plus sales-time savings adds up to roughly 6-8M HUF/year in value. ROI closes within 12 months.
Three weeks of discovery looked long, but the manual labeling of 800 emails wouldn't have happened without it. The eval set is the backbone of the project — and there's no eval set without manual data. Don't compress discovery just because the client "wants to see money moving."
We didn't switch on all four categories at once. Technical went first (the easiest), with a week of monitoring; commercial followed, and complaint and partnership only went live in week 13. That's two weeks of "slowness," but it dramatically cut the risk.
The 60-item eval set was right on launch day, but new edge cases keep coming. During hyper-care we added 5-10 new cases a week. By week 17, the eval set had grown to 110 items.
An AI system is only effective if the sales team uses it, rather than ignoring it. The manual-validation phase in the early weeks existed exactly for this: to let the team get used to the flow, make suggestions, and develop a sense of ownership over the system.
OpenAI API token costs can slip easily. We logged the cost of every classification in the audit_log table, shown on a daily dashboard. If a day went above $5, it triggered an alert. (Typical daily cost: $1-3.)
Related articles from us: Building a RAG chatbot — a deeper look at the vector-DB and LLM-context side. Defending against LLM hallucinations — confidence-scoring and output-validation techniques. AI implementation at Hungarian SMBs — SMB-specific ROI calculations.
The success of an AI project doesn't hinge on model accuracy — it hinges on the quality of discovery, how well the sales team is brought on board, and an iterative launch. 94% eval-set accuracy is the destination, not the starting point.
The full project took 4 months, with a build cost of 3M HUF. Monthly operating cost runs 125,000 HUF. ROI closed within 12 months — driven mainly by the 3 recovered deals and the sales-time savings.
If you're planning an AI lead assistant, let's talk it through on a 30-minute call. The discovery cost (200,000-600,000 HUF) typically gets absorbed by the deals you stop losing within the first month — if the problem is real.
About the author
Corevanix Kft.
Technology partner
Budapest-based technology partner — SAP/ERP integration, web development, AI automation and mobile app development. We work inside the client’s own environment, and the delivered code belongs entirely to the client.
Legal basis, a DPA with the AI provider, EU data residency, pseudonymisation, retention and training opt-out, the balancing test, the AI Act and a checklist.
Prompts are code: repo, versioning, review, template structure, few-shot examples, eval sets, regression tests, injection defence, cost and observability.
OCR + LLM pipeline, JSON-schema extraction, validation with human-in-the-loop, SAP/ERP integration, error-rate tracking and ROI for invoices and contracts.