The Problem: A Shared Inbox Is Not a Process – It's a Risk
A shared inbox works surprisingly well at the start. But once request volumes, product diversity, and multiple teams converge, it becomes a structural bottleneck.
What we see in practice again and again:
No clear ownership Who's responsible? Who takes over? Who escalates – and when?
Duplicate or missing processing Two responses to the same request – or none at all.
No transparency No reliable metrics on SLA, backlog, peak times, or top topics.
Knowledge depends on individuals Good processing depends on individual employees – not the system.
Fragmenting workstreams Product teams constantly lose focus due to unfiltered requests.
The actual problem isn't email itself. The problem is the missing translation from unstructured input into structured, controllable work.
The Target State: Clear Workstreams – Without More Clicks, Without Friction
The company had a clear goal:
- Separate workstreams per product line and team (e.g., Product A, Product B, Service, Spare Parts)
- Clear responsibilities, defined SLAs and escalation paths
- Faster routing, less manual sorting work
- More context per request (Customer, product, urgency, recommended next steps)
- Full transparency and controllability over volumes and bottlenecks
And crucially: No new tool hell. The process should become faster, clearer, and more robust – not more complex.
The Solution: Ticket System + Intelligent Routing + Insights
We deliberately built the transformation in three stable layers.
1) The Ticket System – The Operational Backbone
Every incoming email is automatically converted into a ticket – including thread, attachments, and metadata.
Why a ticket system instead of an inbox?
- Tickets have status, owner, priority, category, and SLA
- Tickets are measurable (Time-to-First-Response, Time-to-Resolve, Reopen-Rate)
- Tickets are scalable (Queues, teams, automations, audit trails)
A minimally viable ticket model looked like this:
ticket_id
channel = email
customer / domain
subject, body, attachments
product_type (Label)
intent (Label)
priority
assigned_team, assignee
status
timestamps (created, first_response, solved)
confidence_score (from Classifier)
Result: "Emails" became clearly defined work units that can be managed, measured, and scaled.
2) Workstreams per Team: Queues, Ownership, and SLAs
For each product line or unit, we set up dedicated queues – with clear rules:
- Automatic assignment by product and intent
- Defined SLA rules (e.g., First Response within X hours)
- Escalation on impending SLA violation
- Backup logic: Team before individual
This made immediately visible:
- Which teams are stuck in backlog
- Which requests are becoming critical
- Where volume spikes occur
- Which topics regularly recur
The shared inbox was previously a black box. The ticket system made it a controllable process.
3) The Classifier: Automatic Routing & Prepared Insights
Now comes the step that turns "digitized" into real transformation.
On top of the ticket system, we placed a classifier that automatically:
- Classifies (Product line, intent, optionally priority)
- Routes (Assignment to the right queue or team)
- Enriches (Insights, extracted key information, processing suggestions)
What gets classified?
Depending on the product portfolio, typically:
- Product type / product group
- Intent: Quote, spare part, complaint, technical question, service appointment, project/tender
- Urgency (e.g., production standstill vs. general inquiry)
- Language / region (optional)
- Customer segment (optional)
What insights are prepared?
Instead of manually capturing everything each time, the system provides context:
- Brief summary of the request (1-3 sentences)
- Key entities (Article or part numbers, machine model, serial number, location, desired date)
- Next best action (What information is missing? What follow-up questions make sense?)
- Routing explanation (Why the ticket landed in the respective team – important for trust and acceptance)
The goal isn't "AI magic." The goal is: less searching, less sorting, more solving.
Under the Hood: Engineering, Not a DIY Solution
For such a system to work in daily operations, you need a robust setup – not just a model.
Simplified architecture:
- Email Connector (e.g., Microsoft 365 / IMAP)
- Ingestion Service (Threading, Attachment Handling, Deduplication)
- Ticket Core (Data model, state machine, SLA engine, queues)
- Classifier Service (Text preparation → Classification → Confidence score)
- Rules & Guardrails (Fallback rules for uncertainty)
- Insights Layer (Extraction, summary, suggestions)
- Observability (Logs, metrics, dashboards)
- Feedback Loop (Corrections as training data)
Human-in-the-Loop Instead of Flying Blind
A central best practice: Automation needs a safety net.
We worked with confidence thresholds:
- High Confidence → Automatic routing
- Medium Confidence → Routing suggestion, team confirms
- Low Confidence → Triage queue for manual assignment
Every manual correction flows back as feedback – for continuous improvement of the classifier.
Product Updates from the Project: Details That Make the Difference
In addition to the core system, we implemented features that have real impact in daily work:
One-Glance Ticket Briefing
A compact ticket header with:
- Summary
- Extracted core data
- Recommended follow-up questions
Effect: Faster orientation, fewer inquiries.
Standardized Response Templates per Intent
- Professionally formulated
- Team-specific
- With dynamic placeholders
Effect: Consistency and speed without copy-paste chaos.
Transparency for Team Leads
Dashboards for:
- Backlog per queue
- SLA risks
- Volume by product & intent
- Peak times
Effect: Control based on data – not gut feeling.
Audit Log & Explainability
Every automatic decision is traceable:
- Routing reason
- Model version
- Confidence
- Override history
Effect: Trust, compliance, and debuggability.
What Changed: From Reaction to Control
| Before | After |
|---|---|
| Work is "seen" when someone opens the inbox | Every request is a ticket with owner, status, and SLA |
| Priorities arise randomly | Clear queues per product and intent |
| Responsibility is socially negotiated | Automatic routing with safety net |
| Reporting is tedious or impossible | Less context switching, faster processing |
| Full transparency for management and team leads |
The result isn't just faster responses – it's a scalable Inside Sales process.
Engineering Best Practices: Our Key Learnings
- Clean taxonomy first – Better 8-15 robust classes than 40 theoretically perfect ones
- Guardrails beat perfection – Reliability is more important than maximum automation
- Feedback loop from day 1 – Corrections happen – use them systematically
- Observability is mandatory – Monitoring of model drift, routing accuracy, SLA impacts, and throughput times
- Change management is part of the solution – Adoption determines success – not the model
Transformation rarely fails due to technology. It fails due to lack of acceptance.
Conclusion: Digital Strategy & Transformation You Feel in Daily Work
This is exactly what Lotzer Digital Engineering stands for: Strategy, processes, and technology mesh cleanly – and deliver solutions that work in daily business.
If your Inside Sales still lives in a shared inbox today, it's not a small tool topic. It's a scaling problem – and at the same time an enormous opportunity:
- Clear workstreams per product
- Measurable SLAs
- Less friction
- Higher quality
- More throughput without more stress
Want this too? Then let's examine together how a ticket and routing setup can look for you – from the operating model to the classifier and the right insights.