The clean version
Most companies will, at some point, draw you a picture of the deal cycle. It's usually a horizontal line with five or six boxes. Qualification, discovery, scoping, proposal, negotiation, close. Neat labels, arrows pointing right.
This is fiction. Real deals do not look like this.
A real deal looks more like a toddler with a crayon, scribbling all over the walls. Lots of energy. Vague directional intent. Periods of confident scribbling that don't, on inspection, lead anywhere. Occasional doubling back to a section of wall they were supposedly done with. The finished picture, if you squint, is recognizably what was supposed to be drawn — but only because someone insisted on calling it that.
The clean version is still useful as a shared vocabulary. It gives you something to point at when you're trying to coordinate with an AE, a manager, or a forecasting system. "Where are we in this deal" is a question with a meaningful answer if everyone agrees on what the boxes mean. But the diagram is a model of aggregate deal behavior, smoothed across hundreds of them. Any specific deal you're working on will not look like that diagram, and if you try to make it look like that diagram you'll do the wrong thing in some of the most important moments.
This chapter is about how the cycle actually behaves, what each phase requires from you specifically, and how to know which phase you're really in — which is often not the phase the CRM says you're in.
The phases, with what's actually happening underneath
Here's the version I find more useful. Five phases, each defined by what's happening between you and the user, not by what's recorded in the CRM.
Qualification. Someone has decided that this opportunity is worth your time and the AE's. Usually the AE has had a call or two before you arrived. The question being answered is: is this a real deal? Real means the user has a real problem, real authority to solve it, and a real reason to solve it on a real timeline. If any of those is missing, you're not in qualification anymore, you're in something else — sometimes useful, often not. Your job in qualification, when you're brought in, is mostly to confirm the technical version of "real": is the use case actually a fit for what you sell?
Intro and discovery. This is where you and the user start to learn about each other in earnest. They learn what your platform does and how you talk about it. You learn what they're trying to build, who's involved, what their constraints are, what they've already tried. The shape of the deal — who's deciding, what they're deciding, when — starts to become visible. This phase is longer than people expect and shorter than it should be. We'll spend the next chapter on it because it's the most underrated phase in the cycle.
Iterative discovery and Q&A. This is where most of the work actually happens, and the place where the clean diagram falls apart hardest. It looks like a loop, not a forward arrow. The user asks a question. You answer it, or take it offline and come back. They ask a follow-up. They bring in a new person who has a different question. They go quiet for a week and come back with a new architecture diagram that changes the conversation. You demo something. They ask for a demo of something else. The deal might be in this phase for a few weeks or for several months. The phase ends when the user has enough information to make a decision, and the duration is mostly a function of how complex the use case is and how many people they have to convince internally.
Scoping. At some point the conversation shifts from "can your product do this" to "what are we actually buying, and how does it get integrated." The user is mostly past evaluation; they're now planning the implementation. You're mapping their requirements to specific products, helping them think about phasing, and probably introducing more people on your side — a delivery resource, a partner, a technical account manager. The discussions get more concrete and more operational. Pricing and contract conversations are running in parallel, mostly outside your view.
Win/loss and post-sales. The deal closes one way or the other. If it closes, your role narrows or hands off. If it doesn't, there's still work — understanding why, leaving the door open for later, capturing the lesson. The post-sales handoff matters more than most SAs treat it, because it's the bridge between the deal you just closed and the relationship you'll have with the user for years afterward.
These phases overlap and bleed into each other in any real deal. You might be in iterative discovery on the technical solution while you're already in scoping on the commercial framework. You might be in qualification on a new use case while you're in post-sales on the original one. The phases are a frame for thinking, not a sequence of tickets.
The phase-mismatch problem
The single most common deal-management failure I've seen is a phase mismatch — where the AE, the user, and the SA each think the deal is in a different phase, and they're all acting accordingly.
The classic version: the AE thinks the deal is in scoping, because they've moved it to "scoping" in the CRM and they're working on the contract. The user thinks the deal is still in iterative discovery, because they have three open technical questions they haven't resolved. The SA thinks the deal is in scoping because that's where the AE said it was, and they're focused on the integration plan. The contract gets sent over and the user goes silent, because they were never actually ready to talk about contracts.
This kind of mismatch is structural. The CRM is a forecasting tool, and the AE has incentives to push deals forward in it. The user has their own internal timeline and their own questions. You, the SA, are the one with the most direct visibility into where the user actually is, because you're the one in the technical conversations. This means the three of you are usually in different phases simultaneously, which is fine, as long as you don't all try to operate in your own version at the same time. Your job is to be honest about that, internally, even when the honest answer is uncomfortable.
A useful question to ask yourself, going into each call: what does the user need to be true for this deal to close? Often the answer is something specific and unresolved — a question about scale, a concern about a specific failure mode, a decision their team hasn't made yet. If that thing isn't true yet, you're not as far along as the CRM says, no matter how many emails have been exchanged. The way to advance the deal is to address the actual unresolved thing, not to push the user toward a decision they're not ready to make.
What each phase needs from you
The shape of your contribution changes across phases. New SAs often default to the same posture in every meeting — heavy on product depth, ready to demo, eager to answer questions. That works in some phases and is actively unhelpful in others.
In qualification, you mostly listen. You're trying to confirm the technical fit, which means understanding what they're really trying to build. The temptation is to start selling — to show how impressive your product is, to demo something cool. Resist it. The user isn't ready to buy, and a too-eager pitch in qualification reads as desperate. The right tone is curious and grounded.
In intro and discovery, you're starting to translate. You're learning their language, surfacing their constraints, building a working model of their problem. You should be talking, but most of the talking is questions. We'll go deep on this in Chapter 5.
In iterative discovery, your job shifts toward expert and trusted advisor. The user has specific questions. You answer them with precision. You bring in SMEs when you should. You're proactive about surfacing things they haven't asked about but should know. This is where you build the relationship that decides whether the deal closes — not on whether your product is impressive, but on whether you, specifically, are someone they want to keep working with.
In scoping, your job shifts toward operator. You're mapping requirements to a concrete plan. You're introducing the right people for the next phase. You're being careful about what gets put in writing and what doesn't, because anything specific in scoping shows up later in implementation. Be specific where you can be specific, and be honest about where you can't yet.
In win/loss, regardless of outcome, your job is to leave the relationship in good shape. If you won, the handoff matters more than the celebration. If you lost, understanding why and leaving the door open matters more than the post-mortem. We'll cover the post-sales handoff in more depth later.
Sometimes the cycle just looks weird
A real deal often looks, as we said, more like a toddler with a crayon. There are deals that close in three weeks because the user already knew exactly what they wanted before the first call. There are deals that take eighteen months because the user's organization needs that long to move. There are deals that look closed and then go quiet for a quarter and come back. There are deals where the user fires their VP halfway through and you have to start over with a new buyer. There are deals where you do everything right and they pick the competitor. There are deals where you do everything wrong and they sign anyway.
The variability is the job. You can't control most of it. What you can control is your read of where the deal actually is, your honest assessment of what it would take to advance it, and your discipline about doing the right thing for the user even when commercial pressure wants you to skip a step.
One sign that you're getting better at this: the gap between where the CRM says a deal is and where you'd say it actually is gets smaller and more predictable over time. New SAs tend to be optimistic — to over-read user enthusiasm as buying signal, to mistake a lot of activity for forward motion. Senior SAs read deals more conservatively and are right more often. The conservatism isn't pessimism; it's calibration.
The pattern, eventually
If you do this job long enough, you start to recognize patterns. The deal that's moving fast for the wrong reasons. The deal that's stuck on the wrong question. The deal that's actually closer than it looks. The deal that's about to fall apart because of something internal at the user that nobody is saying out loud.
The patterns aren't rules. They're recognitions, built up across enough deals that you can spot the shape of the situation faster than you can articulate why. This is what experience buys you in the role. You'll start recognizing these shapes after maybe twenty or thirty deals, and you'll keep getting better at it for years after that. The only way to accelerate the recognition is to do the deals deliberately and reflect on them honestly.
The next chapter is about the phase where most of the recognizable patterns first show up: discovery.
A note for builders
The biggest deal-management mistake I see in companies building an SA function is treating the SA as a forecasting input rather than a deal-strategy input.
The SA usually has the clearest read on where the deal actually is, technically and relationally. That read is valuable for forecasting — but it's even more valuable for strategy, because the SA can often see the unresolved issue that's actually blocking the deal, the move that would unlock it, or the moment when pushing harder is going to backfire.
If the only thing you're using your SA for is to fill in a confidence percentage in the forecast, you're using maybe twenty percent of what they can offer. The deal-strategy conversation between AE and SA — what's actually happening here, what does the user need, what should we do next — is where the function earns its keep, and it's a conversation that has to be set up deliberately. Make time for it. Build the cadence. Reward the SAs who bring real reads, even when the reads are uncomfortable.