Not a bot replacing dispatchers, but relief for the incoming queue
Hans Schramm GmbH, a Munich-based plumbing, heating, and home-renovation company, has about 100 employees. According to Germany's INQA initiative, the business receives an average of 1,200 customer enquiries a week and roughly 28,000 incoming invoices a year. At that volume, a missing address or a misrouted emergency call is costly even when the trade work itself is excellent.
As part of the DigiResHand project, the company introduced a voice assistant called Paul. It answers calls, asks clarifying questions, checks customer details, and routes the request to the appropriate staff. INQA says the assistant handles more than 1,000 calls a week. The CRM partly classifies enquiries by type, such as emergency, quote request, or complaint. Employees can see the activity on a dashboard and intervene. This describes an operating workflow; it does not prove that every call is resolved without a person. The source does not disclose the automated-resolution rate or routing accuracy.
The case matters less for the bot's conversational fluency than for the handoff. The bottleneck is getting a correctly documented request to the next responsible person. If an employee has to ask again for the address, urgency, and customer history, answering the call automatically saves little. Evaluate the whole chain: call → structured case record → category and priority → staff member or emergency team → confirmed action.
What the reported outcomes actually establish
INQA reports that automation of routine work, including invoice-data entry, saves employees up to 15 hours a week. This is an upper estimate in the project account, not a measured average attributable to the voice bot alone; it should not be projected onto every service business. The same account says acceptance of new tools rose from 20% to more than 80% after staff involvement. The measurement methods and system costs are not publicly disclosed. We do not present these figures as an independently audited return on investment.
One strong operational detail is that the assistant was not designed solely by outside developers. First-year trainees, office employees, and first-line support staff took part in testing. Small pilot groups became digital ambassadors who helped colleagues learn the tools. Management did not leave the loop: supervisors have a monitoring dashboard, and employees can take over conversations. Callers are told they are speaking to AI. This working arrangement, rather than a polished synthetic voice, makes the system manageable.
Applying the lesson to a small business
For a service company, clinic, repair shop, or wholesaler, a useful scope is narrow: not “let AI speak to everyone,” but “record a standard request and pass it on without losing context.” First list the ten to fifteen common reasons for calls. Separate emergencies, complaints, payments, and enquiries containing personal data. For each category, define required fields, permitted questions, and the human who makes the final decision.
A minimal architecture combines telephony, speech recognition, classification rules, CRM integration, and a handoff log. A language model can help interpret free-form speech or summarize a call, but it should not set prices, promise a technician's arrival time, or change an order status without a check. Where call reasons form a short, stable list, rules and a conventional form may be cheaper and more reliable than a model.
Local AI is possible here, but the source does not say where Schramm's model runs or identify its provider. This case must not be described as proof of an on-premises deployment. A business requiring its own environment would need to assess local speech recognition, a model for field extraction, telephony, CRM connectivity, updates, and protection of recordings separately. A local server does not make the process secure by itself: access rights, retention, backup, and confirmation that a request reached its owner still matter.
Data, integrations, and the cost of an error
Before a pilot, assemble a de-identified sample of calls or written requests and have people label the correct categories. Accuracy cannot be measured without this reference set. Test recognition of addresses, names, and equipment under real background noise; urgent cases need their own test. An emergency call should have a short route to a person rather than a long “smart” conversation. Case-record permissions should follow the CRM: helping route work does not entitle a bot to reveal another customer's history.
In the pilot report, track more than the number of calls handled:
- the share of enquiries reaching the right team on the first attempt;
- the share of urgent enquiries transferred to a person within the target time;
- manual review and correction time per case;
- missed and repeat calls;
- the cost of telephony, transcription, the model, support, and integration.
Keep misclassifications and review them with the office team. Agree in advance who corrects the case record, who replies to the customer, and when the automation is switched off. Otherwise “minutes saved” turn into another screen that everyone has to inspect manually.
A model calculation is not Schramm's result
Suppose a small service operation receives 500 calls a week and initial recording and transfer take one minute each. The theoretical upper bound is 500 minutes, about 8.3 hours a week. This is a **model calculation**, not an observed Hans Schramm result. It excludes non-standard conversations, case review, corrections, usage charges, and maintenance. If half the calls still require a person and checking each record takes 20 seconds, the net gain is substantially smaller. Measure your own baseline minutes before the pilot.
For an investment decision, compare full monthly costs with verified reductions in repeated clarification and manual handling. Do not multiply a headline “up to 15 hours” by every employee. Choose one process where errors are visible and testable, such as routing emergency calls or transferring invoice fields into a record. These are different processes and require separate success measures.
A first step without a large project
For two weeks, use one phone line or one request category. Record baseline metrics, specify the mandatory fields, appoint an owner for review, and require human confirmation for ambiguous cases. After 100–200 requests, compare the routing with human labels. Expand only when the path to a person is dependable and the time saved exceeds review time and operating cost.
The Hans Schramm experience shows that value does not come from a “talking AI” on its own. It comes from the coordination of people, data, and the route a request follows. The best assistant is the one that does not force a dispatcher to ask for the address again.