Field notes › Running the business
Client reporting that doesn't eat your week
What clients actually want to know
Strip the formatting away and most client reporting in labour hire answers three questions. Who is rostered on my site this week. Are they cleared to be there. And what happened to the extra crew I asked for on Tuesday.
The client does not want a document. They want certainty, and the document is just the way you have been delivering it. That distinction matters, because once you see it, you can stop optimising the document and start delivering the certainty some other way.
The Friday report treadmill
The usual routine looks like this. Someone in the office pulls names out of the roster spreadsheet, cross-checks tickets and inductions against another spreadsheet, pastes the lot into a template, tidies it up and emails it off. Then does it again for the next client. Every week, forever.
Two problems with this, and the hours are only the first one. The second is that the report is stale before the client opens it. A worker calls in sick on Sunday night, the swap gets sorted by phone, and the document from Friday is now wrong. So the client rings to check anyway, and you end up doing the reporting twice: once in writing and once out loud.
Stale reporting is worse than no reporting, because the client learns not to trust the document. Once that happens every report generates a follow-up call, and you are paying the cost of both channels.
Give them the live answer instead
The better model is to stop producing snapshots and give each client a window into the live roster. In Mustr, every client site gets its own login. They see their roster and only their roster, current as of right now, day shift and night shift. No other client's crew, no other site's numbers, nothing to redact before sending.
When the roster changes, there is nothing to regenerate or resend. The portal already shows it. The Sunday night swap is visible Monday morning without anyone writing an email about it. The weekly compilation job does not get faster, it stops existing. There is more detail on what clients can see and do at client portal.
Requests in writing, not from memory
Reporting is only half the traffic between you and a client. The other half runs the opposite way: they want two more crew for Thursday, or they want to know whether flights are booked for the incoming swing. When that arrives by phone, it lives in someone's memory until it reaches the roster, and memory is where requests go missing.
Through the portal, clients raise shift requests themselves and tick off flights and accommodation against the shift. The request, the response and the status all sit in one place with a record behind them. If there is ever a dispute about who asked for what and when, the audit trail settles it without anyone digging through a phone log.
What you still talk about
None of this ends the conversation with your client. It changes what the conversation is about. When the routine questions answer themselves, your calls can cover the things a portal cannot: whether the crew mix suits the next phase of work, where the client is short, where you could pick up scope. That is the conversation that grows the account, and it is the one that never happens while you are reading names off a spreadsheet down the phone.
If reporting is costing you a day a week, see it on your own roster and work out what you would do with that day instead.