Classify Inquiries Before Introducing AI in Customer Service

Prepare customer inquiries before introducing AI into customer service

When a technical services SME receives an inquiry, the answer may depend on a contract, a previous site visit, a machine model or an exception agreed by email. If that information is scattered, adding an AI assistant will not bring order to the service: it may simply make the disorder respond faster and with more confidence than it should.

Effective preparation starts before you choose a tool. It means deciding which inquiries AI can handle, what information it can use, which cases it must escalate and how its performance will be checked. For a B2B company with 5 to 50 employees, this does not require transforming the entire organization, but it does require customer service, operations and management to agree on shared rules.

The trend favors experimentation, but also suggests starting with a clearly defined scope. Eurostat recorded that 13.5% of enterprises in the European Union with 10 or more employees used some form of artificial intelligence technology in 2024, up from 8% in 2023 (Use of artificial intelligence in enterprises). This is a general figure, not a measure of AI adoption among Spanish industrial SMEs. It does show that AI is no longer a distant topic; it does not prove that automating any inbox is a good decision.

1. Classify inquiries by the decision involved, not just the topic

A list of categories such as “breakdowns,” “quotes” and “invoices” is useful for organizing emails, but it is not enough to decide what an assistant can answer. Two inquiries about a breakdown may call for very different responses: one asks about support hours, while another describes a production stoppage requiring immediate attention.

Start by reviewing a sample of real inquiries — for example, those received over four to six weeks — and group them by the work that needs to be done. An initial classification might include:

• Repeatable information: support hours, geographic coverage, documentation required to open a case or contact channels.
• Request follow-up: the status of a request, an expected visit date or receipt of a report.
• Diagnosis or recommendation: symptoms of a fault, spare-part compatibility or equipment configuration.
• Commercial or contractual decision: the scope of an offer, warranty terms, penalties or contract changes.
• Critical incident: risk to people, a facility shutdown, potential additional damage or failure to meet a time-sensitive deadline.

For each group, note the approximate volume, who handles it today, what information is needed and what happens if the answer is wrong or late. This helps distinguish a frequent, low-risk response from a decision that requires professional judgment, even if it comes up often.

Example: a maintenance company receives questions about preventive maintenance. AI could explain what information is needed to request a visit and find the approved procedure. It should not independently confirm that an intervention is covered by a contract if that requires interpreting addenda or checking a commercial exception.

The outcome of this step should be a simple table: inquiry type, permitted response, required information, risk and destination if it cannot be resolved. That table, not a list of software features, defines the first pilot.

2. Prepare reliable sources and rules for exceptions

AI cannot tell which of two conflicting documents reflects the current agreement. So before connecting it to internal information, you need to decide which sources are valid and who is responsible for maintaining them.

Depending on the chosen scope, gather FAQs, support procedures, technical specifications, service terms and approved response templates. For each document, check:

• whether it has an owner and a review date;
• whether it is current and applies to the right service or product;
• whether it includes limitations, warnings and escalation steps;
• whether the assistant can access it without exposing other customers’ data.

You do not need to clean up every company file at once. It is more practical to start with a small, verifiable set. If there are different versions of a manual or special agreements in personal email accounts, the assistant should not treat them as a shared source until someone determines what can be used.

Exceptions deserve an explicit record. A shared spreadsheet can capture situations such as “customers with extended coverage,” “out-of-warranty equipment,” “safety-related inquiries” or “requests for a date that has not yet been confirmed.” For each case, specify what information AI may provide and when it must stop.

Permitted and prohibited responses

Set limits using specific verbs. For example: “It may explain how to open an incident”; “it may summarize the approved restart procedure”; “it must not assure customers that a machine is safe to operate”; “it must not confirm a visit date that is not listed in the system.” These rules are more useful than a generic instruction such as “respond cautiously.”

It is also worth testing incomplete scenarios: a customer who cannot identify the model, an illegible photo or two incompatible versions of a commercial term. The right response may be to ask for the missing information or transfer the inquiry. Not answering yet is better than inventing certainty.

3. Design the handoff to a person and run a limited-scope pilot

AI-assisted customer service works best when handoffs are part of the design, rather than something added after a mistake. Agree on who receives each type of case, how quickly it should be reviewed and what summary should accompany the inquiry.

At a minimum, escalation should be triggered by safety risks, production stoppages, complaints, potential contractual breaches, insufficient information or an explicit request to speak with a person. If there are different severity levels, define them with examples and the relevant channel; “urgent” can mean different things to administration and the technical team.

A sensible pilot could be limited to one channel and two or three types of informational inquiry. For example, an industrial systems integrator could test responses about the documentation needed to open a service request and support hours, without allowing diagnoses or confirmations of coverage. During the test, a person reviews responses before they are sent or checks a sufficiently large sample, depending on the risk.

Before starting, record a baseline for how those inquiries are handled today: how many come in, how long it takes to send the first response, how many are reopened and how many require clarification. Then monitor indicators related to quality and control:

• Accuracy: Does the response match a current, applicable source?
• Appropriate escalation: Did it escalate sensitive cases and resolve straightforward ones?
• Human corrections: What errors or omissions did the team identify?
• Repeat contacts and reopened cases: Did the customer have to explain the problem again?
• Traceability: Can you tell which source supported the response?
• Internal acceptance: Does the staff understand when to trust, review or step in?

Do not judge the pilot solely by speed or the number of inquiries answered. A high response rate can hide late escalations or incorrect information. Review specific examples every week and stop or narrow the scope if safety, privacy or contract interpretation issues arise.

In 2026, it is reasonable to expect more providers to incorporate AI features and customers to get used to fast responses. That does not erase the difference between answering an administrative question and deciding what to do about a breakdown. The operational advantage will depend less on automating everything and more on clearly defining what is repeatable.

4. Avoid implementation mistakes and understand the service model

There are four common mistakes to avoid. The first is connecting the entire document archive without checking that documents are current or that access permissions are appropriate. The second is trying to automate diagnoses, offers and complaints all at once. The third is failing to assign anyone responsibility for updating procedures. The fourth is measuring only the volume of responses and overlooking their accuracy.

It is also a mistake to think AI replaces the technical team’s expertise. In a services SME, that expertise includes nuances that may never have been written down: when an exception is routine, what needs to be confirmed before giving guidance or which customer needs a different process. The pilot helps make those rules explicit, but someone still needs to validate them.

A turnkey implementation usually includes the initial analysis, configuring the assistant with agreed sources and limits, testing and go-live. “Turnkey” does not mean the system automatically knows all the processes or requires no maintenance: the company must appoint someone to review changes to documents and exceptions.

In some models, the customer retains ownership and control of their technology account and pays for usage through an associated wallet. This makes it possible to separate service configuration from platform usage. Before signing a contract, confirm which account will be used, who will administer access and how spending can be reviewed. An all-inclusive price starting at €4,900 can serve as a contextual reference when assessing an implementation, but the actual cost will depend on the scope, integrations and preparation work. It is not a guarantee of savings or results.

Conclusion: start with an inquiry you can govern

Before implementing AI, choose a frequent type of inquiry, gather the valid sources, document exceptions and define when a person should step in. Measure the pilot based on correct responses, escalations, corrections and repeat contacts; expand it only if the team can explain why it works and how it is controlled.

The practical next step is to bring together customer service, operations and management for a brief session and review a sample of recent inquiries. If you come away with an initial table of decisions and sources, you will already have a concrete basis for evaluating an AI solution without automating the chaos.