A supplier proposes paid discovery. What should you get for it?

You ask for a system price, and the supplier suggests workshops and discovery first. That can be useful when unanswered questions could materially change the project. You should still know which uncertainty the work will resolve and what you will receive.

The number of meetings says little about the value. A better test is whether discovery lets you make a decision you cannot make today.

Name the questions to resolve

For example: can the current system support the integration, which user roles are needed, how should exceptions work and what belongs in the first release? Separate business and technical questions while showing their dependencies.

Include people who know the process from everyday work. Managers alone may not be able to describe the harder cases or informal steps that currently keep things moving.

Agree tangible outputs

A useful set might include a process description, first-release scope, integration list, key screens and open risks. You also need an effort estimate with assumptions and a clear statement of what still needs investigation.

Not every project needs all these documents. Choose outputs that support pricing, the purchase decision or delivery. For each, identify who will check that it is complete enough for its intended purpose.

Check whether another team could continue

Agree whether the findings can be shared with other suppliers and which file formats you need. Ask whether the proposed approach commits you to a particular product or technology, and why.

Accept discovery by walking through the answers together: what is now known, which decision follows and what remains uncertain. The findings may show that part of the proposed build is unnecessary. That is still a useful outcome if it lets you change the plan before committing a larger budget. A polished slide deck is helpful only if it carries those answers.