The customer should not pay for our missing acknowledgement

A field officer presses submit, the connection disappears and the screen offers no clear answer. The officer wants to finish the task, the customer wants a receipt and the branch wants the day's records reconciled. Repeating the action seems sensible. Whether it is safe depends on what happened before the connection failed and how the application represents a retry. This is an ordinary design problem with an unusually direct human consequence. The customer cannot be expected to understand our message flow before knowing whether the payment record can be relied upon.

Preserve the action through the retry

The first distinction is between an action and a transmission about that action. An officer may have recorded one receipt while the device sends its details more than once. The network does not know whether those messages represent repeated attempts or separate transactions. The application must carry enough identity for the receiving service to make that distinction according to the agreed business rules. If a retry receives an entirely new reference and enters the posting process as a new event, a reasonable user response can produce an unreasonable result. Reliable connectivity would conceal the weakness rather than repair it.

Our review examined 18,420 field receipt records and found 1,146 repeated transmissions associated with connection interruptions. Those figures did not establish that borrowers had made duplicate payments. They established that the transmission behaviour needed examination. Finance and operations helped identify which records could be matched and which needed further evidence. The application team changed the retry path to retain the original receipt identity. This gave the receiving service a basis for recognising a repeated request without relying on a guess about the amount, customer name or approximate time. Similar-looking transactions are not necessarily the same transaction.

An identity also needs to survive the places where staff resume work. If the application retains a reference only until the screen closes, a restart may destroy the very distinction the design depends on. We tested interruptions at several points, including before central acceptance and after acceptance but before the acknowledgement reached the handset. The user's experience could look almost identical in those situations, while the next safe action differed. The test therefore had to examine both ends of the exchange and the durable record, rather than declare success because the device eventually displayed a connected symbol.

This does not mean technology should automatically resolve every ambiguous receipt. A reference can establish that two messages concern the same recorded action without proving the underlying cash event. That question may require the officer's record, customer evidence and finance review. I want engineers to understand the boundary because it prevents a technical solution from acquiring a wider claim than its evidence supports. Our task was to stop a retry from becoming a new posting request merely because acknowledgement was missing. The historical account position still needed the people and records capable of establishing it.

Give the officer a truthful next step

A pending state is useful only if the officer knows what to do with it. A vague failure message may encourage another collection, an improvised note or a call to someone who cannot see the relevant reference. We worked with operations on a message that explained the confirmation was pending and preserved the route for review. The device had to make the receipt identity available without suggesting that a central posting had already been confirmed. This is a communication problem as well as an engineering problem. The wording should describe the evidence available at that moment, not the outcome the project hopes will occur.

The borrower should not be asked to make another payment solely because our system has not acknowledged an upload. That would turn uncertainty inside our process into a demand on a person who cannot inspect it. Nor should staff give an unsupported assurance that every account entry is complete. Operations needed a way to explain the position and follow up through an accountable route. The exact customer treatment belongs with the relevant business and compliance functions. The CIO must make sure those functions can use the technology record to act responsibly, rather than inherit a screen that offers only success or failure.

There is also a workload consequence. A pending queue must have an owner, enough context and a practical review process. Otherwise, the design merely replaces an unsafe automatic action with an unmanageable list. We wanted staff to know which evidence was missing and who could obtain it. Reconciliation work could then proceed without every case returning to the developer who wrote the retry logic. A system is easier to operate when its exceptions are part of the service design, rather than an embarrassing residue the project expects someone else to absorb after launch.

The training should preserve the same distinctions. Demonstrating a normal successful upload is insufficient preparation for a field officer who will eventually encounter an interrupted one. We rehearsed what the officer would see, what could be said to the customer and which action should follow. This did not require staff to learn network protocols. It required them to recognise the application states relevant to their responsibility. A good explanation reduces the temptation to improvise while leaving room for the judgement and escalation that unusual circumstances require. The process should support the person trying to do the right thing under imperfect conditions.

Close the release and the account on their own evidence

At the review date, thirty-seven records still needed supporting evidence. The software change had passed its tests, and the project sponsor wanted a single closure statement. I kept the two conclusions separate. A tested retry path was evidence about future application behaviour within the tested conditions. It was not evidence that every earlier customer account had been reconciled. Finance and operations retained ownership of that work. A report could recognise the completed release without concealing the unresolved population. That distinction gave the committee a useful account of progress and the remaining obligation.

The same discipline applies to measures of success. Fewer repeated messages might follow from stronger connectivity, a different workload or a change in user behaviour. It does not by itself prove that the posting path handles repeated requests correctly. Conversely, repeated messages may remain normal in a system designed to retry safely. I would rather examine whether the original action is preserved and the account consequence is controlled than reward a low retry count whose meaning is unclear. The measure must correspond to the risk or service question management is trying to answer.

For directors, the enquiry is whether management can connect the field action, its technical record and the customer's account without confusing them. They need to understand the unresolved population and the decisions needed to resolve it. They do not need to prescribe an identifier format or a network library. A concise example can make the issue intelligible: the same receipt reaches the service twice after a lost acknowledgement, and the system must recognise what has repeated. The board can then ask whether the design, operating process and correction work have each been examined by the right people.

I regard the missing acknowledgement as a test of institutional responsibility. The customer did not design the message exchange and cannot repair it. We should preserve their evidence, give staff an accurate next step and resist claiming more completion than we can establish. That takes work across technology, operations and finance. It also produces a service that can tolerate an ordinary interruption without forcing the least informed participant to carry its consequences. A connection may disappear for a moment; the identity and accountability of the action should not disappear with it.