Before You Automate a Report, Ask Who Still Uses It

A colleague and I each spent several hours every week putting together a report on how our programs were using their hours. It was part of our workforce-management work, and leadership had asked for it. So we kept sending it.

Eventually, we went back to the people who had requested it and the people who were supposed to use it. We wanted to understand whether it was still helping them.

Several had forgotten they were even receiving it.

Their inboxes were full. They had more information coming in than they had time to read, and this report had become one more email. From those conversations, we learned it hadn't been used for roughly a month to a month and a half. That wasn't a conclusion we pulled from email tracking. We asked the people involved.

We were still doing the work every week. The need for it had changed, and nobody had told us.

We didn't need a faster way to send it

It's easy to look at several hours of repetitive reporting and start thinking about automation. Pull the data together, clean up the spreadsheet, build the email, and get it out faster.

But making this particular report faster wouldn't have answered the more important question: did it still need to go out every week?

After checking with leadership and the intended users, we moved away from weekly production and toward providing it as needed. We weren't deciding on our own that their request didn't matter. We were asking whether the work still served the purpose they had asked for.

There's a difference.

Sometimes a report exists because someone needed to understand a problem three months ago. The problem gets addressed, their attention moves somewhere else, and the recurring task stays with the team producing it.

Nobody has to make a bad decision for that to happen. The report just never gets a follow-up conversation.

The time went back into scheduling and forecasting

We had plenty of other work that needed attention.

Instead of spending those hours sending something people weren't reading, we had more room to look at areas that were tightly staffed and propose schedule adjustments. We could spend time on our own forecasting questions: where did we need people, what gaps were showing up, and what were the trends telling us over time?

The benefit wasn't exactly the same every week. Sometimes it was more time to review a schedule. Sometimes it was additional analysis. As we improved and automated pieces of our own work, we could keep building and strengthening the processes around scheduling and forecasting.

I don't have a clean percentage to attach to that improvement. What I can tell you is that we moved time away from a recurring output people no longer needed and toward work we could actually use.

That was worth having the conversation.

Start with the person who needs the result

This experience is part of why I ask about use before talking about tools.

If you're responsible for a recurring report, find out who requested it, who uses it now, and what they do differently because they receive it. Those may not all be the same person.

If someone still needs it, great. You have a better starting point for improving it. Maybe the useful part is one exception buried in six tabs. Maybe they need a filtered view they can act on instead of the whole file. Maybe the timing needs to change.

If nobody can explain how they're using it, that's a reason to clarify the request with them. It isn't permission to quietly stop sending it.

Before you spend time automating a report, have that conversation. You might find a useful process worth improving. You might find work that's already served its purpose.

Both are useful things to learn.