Client and Customer-Facing Communication Questions

Direct answer

Lead with a calm, specific, bounded statement: what you checked, what you found (8% of records fail validation), what is and is not yet known about billing, what you are doing today, and when they will hear next. Panic comes from vagueness and surprise, not from bad news, so the cure is precision, a ranked plan and a date. Present billing-affecting failures first, because that is the part the client cares about.

Step 1: size the problem before the call

8% sounds large and says little. Break it down. Illustrative example: the audit covered 2,000,000 records, and 8% fail, which is 160,000 records (0.08 x 2,000,000 = 160,000). (Billing exposure here means the most money that could be wrongly billed; an invoice run is the scheduled batch job that generates and sends invoices.) Sort the failures by what they touch:

Check: 22,000 + 58,000 + 80,000 = 160,000. The headline becomes: "8% failed validation, but about 1.1% touch the amounts that drive billing" Here "touches billing" means the failing field feeds an invoice amount, and the 1.1% is category A only. Say how you know this (the validation rules, run on a given date) and how sure you are.

Step 2: prioritize by billing risk, reversibility and the next deadline

Fix in this order: A before B before C. Within A, put records on the next invoice run first. A wrong invoice that has already gone out is harder to undo than one still in draft, so the date of the next billing run drives urgency. Also estimate exposure honestly: if the average error on a Category A record is $4 (illustrative), the maximum exposure is $22,000 x $4 = $88,000, stated as a range with its assumption, not as a loss.

Step 3: propose the remediation timeline

The spans are reasoned, not arbitrary: Day 2 is two working days to trace 80,000 records' worth of rule failures back to a few causes; Day 5 gives time to correct 22,000 records, re-validate and get the client's approval of staged values; Day 10 allows a second batch of 58,000 simpler code fixes. Replace them with your own team's measured speed, and say they are estimates.

What I would say on the call

"We ran our routine data audit and found that 8% of records fail validation. I want to give you the picture straight away. About 1.1% of records touch amounts that affect billing, and I'll hold those out of the next invoice run until they are corrected, so no invoice is generated from a bad amount or rate. The rest are tax code and formatting issues we can fix on a normal timeline, and I'll check the tax code records against the invoice run and flag any that would produce a wrong or failed invoice. I'll send you the list and the plan today, and you'll hear from me again on Wednesday with the cause."

Avoid words like "corrupted", "failure" and "breach" when they do not apply, and avoid blame. Say "fail validation", which is accurate.

Trade-offs and pitfalls

• Do not wait for the full root cause before telling them. Disclose what you know with its confidence, and promise the rest by a date.
• Do not bury the billing risk. If you soften it, the client discovers it later and trust collapses.
• Do not promise a fix date you cannot verify. Offer a date for the cause and a range for the fix.
• If the next invoice run is tomorrow, the whole plan compresses: hold the run for category A, and brief the client's finance contact first.

Direct answer

Treat the complaint as a reconciliation problem: agree on one concrete number that differs, make both calculations explicit, and walk from their figure to ours step by step until the gap is fully explained. Keep the client informed on a committed schedule, including days when there is no finding. Most gaps turn out to be a mix of definition differences and timing, with occasionally a real defect, and the investigation should separate those.

Step 1: agree on one concrete case (day 1)

Acknowledge within one business day and ask for: the report name, one specific metric, one date range, the number they have, and their method (usually a spreadsheet). Restate it back in writing: "We are comparing total orders for 1 to 7 October: your manual report shows 1,204, the dashboard shows 1,150." Narrowing to one metric and period turns a vague distrust into a testable question.

Step 2: write down both definitions

Ask side by side: what counts as an order (cancelled? test? refunded?), which date is used (placed, shipped, paid), which time zone, whether duplicates are removed, and how late-arriving data is handled. Then collect their source file and our query logic.

Step 3: reconcile with a bridge

Check: 31 + 15 + 8 = 54, and 1,204 - 54 = 1,150. The numbers are illustrative; the shape is real. Classify each cause as: definition difference (agree which is right), timing, our defect (fix it), or their manual error (explain gently, with evidence).

Step 4: keep them informed

• Day 1: acknowledgement and restated scope.
• Every 2 business days: a short update with what we ruled out, what we are testing and the next update date, even if the update is "nothing new".
• A shared document with the bridge so they can follow along and challenge it.
• On resolution: a one-page summary with cause, fix, and what changes.

Step 5: stop it recurring

Document metric definitions on the dashboard itself, add a tie-out check (an automated comparison against a trusted source), and set an alert when the difference exceeds a threshold. If they want their definition used instead of ours, change the dashboard and say so.

Pitfalls

Do not defend the dashboard before looking. Do not tell them their spreadsheet is wrong without a bridge that shows how. Do not go silent while you investigate, which does more damage than the discrepancy.