Process discovery has become a popular way to open an enterprise pitch. Current state mapping, understanding how work actually happens, capturing human judgment before automating anything. The framing resonates, because it describes a problem buyers recognize.
A buyer who sits through the demo afterward sometimes finds that the product has little to do with it. The discovery language was the door into the conversation. What was being sold was an automation platform, a document tool, an analytics layer or a services engagement, each of which may be a good product and none of which produces the thing the opening described.
This is worth naming because it changes what a buyer has to do in an evaluation. Comparing feature lists assumes the products occupy the same category. When the framing and the product diverge, the comparison is between things that solve different problems, and the differences that matter are invisible on a specification sheet.
Eight questions establish the distinction, and all of them can be asked in a first call.
Key takeaways
- Process discovery framing is common in enterprise pitches, and the product behind it varies widely.
- The decisive question is whether the process picture is an input the buyer supplies or an output the product produces.
- A demo built on a prepared dataset shows the interface, not the discovery.
- Services-heavy delivery is legitimate and changes the economics of the second engagement.
- The unit of output, whether a map, a finding or a fundable initiative, determines what the buyer does next.
- Asking what happens with no existing documentation separates the categories quickly.
The eight questions
1. Where does the process picture come from?
The most informative question in the evaluation, and the one that separates categories fastest.
Some products take a process definition as an input. The buyer supplies the map, drawn in a workshop or derived from documentation, and the product operates on it: monitoring, automating, documenting or analyzing against a model the organization already had.
Others produce the process definition as an output. Nothing is supplied. The picture comes from the evidence the product gathers.
Both are useful and they answer different questions. A buyer whose constraint is that nobody knows how the process runs cannot use a product that requires the process as an input.
2. What happens if we have no current documentation?
The practical version of the first question, and it is harder to answer evasively.
An organization with outdated or absent documentation is the normal case rather than the edge case. A product that requires a starting model will say so when asked directly, which is a useful answer rather than a disqualifying one.
3. Can you show us a process the product discovered?
Distinct from showing a process in the interface. The request is to see output that the software produced from raw evidence, including the parts that were surprising to the organization that ran it.
A product that discovers processes has examples of findings nobody expected. A product that displays processes has examples of well-rendered diagrams.
4. Is the demo running on your data or on ours?
A prepared demonstration dataset shows the interface and the output format, which is reasonable for a first conversation. It establishes nothing about what the product would find in your environment.
The question that follows is what a limited trial on real data would involve, how long it would take, and what it would cost. A product that produces discovery can answer in days. A product that requires configuration against a supplied model answers in weeks.
5. Who performs the work, the software or the services team?
Legitimate answers exist in both directions, and the economics differ substantially.
Software-led delivery means the second engagement costs a fraction of the first, because the population, the structure and the tuning carry forward. Services-led delivery means the second engagement costs roughly what the first did, since the work is performed by people each time.
Neither is wrong. The buyer should know which they are purchasing, because it determines whether they are acquiring a capability or commissioning a project.
6. What is the unit of output?
Three answers are common and they lead to very different next steps.
A process map is documentation. The buyer still has to decide what to do with it.
A finding is an observation with evidence. The buyer still has to build the business case.
An initiative with an owner, an estimated impact and a disposition is a work item. The buyer can take it to a funding decision.
The further down that list a product delivers, the less translation work falls on the buyer afterward, and translation work is where most diagnostic outputs stall.
7. How does the picture stay current?
A product that produces a one-time output is a diagnostic. One that supports repeated cycles at a falling marginal cost is a capability.
The follow-up question is what the second cycle costs relative to the first. If the answer is roughly the same, the product produces snapshots regardless of how it is described.
8. What does it do that a well-run workshop does not?
A fair question and a revealing one. Workshops are inexpensive and most organizations can run them.
Credible answers involve coverage, speed, the ability to compare across markets simultaneously, or reaching people a workshop would never include. An answer built on the quality of the output rather than on what made that output possible tends to describe a better workshop.
Framing and product
What each answer indicates
| Question | Answer pointing to discovery | Answer pointing to something else |
|---|---|---|
| Where does the process picture come from | The product produces it | The buyer supplies it |
| What if we have no documentation | Discovery proceeds | A mapping exercise comes first |
| Show a discovered process | Examples with surprising findings | Examples of rendered diagrams |
| Demo data | Trial on buyer data in days | Configuration period first |
| Who performs the work | Software, with services supporting | Services, with software supporting |
| Unit of output | Initiative with owner and impact | Map or report |
| Staying current | Repeated cycles at lower marginal cost | Repeat engagement at similar cost |
Neither column is disqualifying. The purpose is to know which product you are evaluating.
The categories a discovery framing can cover
| Category | What it actually does | Where the process definition comes from |
|---|---|---|
| Log-based analysis | Reconstructs workflow paths from system event data | Derived from logs, limited to connected systems |
| Desktop observation | Captures activity across applications | Derived from screen activity |
| Documentation generation | Produces process documents from recordings or existing content | From what is recorded or already written |
| Workflow automation | Builds and runs automated steps | Supplied by the buyer |
| Analytics and reporting | Measures performance against defined processes | Supplied by the buyer |
| Consulting engagement | Produces a diagnosis through people | Produced by the engagement team |
| Conversational discovery | Produces the picture from employee evidence at scale | Produced by the product |
Several of these are strong products in their category. The evaluation error is comparing them as though they answered the same question.
Why this distinction is sharpening
Two forces are making buyers more precise about it.
The first is that the problem became widely recognized. Once enough organizations found that an AI deployment failed because the process was not understood, process discovery became the thing every buyer wanted to hear. Positioning follows demand.
The second is that buyers now have experience. An organization on its second or third transformation programme has encountered the gap between the pitch and the product, and it arrives at the next evaluation with specific questions rather than general interest.
That experience is why the eight questions above work. They are easy to answer for a vendor whose product does what the framing says, and awkward for one where the framing is positioning.
What a buyer should prepare
Three things, before the first call.
The constraint, stated precisely. Whether the problem is that nobody knows how the process runs, that the process is known and needs instrumenting, or that the findings exist and nothing is acting on them. Each points to a different category.
One real process as a test case. Describe it to the vendor and ask what their product would produce for it. Specific answers distinguish quickly.
The second-engagement question. Ask what the next cycle costs. The answer separates a capability from a project more reliably than any feature comparison.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform, and it sits in the last row of the category table above.
Discovery Cycles run AI-led interviews across the roles that operate a process, asynchronously and at census scale, with conversations that adapt to each role and follow up on what the person says. The process definition is an output rather than an input, which means the platform operates in organizations whose documentation is outdated or absent.
The Process Library extracts and structures the resulting processes into navigable documentation, built from practice and updated across cycles. The Insights Dashboard ranks findings by impact and effort, with each one traceable back to the employee input behind it. The Initiatives Dashboard converts priorities into business cases, process maps and implementation plans with owners attached, which places the output at the initiative end of the unit-of-output question.
Applying the eight questions to any vendor in this space, including this one, is the point of the exercise. A buyer who asks where the process picture comes from, what a trial on real data would take, and what the second cycle costs will separate the categories faster than any feature comparison.
Evaluation checklist
- Have you stated your constraint precisely enough to identify the category?
- Does the product produce the process definition or require it?
- What happens if your documentation is outdated or missing?
- Have you seen output the product discovered rather than output it displays?
- What would a limited trial on your own data involve?
- What proportion of the engagement is software and what proportion is services?
- What is the unit of output, and how much translation work falls on you afterward?
- What does the second cycle cost relative to the first?
- What does this do that a well-run workshop does not?
- Which specific process will you use as the test case?
Common mistakes
Comparing feature lists across categories. Assumes the products answer the same question.
Accepting a prepared demo as evidence of discovery. It establishes the interface and the output format.
Skipping the second-engagement question. It is the fastest way to tell a capability from a project.
Treating services-led delivery as disqualifying. It is a legitimate model with different economics, and the buyer should know which they are purchasing.
Evaluating without a specific test process. General questions produce general answers.
Assuming the opening framing describes the product. It describes the problem the vendor believes you have, which may be accurate and separate from what they built.
FAQ
How do you evaluate a process discovery vendor?
Establish whether the product produces the process definition or requires it as an input, what happens with no existing documentation, whether you can see output it discovered rather than output it displays, what a trial on your own data would involve, who performs the work, what the unit of output is, and what the second cycle costs.
Why do so many vendors open with process discovery?
Because the problem is widely recognized. Enough organizations have found that an AI or automation programme failed because the process was not understood, which makes discovery the framing buyers respond to. Positioning follows demand, and the product behind the framing varies by category.
What is the difference between producing a process map and discovering one?
Producing a map means rendering a process the organization supplied, drawn in a workshop or derived from documentation. Discovering one means deriving the process from evidence the product gathers. An organization whose constraint is that nobody knows how the work runs needs the second.
Is a services-heavy delivery model a problem?
No, and it changes the economics in a way worth knowing. Software-led delivery means the second engagement costs a fraction of the first because setup carries forward. Services-led delivery means each engagement costs roughly what the previous one did, since people perform the work each time.
What should you ask in a first vendor call?
Where the process picture comes from, what happens if you have no documentation, and what a limited trial on your own data would take. Those three separate the categories faster than a feature discussion, and all three can be answered in a first conversation.
How do you test a vendor's claims about discovery?
Bring one real process, describe it, and ask what their product would produce for it. Then ask to see a finding from another engagement that surprised the organization that ran it. Discovery produces surprises. Rendering produces diagrams.
Ask what the product does, not what the pitch describes
The opening of an enterprise pitch describes the problem the vendor believes the buyer has. That framing is frequently accurate and it is a separate thing from what the product was built to do.
Eight questions, asked in the first call, establish which category is in front of you. The comparison becomes useful once the categories are settled.
See it. Fix it. Lead it.