PROVE in practice: taking one request from idea to measured result

A method is easier to understand when you watch it handle a real request. This article follows one request through all five steps of PROVE: Pinpoint the opportunity, Rank by value, Own the decision, Validate delivery and Evaluate the outcome.

The company and the numbers are fictional, but the shape of the request will be familiar to anyone who has run an IT intake process.

The request

The head of customer service at a mid-size distributor sends a request to IT: "We need a chatbot on the website." It arrives on a Tuesday, alongside twenty other requests, with a note that the CEO saw a competitor's chatbot and liked it.

Without a method, this request has two likely futures. It gets approved because of who is asking, or it sits in a queue until someone escalates. Neither outcome has anything to do with whether a chatbot is worth building.

P: Pinpoint the opportunity

The first conversation isn't about chatbots. It's about the problem. When the product owner asks what a chatbot would fix, the answer is that the service team is overwhelmed by calls, and most of those calls are customers asking where their order is.

That reframes the request entirely:

• Problem: order-status questions take up a large share of the service team's call time, which drives long hold times for customers with harder problems.
• Objective: reduce order-status calls so the service team can spend more time on complex issues.
• Measure: order-status calls per week. The current baseline, pulled from the phone system, is about 1,200. The target is 700 within three months of release.
• Impacted products and teams: the customer website, the order management system, and the team that owns the shipping carrier integration.

Notice that "chatbot" no longer appears. A chatbot is one possible solution. An order-tracking page with proactive shipping emails is another, and it may be cheaper. Pinpointing the problem opens that comparison instead of closing it. For more on this step, see how to write a problem statement for an IT request.

R: Rank by value

With a stated objective, the request can now be compared with everything else competing for the same capacity. The team scores two candidate solutions:

• Chatbot: high complexity (new vendor, integration with order data, training content), moderate value, and real risk that customers still call when the bot can't answer.
• Order-tracking page plus shipping emails: moderate complexity (mostly integration work the shipping team already understands), similar expected value, lower risk.

Both are ranked in the same list as the rest of the portfolio, including a long-postponed upgrade to the shipping integration itself. That upgrade turns out to matter: the tracking page depends on it. Ranking it on the same scale exposes the dependency and moves the upgrade up the list, rather than leaving it in a separate maintenance bucket where it would keep losing to new features.

The tracking-page option ranks fourth in the portfolio. The chatbot ranks below the line. See a value vs. complexity matrix that works for how to run this comparison.

O: Own the decision

A ranked item isn't a commitment until someone owns it. The decision record names:

• Sponsor: the head of customer service, who framed the problem and the value case.
• Owner: the product owner for the customer website, who is accountable for delivering the result, not just the feature.
• Rationale: the tracking page was chosen over the chatbot for lower risk and complexity at similar expected value. The chatbot remains an option if order-status calls don't fall as expected.
• Assumptions: customers will use a self-service page if it is linked from order emails, and carrier data is accurate enough to display.

Before work starts, the shipping integration team and the order management team each confirm their part and their estimate. That confirmation is what turns a hopeful date into a commitment people can stand behind. See sponsor vs. owner accountability.

V: Validate delivery

Six weeks in, the delivery data shows the shipping integration work running slower than planned. Because the dependency was named in the Rank step and confirmed in the Own step, the owner sees it early and raises it at the weekly review, weeks before the target date rather than days.

The team splits the release: the order-tracking page ships first using the existing carrier feed, and proactive emails follow once the integration upgrade lands. Before calling the first release done, the owner confirms it meets the acceptance criteria the service team agreed to: order status visible within one click of the confirmation email, for every carrier the company uses. See leading indicators that a project is in trouble.

E: Evaluate the outcome

Three months after the tracking page ships, the owner and sponsor run a short outcome review. Order-status calls have fallen from about 1,200 a week to about 820. That is real progress, but short of the 700 target.

The review finds the gap. Customers who never open the confirmation email don't know the tracking page exists. That points to a concrete next step: proactive shipping emails, which are already in progress. It also produces a lesson for future ranking. Self-service projects at this company need a plan for how customers will discover the new option, or the expected value is overstated.

That lesson is the real payoff of the final step. The next time a self-service request is ranked, its value estimate will account for adoption. See closing the loop with outcome data.

What changed because of PROVE

Compare this with the path the request would have taken without a method. The company would likely have bought a chatbot because the CEO liked one, with no stated objective, no baseline, and no one checking afterward whether call volume moved. The shipping integration upgrade would have stayed buried. And nobody would have learned that discoverability drives the value of self-service.

PROVE didn't make the decision for anyone. It made sure the decision was made on stated value, by an accountable owner, and then checked against reality. You can see where your own organization stands on each step with the PROVE self-assessment.