Before automating the report, ask what would break without it

Before automating a report, I want to know what would break if nobody wrote it.

That is not an argument against reports. Some carry evidence, preserve decisions or give another person information they cannot obtain elsewhere. In those cases, losing the report would lose something important.

But “we spend too long producing this document” leaves another possibility open: the document may be an expensive way of moving information between systems or people who already have most of it.

Automating its production can make that arrangement cheaper. It can also make the arrangement harder to question, because the new tool appears to have solved the problem.

The document and its purpose are different design choices

Consider three ways of helping an administrator decide whether a job is ready to invoice.

One produces a polished report from the technician’s notes. Another shows the completed work, the parts and the outstanding approval in one place. A third changes the collection process so the necessary information arrives together, with a clear exception when something is missing.

These are not three versions of the same feature. They make different assumptions about where the difficulty lies.

Consider a fictional ventilation installation. The work is finished, but the office still needs the customer’s approval and a photo to complete the billing record. A writing tool can improve the report. It cannot supply the missing photo or the customer’s approval.

The interesting design question is therefore not “Which model writes the best report?” It is “What does the next person need in order to make the decision?”

The report may still be the best answer. It should earn that position rather than inherit it from the existing workflow.

Making unnecessary work cheaper can preserve it

There is a tempting way to evaluate an automation: compare the time required to produce the old output with the time required to produce the new one.

That comparison answers a useful but limited question. It says nothing about whether the output is the right thing to produce.

Suppose a team can generate ten summaries in the time previously required for one. If another person must now inspect all ten to find the same missing fact, the extra production has not settled the underlying problem. This is an illustrative possibility, not a measured result from a client.

The opportunity may be to expose the missing fact directly, route the exception to someone who can resolve it, or remove an unnecessary approval step. Each option changes the work differently. None should be chosen merely because it produces the most impressive demonstration.

This is where technical exploration becomes more interesting than attaching a model to an existing form. The challenge is to discover which part of the current arrangement is necessary and which part exists because the old tools made it convenient.

Do not remove a document until you understand who depends on it

The opposite mistake would be to call every report bureaucracy and eliminate it.

A document can have readers who are absent from the initial discussion. It may explain a decision months later, support a handover or preserve an exception that a dashboard does not capture. The responsible team needs to confirm those dependencies and any record-keeping requirements before changing them.

GOV.UK’s user-research guidance makes a useful distinction here: understand what people are trying to accomplish, including those who provide or support the service, rather than treating a proposed solution as the need itself.

That is the part worth keeping. “Nobody in this meeting reads it” is not evidence that nobody needs it. Equally, “we have always produced it” is not evidence that its current format is necessary.

A prototype should help choose between designs

I would rather use a small prototype to compare two ways of completing the work than polish a single automation before its purpose is clear.

One version might generate the report. Another might give the next person a concise view of the facts and unresolved exceptions. The comparison should examine whether that person can make the right decision, what they still have to retrieve, and what information must remain available afterward.

If the report wins, there is a stronger reason to automate it. If the second design wins, the project has discovered a better target. If neither works, the failure tells us something about the missing information or authority—not simply about the model.

This is an argument for more useful technical ambition, not less. AI, integrations and custom interfaces can change how work moves through an organization. Limiting the project to “write the same thing faster” may leave that larger opportunity untouched.

My preferred starting point is the decision that needs to happen next. The document is one possible way to help it happen.

That also changes how time savings should be evaluated: not just how quickly an output appears, but what the completed work enables.