The expansion deal that started as a "how do I export this?" ticket
In B2B software, the most reliable buying signal of the week is sitting in your support inbox right now, disguised as a complaint. An admin opens a ticket asking whether your API can handle a higher rate limit. A technical owner asks how to connect your product to the new system their company just bought. Someone with "VP" in their signature escalates because a feature they need for a board demo isn't working. Each of those is a support issue. Each is also a person telling you, in plain language, that their usage is about to change.
Your support team hears this constantly. Sales and customer success usually find out weeks later, if at all, because the signal never left the ticketing tool. That gap is exactly where AI lead qualification earns its keep for a customer service org: not by answering tickets, and not by auto-firing leads at sales, but by reading the conversations your agents are already having and attaching the context that makes a signal actionable. OECD research on SME AI adoption keeps landing on the same practical rule: start where the source data is clean and the owner is obvious. Support transcripts qualify on both counts. You already own them, and they're already structured by ticket type, severity, and account.
The first workflow worth building is narrow. It reads support conversations for a short list of specific commercial cues, then assembles a routing packet: the ticket text that triggered it, the account's tier and renewal date, recent product usage, the severity of the open issue, and the role of the person talking. The output is a qualified, human-ready handoff with evidence attached. It is never an autonomous verdict, and it never lets the customer feel like their support request became a sales pitch.
Four signals, not one — because not every angry customer is a buyer
The thing most teams get wrong is treating "intent" as a single category. It isn't. A feature request from a power-user admin, an integration question from a technical owner, an executive escalation, and a complaint from the person who signs the renewal are four completely different conversations, and routing them identically guarantees both missed expansion and annoyed customers. Define the categories first. Decide which phrases, ticket types, and product events count as a possible commercial signal, and write down the ones that explicitly do not — a frustrated user mid-outage is not a cross-sell opportunity, full stop.
This is where NIST's AI Risk Management Framework matters more than it looks. Support-to-sales routing damages trust fast when the intended use is fuzzy or when a low-confidence guess gets treated as fact. So the model should mark its confidence, show the exact ticket language behind every route, and send anything ambiguous to customer success for a human read before anyone in sales sees it. Sales and support should agree, in writing and before launch, on what happens to a false positive — because there will be false positives, and the customer relationship pays for them if no one owns the cleanup.
Then there's the data itself. Support tickets are full of account notes, user identities, and sometimes sensitive operational detail. CISA's guidance on securing data used to operate AI systems should shape how that ticket text and account context are handled: preserve the existing support permissions, don't widen who can see a customer's notes just because a model is reading them, and keep an audit trail of what evidence drove each route.
What to do Monday, and the one metric that tells you to stop
Don't build the org-wide version. Pick one product line or one account segment and run a pilot there. Before you turn anything on, get customer service, customer success, and sales in a room and force three agreements: which signals count, who owns the review step, and what a useful handoff actually looks like to the person receiving it. If your support team can't yet articulate the difference between "this ticket is a buying signal" and "this ticket is a problem to fix," you're not ready — wait, and define that line first.
Keep the starting dataset deliberately small: ticket text, account tier, renewal date, product usage, severity, contact role, and your routing rules. That's it. Decide up front which fields are required, which are optional context, and which conditions exclude a ticket from routing entirely. Then measure five things — accepted handoffs, rejected handoffs, sales follow-up time, downstream opportunities created, and customer irritation. That last one is the kill switch. If customers start feeling sold-to mid-support-request, or if your agents feel pressured to upsell instead of resolve, the design is wrong no matter how many qualified leads it surfaces. Repair ownership, permissions, or signal quality before you add a single new category.
The scale decision is simple once the pilot runs: did accepted commercial handoffs go up, did false positives drop after the human review step, and did premature sales outreach (the kind that fires before the support issue is even closed) visibly shrink? If those three move the right way, expand to the next segment. If they don't, the problem isn't the model — it's the handoff. This connects naturally to the broader work of finding manual work worth fixing, and if you want a structured read on where to start across your operation, the AI Opportunity Score is built for exactly that triage.
