Classifying B2B sales requests with AI

Short answer

The first step in classifying sales requests with AI is to define a small number of clear labels that match the queues the company actually uses. Instead of forcing ambiguous messages into a class, route them to review, and measure success by the impact of wrong routing as well as accuracy.

Use operational labels

Product interest, new customer, existing customer support and out-of-scope requests should correspond to actual actions. Decide whether a message may carry multiple labels.

Prepare examples

Build a sample set from authorised real requests using only necessary fields. Include rare but important classes. Keep development examples separate from the final evaluation set.

Allow uncertainty

Do not force ambiguous or incomplete requests into a class. Provide human review, correction records and routing rules. Make prioritisation reasons visible.

Measure operational impact

Track errors by class, incorrect routing, correction time and unrecorded requests. Model accuracy alone does not show whether follow-up works.

Keeping the label set simple

Many fine-grained labels increase both the need for sample data and the chance of error. Start with only five or six classes that have an operational meaning, and write down which person or queue each class goes to. Labels can be split as the need is measured.

A practical evaluation exercise

Limit labels to queues the company will actually use. Ask two people to label the same requests independently and resolve disagreements in the process definition before training or prompting. Keep a review-needed route for ambiguity. Evaluate misrouting impact and correction time as well as the proportion classified correctly.

Frequently asked questions

Two questions we are often asked on this topic.

How many examples are needed for classification?

There is no exact number; what matters is that rare but critical classes are represented too. Starting with a small, carefully labelled sample set and widening it according to error analysis is better than a large, noisy one.

How much of a problem is a wrong classification?

The impact depends on where the error sends the request. An error into a low-impact queue is cheap; missing a large customer request is expensive. So track error types separately.