A stakeholder request can be useful even when it is not backed by a reliable metric. It tells you where someone is currently making a decision, resolving an exception or compensating for missing information.
The job is not to treat that account as fact. It is to establish what kind of evidence supports it and what the future solution actually needs to represent.
Keep four things separate
Recorded fact. A system record, document or other artefact exists.
Stakeholder account. Someone describes what happens in practice.
Analytical inference. The available evidence supports an explanation, but does not establish it.
Unknown. The project does not yet have enough evidence to decide.
Why this changes requirements work
Suppose a sales manager asks for an approval workflow because discounting is "getting out of control". If the project cannot establish the frequency, value or business consequence of those exceptions, the requirement should not quietly become a workflow specification.
The implementation team can still identify the event, decision, actors and information needed. It can also specify what must be captured so the business can distinguish a real control problem from a strongly held impression.
Discovery does not remove uncertainty. It records where uncertainty affects the design.
The system may need to create the missing evidence
Some requirements exist precisely because the business cannot currently answer the question reliably. In that case the useful output is not an invented baseline. It is a clear definition of what needs to become observable after implementation.
ProperBizFix provides business analysis and requirements discovery for implementation partners before solution design.