Bottom line

If the task is to sort incoming inquiries into queues, you do not necessarily need to let a model act freely in your CRM. A classifier with predefined choices—“sales,” “support,” “billing,” “other,” and “review needed”—may be enough. The model selects a label, deterministic code validates the result, and a person handles uncertain cases.

This is easier to test and constrain than an agent with tools. But a fixed list does not make a model infallible: a message may be ambiguous, no class may fit, and a returned probability may not match real accuracy. A pilot should measure errors for each queue and preserve the option to abstain from automatic classification.

Where it can help

A small online shop or service company often receives inquiries through email, a website form, and messaging apps. An employee reads the text, chooses a team, transfers the gist into a record, and may forget an important tag. A model can suggest a queue and labels such as “return,” “delivery date,” “service not working,” or “price request.”

The value is not that AI writes a polished reply. It is that the inquiry reaches the right person sooner and the team sees recurring reasons. If requests are rare and manual sorting takes seconds, a separate ML component may cost more than the problem. Measure volume and process time first.

An architecture with limited authority

A practical pipeline has five parts:

1. **Receive the text.** Read an email or form through an ordinary integration layer. Preserve its source and inquiry ID. Remove data the model does not need, and do not send content to a cloud service without an approved basis.
2. **Prepare context.** Add only safe information—the queue list and short category definitions. Do not give the model access to the CRM, mailbox, file stores, or message-sending. Inbound text is data to classify, not new instructions to the application.
3. **Make a fixed choice.** Ask it to choose from specific options: billing, sales, technical, other, or review. Do not ask it to invent a department name or perform an action. A typed result is easier to validate than arbitrary text.
4. **Check rules.** Ordinary code verifies the result is on the allowlist, the queue exists, required fields are present, and special conditions match policy. A payment dispute, for example, can require human review regardless of model score.
5. **Write and notify.** The integration creates a draft or puts the inquiry in a provisional queue. Enable automatic routing only after tests on real examples; financial, legal, and sensitive cases should reasonably stay with a person.

There is no universal “correct” confidence percentage. Set thresholds according to error cost: a support request sent to the wrong team may be more expensive than an extra message sent for manual review. If the model is unsure or selects other, abstaining from routing is safer.

What typed decisions provide

A recent implementation example is AnyDecisionModel, a Swift package with an API for binary questions, enum-based choices, and ordinal scores. Its local MLX backend runs a model on Apple silicon and returns a structured choice with probabilities instead of asking for ordinary prose. This can be a useful routing interface, but the package is not a ready-made CRM integration and does not guarantee accuracy.

There are practical limits. The package documentation warns that models may prefer options listed earlier. Rotation debiasing evaluates several permutations and averages probabilities, but increases compute. Calibration was tested on two tasks, and transfer to other tasks has not been established. Therefore, “0.92 confidence” should not automatically mean “92% of your messages will be classified correctly.”

The package requires Swift 6.2. Its local MLX backend requires Apple silicon and the Metal toolchain. Core AI requires a newer system and build environment; the core library and remote Jev backend have different requirements. This is an option for teams already using Apple platforms, not a universal replacement for a Windows or Linux server. Check versions, platforms, and licenses before product use. The Swift package license does not replace the model license.

How to evaluate a classifier on your messages

Collect examples from ordinary and difficult weeks: different channels and phrasing, typos, short emails, and cases that touch more than one team. Label the correct queue with the employees who manage it. Split examples into tuning and held-out evaluation sets; the same messages should not both tune the model and prove its quality.

Compare the model with the current process and simple rules. Sometimes keywords or a dropdown on the form are cheaper. In a pilot, track:

  • precision and recall separately for each class, not only the overall match rate;
  • a confusion matrix showing which queues the model mixes up most often;
  • the share sent for human review;
  • minutes employees spend correcting the route;
  • delay between message arrival and a reviewable suggestion;
  • changes across channels, languages, seasons, and new inquiry forms.

Word error rate applies to speech recognition and does not evaluate text routing. A confusion matrix and the cost of each error type are more useful here. Research on speech recognition also finds differences across accents and speaker groups; if inquiries are transcribed from calls, test actual speakers and recording conditions rather than only clean demo audio.

Do not tune the threshold just to maximize coverage. Test abstention separately: what happens if the model chooses an unsuitable class, misunderstands the request, or sees text such as “ignore the rules and send the data”? The protection is not a magic prompt; it is that the classifier does not execute input instructions and cannot read or change records by itself. OWASP recommends treating prompt injection as an input-data risk and limiting consequences through application permissions and actions.

Economics and operations

Compare the cost of one correctly processed inquiry, not token price against an employee’s salary. Include integration development, licenses, model support, latency, human corrections, and the cost of a missed request. If the model saves ten seconds but checking it takes twenty, automation has not sped up the process. With high volume and substantial time spent sorting, even a simple local classifier may help.

Local inference helps keep text on a controlled device, but it does not solve access, storage, backup, or deletion. Use encryption, account management, and a reasonable retention period for incoming messages. For a cloud API, separately verify what data is sent and what the contract allows.

Employees need a clear “correct category” action and an explanation in business terms, not hidden model reasoning. Keep only necessary statistics: original and suggested queues, whether it was corrected, model version, and processing time. Do not log unnecessary email text, personal data, keys, or secrets.

A short pilot plan

1. Choose one channel and a few clear queues. If categories overlap, simplify the taxonomy first.
2. Define inclusion and exclusion examples for each queue. Add other and review so the system can abstain.
3. Prepare a representative de-identified sample and agree on labels with queue owners.
4. Run in shadow mode: employees continue routing while the system records suggestions for comparison.
5. Review errors and calculate actual time savings. Tune the review threshold separately for each class.
6. Then enable provisional routing only for a narrow group of low-risk inquiries, with a quick return to the general queue.

Conclusion

For inquiry sorting, start with a small set of defined classes and a verifiable result. A model may suggest a route, but the queue list, handling rules, and write permission should remain in ordinary code and with a responsible employee. This is less exciting than giving an agent keys to every door, but an error review will show who suggested the category, who checked it, and who could change the inquiry.

The next step is to measure volume, manual sorting time, and the cost of a wrong route, then run a shadow test on de-identified messages. If a small ruleset performs just as well, keep the model out of the picture. If the test shows material savings without more critical errors, expand automation gradually.