The qualification scripts most SaaS teams run in chat were written by someone who has never closed a deal. I know that's a blunt opening, but I've reviewed enough of these to be confident. They follow a format that made sense for phone qualification in 2003 and got copy-pasted into a chat widget twenty years later. The result is a conversation that feels like a CRM form — just with a typing indicator.
I've spent fifteen years in B2B live chat. Built ChatMetrics from the ground up, generated over $5 billion in pipeline from more than 300,000 leads. When we built the training corpus behind GTM Clarity — over a million real B2B sales conversations — we analysed what actually happens in the exchanges that lead to a meeting booked versus the ones that end with a polite "thanks, I'll take a look." The patterns are clear. And they contradict almost everything the standard chat qualification playbook tells you to do.
Why BANT Doesn't Work in Chat
BANT — Budget, Authority, Need, Timeline — was designed for phone qualification. That context matters enormously. On a phone call, you have someone's full attention for 20 or 30 minutes. They answered, which is itself a signal. The social contract of a phone call means they're going to stay on the line and answer your questions even if they feel a bit uncomfortable. You can read the silence. You can push back, redirect, re-engage.
Chat is nothing like that. Chat is async, fragmented, low-commitment. Someone opens your chat widget while they're also on Slack, half-watching a browser tab refreshing. They typed because they were curious — not because they're ready to be interrogated. The moment you ask "What's your current budget for this?" in the second message of a chat conversation, you've essentially told them you're running a script. They know it. They close the window.
BANT in chat doesn't qualify leads. It interrogates suspects. There's a difference, and your conversion rate feels it.
The deeper problem is sequencing. BANT starts with budget. Budget is the question that creates the most friction, because it forces the visitor to make a commitment — a number, a range, an acknowledgement that money is involved — before you've given them a single reason to trust you. You've asked them to expose their position before you've demonstrated any value. No good salesperson does this on a call. But the chat scripts say to ask it first, and teams run it first, and then wonder why conversations end before they get anywhere.
The Three-Part Qualifying Conversation
What actually works is a structure I'd call Context → Problem → Fit. It maps to how a good conversation naturally unfolds between two people who don't know each other yet. It doesn't feel like qualification because it isn't leading with qualification. Qualification is the byproduct of a conversation that was actually useful to the visitor.
Context is the opening move. You're signalling that you know something about who they are or why they're here. This isn't about being creepy — it's about demonstrating that you're paying attention, that you're not going to waste their time, that this conversation is going somewhere relevant. If you're using identity resolution to recognise company-level visitors, you can be genuinely specific. If you're not, you can still use page context, referral source, or visit history to frame an opener that feels pointed rather than generic.
Problem comes next. Not "what are you looking for?" — that's too open. Not "what does your process currently look like?" — that's too formal. A good problem question names the pain points your ICP actually has, and asks which of those is driving them today. You're not fishing with a blank hook. You're offering them a frame that they can either accept, modify, or correct — and any of those responses moves the conversation forward.
Fit closes the loop. Now you know enough to either qualify them or disqualify them honestly. This is where company size, urgency, decision process, and timeline enter the conversation — but they enter it after the visitor has already told you what they care about, which means those questions feel like natural follow-ups rather than intrusions.
Openers That Work
The opener is the single highest-leverage moment in a chat conversation. It determines whether the visitor stays or bounces, whether they engage or ghost, whether the next exchange feels like a conversation or a funnel step.
The best openers are segmented — by page and by what you know about the visitor. A generic "Hi there! How can we help?" is worse than silence. It tells the visitor they're talking to something that doesn't know who they are, doesn't know why they're here, and is going to make them do all the work. That's not a good first impression.
Here's how segmentation plays out in practice.
For a pricing page visitor where identity resolution has confirmed they're from a mid-market or enterprise ICP company: "Hi [name] — most [company size] SaaS teams come to us when [specific pain point]. Is that what's driving today's visit?" You're naming the pain before you ask the question. You're showing them you're not starting from zero. That single signal — that you've done some homework — is worth more than five perfectly crafted follow-up questions.
For a demo page visitor you don't have a name or company for: "Saw you landed on the demo page — what made you look us up today? Happy to walk you through it live if that's useful." You're not pretending to know more than you do. But you're using page context to demonstrate relevance, and you're offering something concrete rather than asking a hollow open question.
For a return visitor on their third site visit, arriving from a blog post: "Welcome back — looks like you've been doing your research. What questions haven't been answered yet?" Three visits is intent. Call it out. Frame it as a positive. Give them permission to tell you what's still missing rather than starting the whole pitch from scratch.
The Questions That Actually Matter — and Their Sequence
Pain first. Then scale. Then timing. Not the other way round.
Pain first means your first substantive question is about what's broken, what's frustrating, what's costing them time or money or pipeline. Not what they're looking for. Not what their current stack looks like. What hurts. People will tell you what hurts before they'll tell you their budget. Always.
Scale second means once you understand the pain, you contextualise it. How many people does this affect? What does it cost when it goes wrong? Is this a one-team problem or a company-wide one? This isn't qualification by stealth — it's genuine curiosity that also happens to tell you whether this is a $10k deal or a $100k one.
Timing last. "When are you looking to make a decision?" asked before you've established any value is a closing attempt with no runway. Asked after you've understood the pain and confirmed the scale, it's a natural question about what comes next. Same words, completely different conversation dynamic.
Budget is the question most teams ask too early. Fit and interest questions should come before financial commitment questions in every case, without exception. This isn't about avoiding difficult conversations — it's about earning the right to have them.
Handling "Just Browsing"
"Just browsing" is not a dead end. It's an invitation to demonstrate that you're worth a few more minutes of attention without pressuring them into anything.
The wrong response is to treat it as a rejection and either close the chat or pivot immediately to a qualifying question. Both moves read as desperation. The right response is to acknowledge it, offer something genuinely useful, and leave a hook they can grab onto when they're ready.
Something like: "No problem at all — worth knowing we have [specific resource] that most people find useful at this stage. Happy to send that over if you want, or just ask me anything that comes up." You've respected their signal. You've offered value without pushing. And you've left the door open without propping it up with a foot in the frame.
The visitors who say "just browsing" and then re-engage are often higher intent than they initially appeared. They needed a lower-pressure entry point. Give them one.
When to Push for the Meeting vs. When to Nurture
This is where most chat AI gets it wrong. The decision to push for a meeting isn't about how many qualifying criteria you've ticked — it's about reading the signals the visitor is actually sending.
Ask about implementation timeline and you should push for the meeting. That question means they're already mentally inside the product. They're thinking about what it takes to get it running. That's not a browsing signal. That's a buying signal. Every exchange after that should be moving toward a booked conversation.
Ask about pricing without any prior context and you should nurture first. Price questions without context are almost always a proxy for a different question — "is this going to be worth my time to evaluate?" — and pushing for a meeting before you've answered that doesn't accelerate the deal. It just forces a conversation before the buyer is ready, and those conversations rarely go well.
Implementation questions, specific integration questions, questions about your team's onboarding process, questions about outcomes from clients who look like them — these are all "push for the meeting" signals. Broad feature questions, pricing sanity checks, "how does this compare to X" questions — these are "give me more information first" signals. The sequences are different, and treating them the same kills conversion.
There's also the ACV consideration. High-ACV deals need human involvement — our data shows AI closes deals above a certain threshold at 40% lower rates than experienced humans. Knowing when to escalate to a live conversation is as important as knowing what to say in the first place.
Three Scripts: What This Looks Like in Practice
These aren't hypothetical. They're built directly from the patterns in our conversation corpus, adapted for three scenarios every SaaS team encounters.
How to Train AI on These Patterns — Not Just Configure It
Most SaaS teams treat their chat AI like a form builder. They set up triggers, write response options, configure routing rules. That's configuration. It's not training. Configuration tells the AI what to do. Training tells it why, and what good looks like.
The difference shows up in every conversation that goes slightly off-script. A configured AI hits a branching condition it wasn't built for and either exits gracefully to a human or gives a response that clearly doesn't fit the conversation. A trained AI handles the deviation because it has context — patterns from thousands of real conversations about what works at each stage, what signals matter, how to read the difference between a browser and a buyer.
What does training actually look like? Start with your best-converting conversations from the last 12 months. Pull the transcripts. Read them. Not to extract scripts — to understand the pattern. When did the visitor first indicate real intent? What did the rep say just before that? What question unlocked the conversation after a dead response? That's your training signal. Feed it back into your AI configuration as examples, not as rules.
The other thing worth doing: audit your failure modes. Pull the transcripts where qualified visitors dropped off. Where did the conversation go wrong? Usually it's one of three things: the opener was too generic, a qualification question came too early, or the AI missed a buying signal and failed to push for the meeting. Those are fixable — but only if you identify them.
GTM Clarity is trained on over a million B2B sales conversations, which means the pattern library is significantly deeper than anything you'd build from your own transcript set alone. But the principle is the same regardless of which tool you're running: the AI should know what good looks like, not just what the rules say.