A generic discovery script — pain, budget, authority, timeline — was built for a world where the buyer sitting across from you understands software categories and can articulate their own requirements in software terms. A lot of vertical SaaS discovery calls don't have that buyer. The person on the call might be a clinic owner who has never evaluated a SaaS product before, describing their problem entirely in the vocabulary of their trade, and a script built around generic qualification questions extracts almost nothing useful from that conversation. Discovery in a vertical market has to be rebuilt around the specific workflow the product replaces, not around a generic sales methodology.
Why BANT and MEDDIC underperform in a vertical market
These frameworks assume the prospect can self-report their own pain in a way that maps cleanly onto the vendor's solution space — "what's your current process for X, and what's broken about it." A prospect deep in a specific vertical usually can't answer that abstractly; they can only describe what happened last Tuesday when a specific job went wrong. Discovery has to meet them there. Instead of "what's your pain point with scheduling," a workable vertical question is something concrete and industry-specific: "walk me through what happens between when a customer calls to book a service and when the invoice goes out." The answer to that question surfaces the actual workflow gaps, while the generic version usually gets a vague, unhelpful answer because the prospect has never had to compress their business into "pain points" before.
A discovery call that uses the prospect's terminology back to them — the exact words their industry uses for a job, a client, a shift, a route — builds credibility fast and gets more honest answers than a call run in generic SaaS-speak. This is also why the person running vertical discovery calls benefits from real domain exposure, not just sales training.
Why the buyer is often not the user
In a lot of vertical markets, the person who signs the contract and the person who lives in the software daily are different people with different incentives. A practice owner buys the scheduling system; the front-desk technician uses it eight hours a day. A fleet owner buys the dispatch software; the dispatcher and drivers use it. If discovery only talks to the buyer, it captures the business-level reason to buy (cost savings, compliance, growth) but misses the workflow friction that will actually determine whether the user adopts the tool or quietly reverts to the old spreadsheet within a month. The strongest vertical SaaS discovery processes insist on at least one conversation with an actual day-to-day user before the deal is qualified, even if that means slowing the sales cycle down to get it.
A deal that looks qualified because the owner is enthusiastic can still fail to renew if the frontline staff never actually adopts the tool. Treat "have we talked to a real user, not just the buyer" as a hard qualification gate, not a nice-to-have — it's a stronger predictor of retention than budget authority is.
Qualifying on workflow fit, not company size
Horizontal SaaS often qualifies leads on firmographic proxies — headcount, revenue band, tech stack. Those signals are weak in a vertical market because two businesses of identical size in the same industry can have wildly different workflow complexity: one dental practice runs a single location with paper charts, another runs three locations already using a competitor's software and needs a migration path. The qualifying question that actually predicts a good-fit customer is closer to "does their current workflow resemble the shape our product assumes," not "are they big enough to afford us." A prospect whose workflow doesn't fit the product's model at all is a bad deal regardless of budget, because the implementation will be a fight against the product's assumptions the whole way through.
Wrapping up
Discovery in vertical SaaS fails when it's run like discovery for a horizontal tool — generic pain questions and firmographic qualification miss what actually matters here. The prospect usually can't self-report their pain in abstract software terms, so questions have to be concrete and grounded in the industry's real workflow. The buyer who signs is frequently not the user who lives in the product, and skipping a conversation with the real user produces deals that look qualified on paper and churn in practice. Qualify on whether the prospect's actual day-to-day workflow fits what the product assumes, not on company size or budget alone.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.