A customer has been barred for non-payment and it turns out they paid three weeks ago. Walk me through how that happens and what you fix.

Get the service back before you understand it

The customer is disconnected and paid up, so the first move is restoration, and the reason to say that out loud in an interview is that restoration is not a status change. Barring was carried out in the network: a provisioning request went to the subscriber data store and to whatever enforces the restriction, and lifting it means another request going the other way. That request can fail, can partially succeed so that voice returns and data does not, and can leave the device needing to reattach before the customer sees anything. So the fix is an order to be tracked to completion and confirmed against the network, not a flag to be flipped in the billing system with an apology.

Two things follow immediately. Somebody has to tell the customer, because a bar that quietly lifts twenty minutes later still cost them a morning. And the account has to be marked so the same dunning cycle does not re-bar them tonight, which it will if the underlying condition is untouched and the nightly job runs again.

The money arrived and was never allocated

The overwhelmingly likely cause is not a lost payment. It is a payment that landed as cash on the account, or in a suspense account, and was never allocated against the invoice that the collections process was watching.

This happens in a small number of well-known ways. The payment carried a wrong or missing reference, so the incoming file could not be matched to an account or to a document and went to unallocated cash. It was allocated to the wrong account, often a sister account for the same customer, which is common with business customers holding several. It was allocated to the account but against a different invoice, typically the newest one, leaving the old document open. It was a part payment that cleared most of the balance and left a small residue on an ageing invoice, and the ageing rule does not care about the amount. Or it was collected by direct debit, marked as settled optimistically, later returned unpaid, and then re-presented and collected, leaving the document's history inconsistent.

The distinction that matters underneath all of these is between the account balance and the state of individual documents. Collections chains are almost always driven by document ageing, because that is what a debt looks like legally and what a demand letter has to reference. A customer can therefore have a zero or credit balance overall and still hold a sixty-day-old unpaid invoice, and the process will pursue that invoice into a bar. Any system whose collections logic reads the balance instead would have avoided this case and would instead have failed to chase real debt, so the answer is not to swap one for the other but to make the allocation correct and to add a guard.

That guard is worth naming precisely: before any irreversible step, revalidate. A bar is the one action in the chain that a customer notices immediately and that cannot be undone quietly, so it should be preceded by a fresh check that the specific document is still unpaid, that no payment has arrived on the account since the notice was issued, and that no unallocated cash is sitting there large enough to cover it. Unallocated cash on an account about to be barred is a stop condition, not a footnote.

Dunning is a state machine, and the states are commercial

Describing the chain as a set of scheduled jobs is what makes these failures possible. Model it as a per-document, per-account state machine and the awkward cases become expressible rather than accidental.

The path runs from invoice issued, through overdue, reminder, final notice, restriction of outbound service, full bar, and eventually to referral or write-off, with dates and notice periods between the steps. What separates a real design from a diagram is the set of transitions that are not the happy path. A dispute lodged against a specific charge should suspend the chain for the disputed amount and only that amount, so a customer arguing about one roaming charge is not pursued for the whole bill. An agreed payment arrangement suspends the chain while it is honoured and resumes it precisely where it left off when it is not. A payment received part way through returns the document to current and cancels any pending notice, including one already queued to print. And a credit note issued after a notice has gone out has to unwind the notice as well as the balance.

Alongside those transitions sit the suppression rules, which exist because the consequences of barring some customers are not commercial at all. Accounts carrying a fixed line used for emergency calls, customers flagged as vulnerable, accounts under a complaint being handled by a regulator or ombudsman, business accounts inside a contractual escalation, and anything where a regulator requires a specific notice period before disconnection all belong in a list that the automated chain will not touch without a human. Most jurisdictions constrain how and when a provider may cut off a customer, and the safe design assumption is that the bar step needs an exclusion list rather than that the rules will be remembered by whoever wrote the query.

The blast radius question nobody asks first

Finishing at this customer is the mark of an adequate answer rather than a strong one. A wrong bar is a systematic failure with a population, and the immediate task is to find the rest of that population before they telephone.

The queries are not difficult once you know to ask: accounts barred in the last cycle that have unallocated cash, accounts barred while holding a credit balance, accounts barred while a dispute was open, payment files whose match rate fell below its normal level, and the size of the suspense account over time. That last one is the honest health indicator for this whole area, because unallocated cash is money the business has received and cannot attribute, and it grows quietly. A revenue-assurance function that reconciles payments received against payments allocated, daily, catches this class of fault long before collections turns it into a disconnection.

The two counts to publish from every collections run are how many accounts entered each state and how many were held back by a suppression rule. A run that bars an unusual number of accounts, or that suddenly stops holding any back, has changed behaviour, and finding that out from a report beats finding it out from a customer.

Why this is a trust failure rather than a billing error

The reason interviewers like this scenario is that the technical fault is mundane and the consequence is not. The customer did what was asked, was penalised for it, and had their service removed in a way they had to notice. Repairing the allocation does not repair that, which is why the answer has to include the customer-facing part: a proactive contact rather than waiting for the complaint, a credit for the period without service, a check on whether a late-payment charge or a reconnection fee was applied and should be reversed, and a record of the case so that a pattern of them becomes visible to someone senior enough to act.

Collections chases documents, not balances. Before the one irreversible step in the chain, re-read the document's state and the unallocated cash on the account, because the cost of a wrong bar is not the amount in dispute.