HuskiesSunday night. Somewhere right now, in a lot of technical companies, someone is putting together the weekly report for the client by hand.
The questions are always the same:
- How many jobs were completed this week?
- How many were rejected, and why?
- What's ready to invoice?
- What has been sitting too long?
The answers exist. They're just scattered: statuses in the spreadsheet, photos in the chat, quantities in a notebook, the reason for a rejection in someone's memory.
The report takes three hours because the person writing it is really collecting the data.
The report is the last step, not the work
A report is a view over data that already exists. If it has to be assembled by hand, the problem isn't the report. It's that the data was never recorded in one place, at the moment it happened.
So the change starts in the field, not in the office:
- The technician changes the job's status on their phone when the work is done. Not at the end of the day, not by phone call.
- Photos and quantities go on the job itself, with a name and a time.
- A rejection has a required reason field, so it can be counted.
- Costing is calculated from the quantities. It isn't typed in later.
Once those four things are true, the weekly report is just a saved query that runs on a schedule.
What it looks like in production
One of our clients, a telecoms infrastructure company, used to write the weekly KPI report for their main contractor by hand, every Sunday night, from four different tools.
Today the report goes out by itself every Thursday at 09:00. Completed, rejected, ready to invoice. Nobody opens a spreadsheet for it.
They got Sunday night back as a side effect.