WalkMe discovery and pilot

We run a structured discovery in seven steps, and we finish it with a scoped pilot rather than a proposal. The last two steps are the ones that matter most, because we publish hours and an investment range at the end of the discovery, and we write down our own dependencies as a risk.

1. Current challenges, in your words: The language your people actually used in the room, kept as they said it.
2. Outcomes and measures, agreed before anything is designed: The measure exists before the thing being measured. This is the step that stops a build becoming an expensive guess.
3. Current state, counted: Actual step counts and named friction points. This is where a business case is either real or it isn't.
4. Future state: Issue, proposed solution, key outcome. One row per problem, readable by a steering committee in four minutes.
5. Design principles and rules, agreed up front: How firm the guidance is allowed to be, what gets enforced and what gets suggested. Getting this wrong is a common reason a pilot underdelivers, because people quietly ignore guidance they can ignore.
6. A scoped pilot: Hours, deliverables and an investment range.
7. Risks and assumptions, stated honestly: Including what we need from you, and where we are the dependency.

If the honest answer is that WalkMe isn't the right fit, or that you already own more of it than you need, we will say so. We have not earned anything on a WalkMe licence since September 2024, so there is nothing riding on the answer.