The Scoping Call Has One Job: Name the Number
When we rewrote the site last week, one of the decisions we locked in was how the first conversation with a prospect works. We moved away from a paid diagnostic and made the scoping call free. Thirty minutes. No pitch deck.
The format sounds simple, but it forced us to be specific about what the call is actually for.
What the Call Produces
The output of a scoping call is four things:
- The one system worth building first
- The metric that system has to move
- Where that metric sits today
- Where it should sit in 60 days
If we can't fill all four in by the end of the call, we don't take the build. Not "we'll follow up," not "let's scope it in more detail." We pass.
That constraint sounds harsh, but it does useful work. If the client can't name a number the system should move, one of two things is true: the problem isn't software, or the scope isn't clear enough to build against. Either way, starting a project there is a mistake.
What "One System" Actually Means
Most small businesses we talk to have five things they want to fix. Scheduling, quoting, job history, customer records, and some kind of reporting. Those five things are related, and it's tempting to scope all of them at once.
We don't. One business unit, one workflow cluster, one system. Whatever causes the most pain right now and has a number attached to it.
The practical reason is scoping. A system that does five things in one build has five ways to drift. Named integrations and named exclusions, written down before the first line of code, only hold when the scope is specific enough to name them cleanly. A five-unit build is too large to scope that way in one pass.
The less obvious reason is adoption. A team learning one new system has a better chance of actually using it than a team learning five at once. The training day after go-live works better when there's one workflow to learn, not a suite.
The Straight Answer
Part of the scoping call's job is telling a prospect when software isn't the answer.
"You need a hire, not a system." "The spreadsheet isn't the problem, the process is." "There isn't a number here yet." Those are real outcomes. They don't convert to a project, but they're accurate, and they're worth more to the prospect than a build that solves the wrong thing.
We made that explicit in how we describe the call: you leave knowing what it would take, whether or not you hire us. That's the deal on a free scoping call. If we spend 30 minutes and the honest answer is "you don't need to build this," we say so.
Scope and Price on the Call
After last week's relaunch, we quote scope and price on the scoping call itself, not in a proposal sent a week later.
A proposal that arrives five days after the conversation is a different conversation. The context has cooled, the details are in a document the prospect has to re-read, and the price hits cold. Quoting on the call means the price lands while we're still in the room together and can answer questions about what's included and what isn't.
This only works because of the four-point output. You can't quote on a call if you don't have a clean enough scope to name a price. Forcing the scope down to one system with a named number is what makes same-call quoting possible.
What Changes When the Scope Is Written Down
The build contract names integrations and exclusions explicitly, with a written change-order trigger. That's not boilerplate language. It's the thing that makes a fixed-price build actually fixed.
An integration that isn't named in writing before we start is either out of scope or a change order when it comes up mid-project. Writing it down forces both sides to decide: is this in, or isn't it? That conversation happening at the scoping call is a much cheaper version of the conversation than the same one happening at week six of the build.
One call, one system, one number. If we can fill those in, we know what to build and why.