A fictional team automates the preparation of customer updates from a shared record. The demonstration works with clean sample information. In ordinary use, an incomplete record produces an incorrect draft and a repeated trigger creates a duplicate. The process became faster before its boundaries became clear.
This is a constructed teaching scenario. It does not describe a real client, a deployed integration or an observed failure. Its purpose is to make the control questions concrete.
The situation
The manual process includes an experienced colleague noticing missing details and asking for clarification. That judgement was not recorded in the automation brief. The new system treats every record as ready because a trigger has fired.
The project measures time saved on the normal path but does not count checking, correction or exception handling. It therefore has an incomplete view of the change.
What everybody thought the problem was
The initial complaint is that the software is unreliable. The software may contain defects, but the process definition also needs examination. The system was not told what ready means or what to do when the same request arrives twice.
Replacing the provider without clarifying those requirements could reproduce the same weakness through another interface.
What the investigation would examine
A review would inspect input requirements, validation, repeated requests, permissions and the point at which an external action becomes irreversible. It would separate preparation of a draft from authority to send it.
The team would also identify an accountable owner for exceptions. A failed request should leave useful context rather than a vague error that forces somebody to reconstruct the task.
What could be tested
A safer pilot could validate required fields, assign a stable request identifier and prepare drafts for review. Known exception records would be included in the test. The system would be deliberately tested with an unavailable provider and a repeated trigger.
Success would include correct output, no unintended duplicate action, preserved inputs and an understandable recovery route. Those are proposed test conditions, not results claimed by this scenario.
What might not work
A rule may reject legitimate unusual cases. A reviewer may approve too quickly. Maintenance may be neglected when the underlying record format changes. The controls need review as the process evolves.
The pattern
Automation inherits the quality of the task definition and data around it. Write the normal path, exception path and recovery owner before selecting the technology. Then test the difficult records as deliberately as the clean ones.
The person behind the thinking
Ayodeji Peter Falope
Business diagnosis, practical decisions and stronger operating systems for Nigerian and African SMEs.