5
Mar
When UAT Turns Into a Debate: A 30-Minute Triage Playbook
It’s 4:47 PM on a Thursday. The release candidate has been “green” all week until someone runs a real-world scenario that hasn’t shown up in any scripted test. Suddenly, four Slack threads light up at once. One person calls it a blocker. Another says it’s expected behavior. Someone else argues users will “just need guidance.” Meanwhile, the delivery lead is staring at the calendar and the go-live comms already drafted.
When you hit this moment, don’t let opinions compete. Run a short triage that forces clarity.
Get on the same page about what’s happening (10 minutes).
Start with facts, not interpretations. What exact steps were taken? What data was used? What did the person expect to happen, and what actually happened (eligible products, calculated price, approval route, order behavior)? Then quickly agree on impact. Does it block quoting? Does it affect a pricing outcome, approval decision, contract generation, or fulfillment handoff? If you can’t reproduce it reliably with the same steps and data, pause the debate and focus on getting a repeatable example first.
Check it against what was signed off (5 minutes).
Pull up the requirement, user story, or acceptance criteria for that flow. For example, what did the business approve for pricing logic, discounting, renewal behavior, and order changes? The goal is simple: confirm whether the current behavior matches what the project agreed to deliver. This avoids “I thought it meant…” debates.
Decide what kind of issue it is (5 minutes).
Pick one label and move forward:
- Build issue: configuration or logic isn’t behaving the way the agreed criteria describe.
- Training issue: the system is working as designed, but this scenario wasn’t covered in the test scripts or training. Users need clarity on the “what to do when…” steps, like which bundle option to pick in an edge case, when a product is correctly ineligible, etc.
- Change request: the criteria never covered this scenario, and stakeholders now want additional behavior.
Choose the right path and lock in the next step (10 minutes).
Now you are not debating. You are routing.
- Build issue: assign an owner, then decide whether you’re fixing it now, providing a temporary workaround, or putting it in the backlog for after go-live. Set a quick retest plan.
- Training issue: create a quick enablement item (one pager, short walkthrough, updated script) and update support materials.
- Change request: log it as a change request, document the impact, and get an explicit approve or decline decision.
The goal isn’t to “win” the argument. It’s to turn a noisy debate into a clear outcome: what we are doing next, who owns it, and how we will validate it. Speed comes from clarity, not last-minute heroics.
Reach out to Milo Massimo for expert help with your Revenue Cloud Implementation