4 min read
What you have at the end of a Discovery
A map, three numbers and a proposal: the four things on the table at the end of a Discovery, and why we charge for them.
At the end of a Discovery there are four things on the table. A map of how the operation actually runs, workarounds included. Three numbers for each area we studied: volume, minutes per item, error rate. A ranked list of what to build. A written proposal for the first Build, with a success measure you can check. Everything before that point exists to produce those four things. Here is how each one gets made.
Why we start here
Every engagement starts with a Discovery, and we do not skip it even when a client arrives with a clear request. The request tells us what you want; the Discovery tells us what the operation needs, and the two are not always the same. It is also where we decide, together, whether we are the right fit. Sometimes the right outcome is “buy this off the shelf,” and we would rather say that in week two than in month four.
A Discovery runs between one and three weeks, depending on the size of the operation and how many areas you want covered. Here is what happens in it.
Step 1: We watch the team work
An engineer and a lead join your team on Teams or video calls. For the first few days they do not propose anything. They watch. If the area is receiving, someone walks the camera through the dock while trucks come in, and they see what gets scanned, what gets written on paper, and what happens when the delivery does not match the purchase order. If it is accounts payable, the clerk shares her screen while invoices are matched, and they notice which ones get set aside and why.
We ask a lot of questions, mostly “what happens next?” and “how often does that happen?” We are looking for the moments where the official process and the real process diverge, because that gap is usually where the software opportunity is.
Step 2: We pull the numbers
Watching gives us the shape of the problem. Data gives us the size. We ask for exports from whatever systems you have: order history, invoice logs, schedules, ticket queues, and the spreadsheets people keep on the side. We count things rather than estimate them.
Three numbers matter most:
- Volume. How many items of this kind come through in a week or a month.
- Minutes per item. How long each one takes a person to handle, including the hunting and re-keying.
- Error rate. How often an item has to be touched twice, corrected or escalated.
These three numbers tell us what a process costs today. Later, they tell us whether what we built helped.
Step 3: We map the flow
Next we draw how the operation runs today, step by step, including the workarounds. Where information enters, where it is copied by hand, where it waits, where it gets lost. The map is plain and visual. Your team should be able to look at it and say “yes, that is what we do,” and correct it where we got it wrong.
The map is yours regardless of what happens next. For many operations it is the first time the whole process has been on one page.
Step 4: We rank what to build
With the map and the numbers, candidates for software become obvious. Usually there are more than you expected, and some are small. We score each one on two things: how much time or error it removes, and how hard it is to build. The ranked list that comes out is deliberately short at the top. We are looking for the first piece of software that pays for itself quickly and that the team will actually use.
Step 5: We scope the first Build
The last step is a written proposal for the first Build: exactly what it does, what it does not do, what it connects to, how it will be shipped in stages, and a fixed price. It also names the success measure, drawn from the numbers in step 2. “Minutes per invoice drops from this to that,” or “order exceptions are caught before shipping instead of after.” Something you can check.
What you get
At the end of a Discovery you have:
- A map of how the operation runs today, including the workarounds.
- Baseline numbers for each area we studied: volume, minutes per item, error rate.
- A ranked list of what to build, with the reasoning.
- A scoped proposal for the first Build, with a fixed scope, a fixed price and a success measure.
If you decide not to continue with us, all of this is still useful. You can hand the proposal to another team, or use the map to fix the process without software at all.
Why it is paid
Discovery is a fixed fee, credited in full toward the first Build. We charge for it for two reasons.
First, it is work. Experienced people spend weeks studying your operation and produce something you can act on. Free discovery is a sales call with a longer agenda, and it tends to produce the answer that leads to the largest project.
Second, paying for it keeps both sides honest. You commit your team’s time, we commit experienced people, and the output is judged on its own merits. If the right answer is “do not build anything,” we can say so.
What happens next
If the proposal makes sense, the Build starts, usually with the same engineer who did the Discovery, and the first stage is in your team’s hands within weeks. We launch it with your team, and Evolve keeps it maintained and improving month by month. But the main thing to know about the first few weeks is this: we are learning your operation, not selling to it.