Reconcile Conflicting Impact Evidence

Business impact analysis rarely receives one agreed set of inputs. A service manager describes feared harm, technology shows past repair averages, procurement quotes a supplier brochure, and customer records tell a different story. Putting those numbers into one table does not make them equally valid. Start a conflict ledger that classifies each statement as measured observation, documented obligation, expert estimate, planning assumption or managerial tolerance decision. Add its time period, unit, included population and source limit. A technical repair average is not the recovery time for valid service output. A marketing promise is not an enforceable service term. A loud complaint does not prove that all customers suffered equally. Equally, an owner's warning should not be dismissed merely because last year's records contain no similar incident; the customer mix or commitments may have changed.

Use three reconciliation questions. First, are sources describing the same output? A team reporting the portal returned in two hours may mean that the screen loaded. Another reporting six hours may be waiting for valid confirmations and record reconciliation. Second, do denominator and period match? Complaints as a share of all calls cannot be compared directly with delayed bookings as a share of daily bookings. Third, are sources still current? An old supplier contract or a trial before a system migration does not demonstrate today's capability. Where possible, recast evidence against the same output and population. Where this is impossible, preserve the discrepancy and show how it affects the decision. 'Between two and six hours depending on the recovery definition' is more informative than averaging to four hours without a known measure.

Test a competing explanation before setting priority. More calls after an outage may reflect more affected customers, or repeated attempts by the same people when no status update arrives. Distinguishing the two requires a request identifier, not unnecessary new personal data, and counts of unique affected requests and repeat contacts. If 80 requests are delayed and 120 calls concern them, do not report 120 harmed customers. When technical recovery succeeds but manual records are not reconciled, do not attribute the entire service delay to the supplier. Draw a timeline: output stops, incident is detected, activation is decided, fallback becomes available, first valid output appears and backlog clears. Different evidence and owners attach to each interval. This shows where an improvement would actually help and where one total time conceals the bottleneck.

The analysis ends in a conditional decision rather than waiting for perfect certainty. State what can be approved now, what a material conflict prevents, who may accept temporary risk and when the decision will be reconsidered. For example, prioritize confirmation of sensitive appointments because an internal rule requires it by day's end, while withholding approval of a fallback capacity until a register trial proves it. Weak supplier evidence must not be silently converted into assumed capability. At the same time, protective steps for beneficiaries need not all wait for a supplier reply. The response lead can propose intake without a confirmation promise, a truthful customer message and a review time to the service owner. Such a bounded service can operate without misrepresentation. State the impact if the worst plausible case is true and a trigger to revise the decision if observation shows the estimated harm was overstated.

Approval documentation carries knowledge rather than merely providing a signature. Record the authorized role, options considered, dated figures, unanswered questions, rejected alternative and evidence that would change the choice. Do not request blanket approval of a table with empty cells; mark unverified data and the temporary nature of the decision explicitly. If the approver's authority is limited, escalate to the properly mandated role rather than treating silence as consent. After an exercise, compare predicted with observed impact: did the consequence emerge at the threshold, did the fallback produce a valid output, and was supplier evidence available? The gap supports a specific improvement and may reorder investment priorities in the next module. A file hash identifies the version reviewed; it does not prove the human judgment was sound.

Rank evidence requests by their power to change the decision, not by how easy they are to collect. A document showing that the forty-five marked requests carry a different deadline could reverse priority quickly; another general interview saying the service matters would not resolve the conflict. Give every evidence request a testable question, owner and due time before the impact threshold. If the evidence deadline passes, take the predeclared conservative action and test it against valid service output, not call volume alone. In the review record separate measurement error from a genuine difference in impact tolerance. Both teams can have correct data while measuring different customer groups or different definitions of restoration. Preserve those outputs separately instead of forcing one number. If the tagging register is incomplete, repair the source and dependent decisions rather than only fixing a manually compiled table. Make exceptions countable so that a small group does not become an untestable excuse.