Qualifying inbound requests with AI: method and limits
- 1AI reads and structures free text; the priority decision should sit in a simple, written grid owned by the sales team.
- 2Test on 150 to 300 past requests before going live, and look first for false negatives: good deals ranked as secondary.
- 3The time saved on triage is often modest; the real gain is speed of response on high-potential requests.
- 4No request is rejected without sample-based human review, and the FADP and the EU AI Act are checked at design stage.
In most SMEs and mid-caps, requests reach the company through four or five channels: the website form, a generic mailbox, the phone, messaging apps, third-party platforms. They are handled in the order they arrive, by whoever is free. The outcome is familiar: a high-potential request waits behind ten that lead nowhere, and by the time someone replies the prospect has often contacted a competitor.
AI can help, provided we are precise about what we ask of it. This guide sets out a six-step method, then the limits. It belongs to our broader work on growth and commercial performance.
What AI does well, and what it should not decide
Current models read free text well. They extract the need, the product concerned, the quantity, the deadline, the location and the language. They condense a fifteen-line message into two, detect urgency and draft a reply.
They should not, however, set commercial policy on their own: which customers we want, from what volume we travel, which requests we decline. These are management decisions. AI applies them; it does not invent them.
Step 1: define what a qualified request is
Keep the definition to one page, agreed by management and sales. Four criteria are usually enough:
- fit: offer, geography, customer size;
- intent: simple information, quote request, imminent purchase;
- urgency: stated or implied deadline;
- capacity: likely budget, access to a decision maker.
Then define four action classes. A: a salesperson replies within the hour. B: reply within the day. C: standard reply enriched with useful resources. D: out of scope, with a courteous redirection.
Step 2: measure the starting point
Before automating, record three figures: time to first response by channel, conversion rate by channel, and time spent on triage. Take an example with explicit assumptions: 60 requests a week and 4 minutes of triage and routing each, so 4 hours a week. The direct time saving is real but modest. The stake lies elsewhere: bringing the response time on the 10 to 15 percent most promising requests from half a day down to one hour, which affects revenue far more than a few hours of triage.
Step 3: separate extraction from decision
This is the most important design choice. AI turns the message into structured fields (need, volume, deadline, customer type, language). A rule grid or a transparent weighted score then assigns the class. The separation makes the system explainable: a sales manager can change a threshold without technical help, and can see why a request was ranked D.
Cross the extraction with the CRM: existing customer, purchase history, open deal. A routine request from an active key account deserves a fast reply. Our use case Inbound request qualification describes this architecture, and the one on automated CRM sales reporting shows how to keep the CRM clean enough for that cross-check to mean something.
Step 4: test on history before going live
Gather 150 to 300 past requests whose outcome is known. Have the system classify them, then compare with the actual outcome and with the judgment of two salespeople, working separately. Look first at false negatives: requests that became significant deals but were ranked C or D. Set the acceptance criterion before the test, for instance: no major deal in class D, and a very small share in class C. False positives cost time; false negatives cost customers.
Step 5: deploy as an assistant, then partially automate
Start with a four to six week phase in which AI proposes the class and a draft reply, and a person validates. Track the manual reclassification rate. Once it stabilises, automate routing and acknowledgement for classes A and B. For class D, never reject without review: a sample is checked every week, and the reply stays courteous and useful.
The principle holds across sectors. In independent hospitality, a group or event enquiry is not handled like an individual booking, and the same prioritisation logic applies, consistent with the pricing approach in Hospitality: dynamic pricing within reach of independent hotels.
Step 6: steer over time
Four indicators are enough: time to first response in class A, manual reclassification rate, conversion by class, and the result of a weekly review of 20 randomly drawn C and D requests. Revise the grid monthly during the first quarter, then quarterly. Field feedback should feed it: what salespeople learn in meetings, as we describe in Sales call reports: what AI changes for field teams, sharpens the criteria better than any model tuning. Likewise, qualified requests reveal price sensitivity and inform the thinking in Pricing: AI in service of margin, not just volume.
The limits to keep in mind
The bias of the past. A system calibrated on history reproduces habits: it underrates segments the company has never served well. If you want to open a new market, the grid must say so explicitly.
Atypical cases. A short, ambiguous or poorly written message can hide a large deal. Provide a "to clarify" class that triggers a follow-up question rather than a risky ranking.
Multilingual input. In Switzerland, requests arrive in French, German, Italian, English, sometimes in transcribed dialect. Test each language separately.
Gaming. Once prospects or partners understand what is rewarded, some write to pass the filter. A periodic review detects it.
Drift. Offer, prices and seasonality change. A grid that is not revised degrades silently.
Upstream processes. If internal routing is confused, classifying faster achieves nothing. This is often a matter of operations and processes before it is a matter of AI.
Regulatory framework: check it at design stage
Requests contain personal data. The revised Swiss Federal Act on Data Protection (FADP), in force since 1 September 2023, requires transparency on purpose, control of processors and care over transfers outside Switzerland, which bears directly on the choice of a tool hosted abroad. It also provides for information when a decision is taken exclusively by automated means and significantly affects the person. Internal prioritisation of business prospects generally falls outside this; automatically refusing a service to a private individual would come closer, and deserves analysis.
The EU AI Act, in force since 1 August 2024, applies in phases, with most obligations applying from August 2026. Commercial qualification is not in principle a high-risk use, but transparency obligations may apply to an assistant that converses directly with people. Swiss companies addressing the European market should pay attention. The assessment is made case by case.
Where to start
Choose a single channel, the busiest one, and a four-class grid. Test on history, validate with the salespeople, then deploy as an assistant. If you want to know whether your inbound requests justify the effort, and in what order to act, our diagnostic establishes that starting point in a few conversations.
A personalised first reading in three minutes.