Before you automate the Friday report, find out who reads it.

The thing everyone wants automated first

Ask a team what they'd automate if they could, and somebody will describe the Friday report. Someone exports a file from one system, pulls another from a second, pastes them together, fixes a few things by hand, and emails it around before lunch. It takes the morning. It's boring. Everyone agrees it should be automatic.

They're usually right that it shouldn't take a person's morning. They're often wrong about what the fix is. Before you automate a report, there's a more useful question than "how": who actually reads it, and what do they do because of it?

That sounds like a cheap shot. It isn't. Recurring reports tend to outlive the reason they were created. Someone asked for it two years ago during a bad quarter. The person who asked has changed jobs. The report keeps going out because nobody wants to be the one who stops it. Automating it perfectly just means it goes out faster to people who don't open it.

Ask three people what they do with it

Pick three people on the distribution list, ideally including the most senior one, and ask them directly. Not "do you find this useful?" because everyone says yes. Ask: "When you got last week's report, what did you do differently because of it?"

You'll get one of three kinds of answer.

"I use it to decide something." The warehouse lead uses it to plan staffing for the next week. Finance uses it to decide which accounts to chase. That report has a job.

"I look at it to see if anything's wrong." They scan for the one number that's off, and most weeks nothing is. The report is really a smoke alarm, read by hand.

"Honestly, I don't really look at it." More common than people admit, and nothing to be embarrassed about.

The answers often differ by person, which is useful too. It tells you the report is doing several jobs, badly, and might be better as two smaller things.

Automate it, turn it into an alert, or retire it

Once you know what the report is for, the right move is usually obvious.

If it drives a decision, automate it, carefully. Some reports carry real weight. On PatientIQ, part of our work was reporting and compliance capabilities that supported hospitals' CMS reimbursement requirements. A report like that isn't optional, and getting it right matters more than getting it fast. Most business reports aren't that serious, but the ones that drive a decision deserve the same care: clear definitions, trustworthy sources, and someone who owns them.

If it's really a smoke alarm, stop sending the report and send an alert instead. Decide which conditions people are scanning for, such as a backlog over a threshold, a customer account past due, or a number moving in the wrong direction, and notify the right person only when one happens. Nobody has to read a quiet week anymore. If people still want the full picture, keep a live view they can open when they choose.

If nobody acts on it, retire it. Send one last note: "We're stopping this report. If you rely on it, reply this week." If nobody replies, you've just automated it in the most efficient way possible.

The clean-up is the business logic

Say the report survives and you're going to automate it. Here's the trap: the morning someone spends cleaning the report is where your business rules are hiding.

Watch the person who makes it, start to finish, and write down every change they make by hand. You'll find things like: delete the test orders that start with a certain prefix. Merge the two customer records that are really the same company. Move anything from the old region code into the new one. Leave out the returns that haven't been inspected yet. Round this column, not that one.

Each of those is a rule your business actually runs on, and most of them are written down nowhere else. If you automate the export and skip the clean-up, the automated report will be wrong in ways that are hard to spot, and people will quietly go back to the manual version.

So write the rules out in plain words, check them with the person who makes the report and someone who reads it, and only then build. Some will turn out to be fixes for problems upstream, like a duplicate customer that should be merged at the source. Those are worth fixing at the source, once, rather than cleaning up every Friday forever. If a number in the report needs a precise definition, our note on defining the metric before you dashboard it goes into how.

Make a missing report loud

Manual reports have one accidental strength: when the person who makes them is out, everyone notices. Automated reports lose that. A scheduled job fails on a Thursday night, the email doesn't go out, and nobody notices until someone makes a decision from last week's numbers.

Build the failure in from the start. The automated report needs a named owner. If it fails, that owner hears about it, not the whole distribution list and not nobody. The report itself should say when its data was last updated, in plain sight at the top, so a reader can tell fresh from stale without asking. And if a source system is late or partial, the report should say so instead of quietly showing smaller numbers.

This is what separates automation that people trust from automation they double-check by hand, which is the worst of both.

Start with one report

Pick the report your team complains about most. Ask three readers what they do with it. Decide whether it's a decision, an alarm, or a habit. If it survives, write down the clean-up rules before anyone builds anything.

That's how our business process automation work tends to start: one recurring task and the person who knows how it really works. Sometimes the result is a reliable automated report. Sometimes it's an alert and a live view. Sometimes it's an email saying the report has stopped, and the morning goes back to someone who had better things to do with it. If you have a Friday report, show us how it gets made.