The shift in the conversation
There's a moment in most deals where the conversation changes character. The user has stopped asking whether your platform can do what they need. They've decided — usually quietly, usually without announcing it — that you're probably the answer. Now they're trying to figure out what they're actually buying and how the integration is going to work.
This is scoping. The shift is subtle but recognizable once you've seen it a few times. The questions get more specific. The architecture diagrams come out. The user starts using "when" instead of "if." A new person joins the call who's clearly there to plan implementation, not evaluate fit. The whiteboard fills up with their actual flows rather than your generic ones.
Scoping is a different kind of work than discovery, and it requires a different posture from you. In discovery, your job was to understand. In scoping, your job is to translate that understanding into a concrete plan — what they're going to use, how the pieces fit together, what the integration looks like, where the risks are, what gets deferred to a later phase. The work is more operational, more specific, more concrete. The cost of being vague is higher because vague answers in scoping turn into bad assumptions in implementation.
Map requirements to products
The core deliverable of scoping is a working map between what the user needs and what your platform actually offers. This sounds mechanical, but it's where a lot of judgment lives.
The user's stated requirements aren't the full picture. They're the visible part of an iceberg that includes implicit requirements they haven't articulated, requirements they don't know they have yet, and requirements that will only emerge once they're actually in the integration. Part of your job in scoping is to surface the parts of the iceberg they haven't seen.
A useful way to work through this is to walk through their flows in detail, end to end, with them. Not your demo flow — their flow, the one their users will actually go through, mapped onto your platform's capabilities. As you walk through it, you'll find places where the mapping is clean, places where it requires a specific configuration, places where it requires custom work on their side, and places where there's a real gap. All four of those are worth surfacing, with the right level of specificity.
The clean parts are the easy ones to talk about. The configurations require you to know your platform deeply enough to recommend the right pattern. The custom work needs to be sized honestly — "this is something you'll need to build, here's roughly what it involves" — without being either dismissive ("oh, that's easy") or alarming ("that's going to be a major project"). The gaps require the most care, because gaps are where deals fall apart late if you don't surface them early.
Surface the gaps deliberately. Don't bury them, don't soften them, don't paper over them with vague language. The user who learns about a gap during scoping has time to plan around it. The user who learns about it during implementation, three months in, has a problem.
Phasing matters more than you think
A lot of users come into scoping wanting everything at once. The full vision, all the integrations, every use case, all in the first phase. This is rarely the right answer, in the same way that "I'd like to learn to swim by entering the Olympics" is rarely the right answer. A useful service you can offer is helping them think through phasing.
Good phasing makes the first phase achievable, valuable on its own, and sets up the second phase cleanly. Bad phasing makes the first phase huge, brittle, dependent on too many simultaneous changes, and doesn't deliver clear value until everything is in place. The temptation toward bad phasing is strong because the user wants to feel like they're getting the whole thing, and biting off the smaller piece feels like settling.
The framing that helps here is to talk about value milestones rather than feature scope. What's the smallest thing we could ship that would actually be valuable to your users? That question often reframes the conversation productively. The user shifts from "what's the full feature set" to "what's the minimum useful version," which leads to a phase plan that has a much higher chance of actually launching on time.
Be specific about what's in each phase and what's deferred. Vague phasing is worse than no phasing. It lets everyone leave the room with different mental models of what comes when, which is how, six months later, three different people on the user's side simultaneously believe a feature is in phase one, phase two, and "definitely not happening." If phase one is the core checkout flow with a single payment method and phase two is alternative payment methods and saved instruments, say that, in those words, in writing. Specificity isn't bureaucracy. It's protection against the disagreements that show up later.
Deeper dives, more specific people
By the time you're in scoping, the people in the room have usually shifted. The early discovery calls might have included a product person, a senior engineer, maybe a manager. Scoping tends to bring in the people who will actually do the work — the engineers who own the integration, the platform team who owns the infrastructure, sometimes a security or compliance reviewer.
The conversations get more technical and more specific. The questions are about edge cases, failure modes, observability, deployment patterns, performance characteristics under load. Some of these you'll be able to answer cleanly. Others you'll need to take offline. Both are fine.
Two things to watch for in this phase.
Don't pretend. When the user's senior engineer asks a question you don't have a confident answer to, the move is the same as it was in earlier phases: name it, take it offline, follow up. The cost of pretending in scoping is higher than in discovery, because the user is now planning their build around your answers. If they make a design decision based on something you said with false confidence, you'll find out about it later, in a tone you don't want to hear.
Bring in the right SMEs. This is the phase where having access to your own internal experts matters most. Whether that's a product manager who knows the roadmap on a specific area, a partner engineer who's seen this integration pattern before, or a senior architect who can give the user a deeper read on a design choice — the value of bringing in the right person at the right moment is hard to overstate. You don't have to be the one with every answer. You have to be the one who knows where to find the answer and is willing to bring in help when needed.
The reflex to handle everything yourself is a junior reflex. Senior SAs are unembarrassed about pulling in expertise. Their reputation isn't built on knowing everything; it's built on the user always getting the right answer, regardless of where it comes from.
When to slow down
There are moments in scoping where the right move is to slow down deliberately, even when commercial pressure is pushing the other way.
The most common one: the user has reached a point where they need to make a real architectural decision, and they're trying to make it on the same call where they first heard the relevant information. This almost never produces a good decision. The right move is to recognize the moment, name it explicitly, and create space. "This is a real decision and I don't want you to make it without thinking it through. Let me put together a written summary of the trade-offs so you can talk it through with your team. Can we come back to it next week?"
This kind of slowdown is uncomfortable for new SAs because it feels like losing momentum. It almost always pays off. The user makes a better decision, the deal closes on a more durable foundation, and your relationship gets stronger because you visibly chose their interest over momentum.
Another moment to slow down: when something the user is saying doesn't quite line up with what they said earlier. Maybe their original use case was about marketplaces and now they're describing what sounds more like a single-merchant flow. Maybe the volume they mentioned in the first call has tripled in the latest one. Maybe the integration timeline they sketched is now compressed in a way that makes the original phase plan unrealistic. When you notice these shifts, ask about them. Sometimes the explanation is simple. Sometimes the shift is the most important signal in the deal.
The general principle: scoping should feel like you're building something carefully, not racing to a finish line. Racing produces deals that close fast and implement badly, which is a worse outcome than careful scoping that closes a quarter later.
Writing things down
Scoping is the phase where written artifacts start to matter most.
In discovery, most of the work happens in conversation. In scoping, the conversations need to land in something durable — a document, a diagram, a project plan, a follow-up email that captures what was decided. The reason isn't formality. It's that the volume of specific decisions in scoping exceeds what anyone can reliably hold in their head, and any one of those decisions can become a problem in implementation if it's been remembered differently by different people.
The artifact doesn't have to be elaborate. A clean recap email after each scoping meeting, in your words, summarizing what was discussed and what was decided, is usually enough. It does two things at once. It creates a written record everyone can reference. And it surfaces misunderstandings, because the user will read your summary and tell you if something is off. The misunderstanding caught in a recap email is much cheaper than the same misunderstanding caught two months into the implementation.
For larger or more complex deals, a more formal artifact might make sense — a written solution overview, a phased project plan, an architecture diagram annotated with which parts use which products. These take more time but they pay back in clarity and continuity, especially if there are multiple stakeholders on the user's side who weren't all in the same meetings.
The thing to avoid is the over-engineered scoping document that takes weeks to produce and isn't actually used. Aim for the smallest artifact that does the job. The job is shared understanding. Anything beyond that is pageantry.
The handoff starts in scoping
If your company has a separate post-sales delivery function — a customer success team, a professional services group, an implementation partner — the handoff to that team starts well before the deal closes.
The biggest mistake in this transition is treating it as something that happens after the deal closes. By the time the deal closes, you've already had ten conversations the delivery team needed to be in. The user has formed expectations based on those conversations. The architecture choices have been made. The phase plan has been agreed to. If the delivery team only sees this for the first time after signature, they'll inherit assumptions they didn't help build, and the user will feel the discontinuity from their first meeting with the new team.
The fix is to bring the delivery team into the deal during scoping, not after. Even a single meeting where the lead implementer joins the scoping conversation, hears the user's plan in their own words, and asks their own questions changes the texture of the entire post-sales experience. The user feels like they're working with a coordinated team rather than being passed off. The implementer arrives with context rather than discovering it after the fact. The hand-off becomes a continuation rather than a restart.
This is one of the highest-leverage things an SA can do, and it's almost always something you have to advocate for. The default in most companies is that delivery comes in after signature, because that's how the org chart is organized and that's what the metrics measure. Override the default when it matters. The user's outcome is better, the delivery team's job is easier, and the deal is more likely to expand later because the implementation lands cleanly.
A note for builders
The biggest mistake I see companies make in scoping is letting commercial pressure compress the phase that least tolerates compression.
A deal that's been in iterative discovery for three months and is now expected to close by end of quarter will, by default, have its scoping phase squeezed. The artifact gets thinner. The phase plan gets vaguer. The handoff gets pushed to post-sales. The user signs and is happy and you celebrate the close. Then implementation starts and the cracks show.
The way to prevent this is to make scoping a real and separate phase, with its own deliverables, its own time budget, and its own definition of "done." A deal isn't ready to close until scoping is actually complete — meaning there's a clear, written, agreed-upon picture of what's being bought and how it's being implemented. If your forecasting and commercial processes don't reinforce that, they'll work against it. SAs aren't powerful enough to fix this on their own. The fix is structural: make scoping a gate, not a checkbox.