Every deal that made it past discovery cost my CTO one to two days before we could actually scope it.

I've run more than 200 discovery calls for OutcomeCatalyst, and every one that turned into a real opportunity ended the same way. I'd write up my notes and sit down with my partner, our CTO, to work out what the buyer actually needed.

That meeting alone ran an hour, sometimes more. Then the real work started.

He'd pull up builds for similar clients, check our documentation for how we'd solved it before, and then work out what was net new. The process took one to two days on every deal before either of us knew the time and effort it would take to deliver for the client.

I see this happening across industries. A manufacturer's quote request stalls until someone checks the specs against past jobs and prices it. A clinic's new patient idles until someone verifies coverage. The businesses change but the issue doesn't: a lead comes in, and one person has to work out what it would take to fulfill the request before anyone can proceed.

I looked at our own company to find out why. Every question my CTO asked me was really a question that could be answered by our codebase and Confluence, our company wiki. My discovery call notes were the input. Our past work was the reference. But he was the manual lookup.

So we built a Claude skill that does the lookup for us. It takes the discovery notes, checks them against everything we've built and documented in our company knowledge base, and then tells us what already exists, what we'd have to build from scratch, and the total effort it would take.

Now, scoping starts the same afternoon as discovery, and my CTO's first look at a deal is a five-minute review of the Claude skill output instead of a two-day reconstruction.

I call this lead diligence, the work between a lead showing up and knowing what you’d have to deliver, the profit margin it leaves you, and the risk of what could go wrong. Here is the framework to turn yours into a Claude skill that does the analysis for you. Plus, how to run it in your specific industry.

Turning lead diligence into a repeatable Claude skill takes four steps:

Let's take a look at exactly how we did each step below:

Record the next five handoffs between discovery and scoping. Don't clean the transcripts up. The questions asked, in order, are the specifications for the Claude skill, and the places you go to answer each one are the sources you'll connect in the next step.

You're listening for two things. The first is the questions that come up on every deal, which become the skill's instructions. The second is where the answers live.

Some come from a system you can connect directly to your AI to reason over. Others come straight from someone's memory, which represents the hidden data that never makes it into your systems of record (critical that you capture this data in the next step).

Ours came down to the same five questions every time: what have we already built that fits, what's close, what's net new, how much effort is it, and what could go wrong?

Connect the AI to the sources you found in step one. For us that was the codebase, so it could see what we'd already built, and Confluence, so it could see how we'd built and documented it. For you it might be past quotes, job files, a policy manual, a shared drive of proposals, or a ticketing system.

However, the AI can only reference the data it can actually read. If an answer usually comes from memory, it has to get captured in your system of record before the skill can use it. Ensure that any missing data points that live within people’s heads are added to your system of record so the AI can reason over it.

The OutcomeCatalyst platform already connects all of our data sources and holds persistent memory and context of every action across every employee, so this step was done before we started. All we had to do was write the skill and let it reason over what was already there.

The skill runs every time a new discovery note arrives, and does in just a few minutes what my CTO used to do in two days.

But it wasn’t perfect to start. Our first version was too vague. We told it to “scope this deal against our past work,” and it came back with a confident summary that read well and missed the things that mattered. For example, it ended up lumping a net-new build into the work we'd already done, misrepresenting the actual effort it would take to deliver for a client.

The problem was in the instructions. We'd asked for a conclusion instead of the specific questions my CTO asks on every handoff.

So we rewrote it to force the answers he gives every time:

“Here are my discovery call notes. Compare what this buyer described to what we have already built and documented. Tell me what exists and can be reused, what is close and would need adapting, and what would be net new. Estimate the level of effort for each and whether our current engineering capacity can absorb it. Flag any risks. List the questions I would need answered before we could scope this.”

The output is a short document with those sections in that order, and it runs as soon as the notes are saved.

Two things made the second iteration work. The instructions came from the real conversation, so the skill answered the questions we were already asking. And the AI had access to all of the necessary data sources, so the answers point to real work instead of guessing.

Run the skill in parallel with your existing handoff and compare the two answers. When they match, the skill is ready. When they don't, the reason is almost always because part of the answer was living in someone's head. Capture it in your system of record, and the next run gets more accurate.

Keep reviewing the output until it can successfully handle your messy deals as well as the clean ones. Once the answers hold up, make the skill the official first step of the handoff.

The first few times we ran the skill next to our existing handoff process, the thing that stood out most was the gap between the two answers.

The skill would return what looked like a clean scope, but my CTO's version carried things the skill had no way of knowing. A “close” build had burned us in the past and wasn't worth reusing. A buyer’s ask looked standard but had a compliance wrinkle. A “net new” item that was half-built in a branch nobody had documented.

Every miss in those first runs was a piece of knowledge that wasn’t written down anywhere.

That was the real insight. The skill handed us a list of every judgment call that lived only in my CTO's head. Once we recorded those, the skill got better.

The skill only knows what made it onto the record, so its most dangerous answer is the one that looks complete and isn't. On the deals where the real constraint never got recorded, it returns a clean, confident scope with the hard part missing. Treat every answer as a draft to challenge until you've watched it handle the messy deals.

It also pattern-matches to what you've done before. A request that isn’t like anything you’ve seen before sometimes gets forced into the nearest match. When a lead doesn't look like your past work, that's the moment to override it.

And it can sound equally sure on both a slam dunk and a stretch. Without a person overseeing the output, you might green-light the deals you should have walked away from. Keep a human gate on the output until you know it's reliable.

The fix for all three is the same. The more of your real context the skill can see, the smaller the gap it has to guess across. That's why I run mine on the OutcomeCatalyst platform, so the answer is drawn from our complete company context instead of whatever happened to get written down on the deal.

Zach

Founder & CEO, OutcomeCatalyst
Book 30 minutes with me →