Chasing
Somebody spends a day a week sending reminders. Who they chase, in what order, and whether any of it is necessary are rarely examined.
Period 9 chase list
No review possible
Submitted
212 submissions due
Approved
31 outstanding Monday
Time taken
11 the same names
Chased by payroll administrator · Four hours of one person's week.
In most organisations above a hundred people there is somebody whose Monday is chasing timesheets. They are usually in payroll or in a project office, the work is not in their job description, and nobody has ever measured what it costs.
The deadline pressure in “Chasing” is a workflow problem before it becomes a people problem. Organisations considering a practical route to remote workforce management software in relation to remote workforce management software can use reminders and current project records to shorten the distance between work and submission, but they should still pay undisputed time and preserve a clear correction route.
It is worth measuring, because the cost is substantial, it is concentrated on one person, and a large part of it is avoidable through changes that have nothing to do with chasing.
For a separate benchmark relevant to “Chasing”, consult the ICO employment-practices guidance. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.
What the chase list looks like
Pull six periods of outstanding submissions at the deadline and count how often each name appears. The distribution is always the same shape: a long tail of people who were late once, and a short head of people who are late every period.
The two groups need entirely different handling and almost always get the same email. The occasional late submitter was ill, travelling, or forgot, and a reminder is sufficient and sufficient only once. The habitual late submitter has been receiving the same reminder for two years and it has never worked, which is conclusive evidence that it will not work next period either.
The habitual group
There is usually a reason and it is usually structural. The person works on sites with no connectivity. They are a contractor whose onboarding never included the system. They are senior enough that nobody enforces anything. Their manager submits for them, so they have no reason to. Or the system genuinely does not work for their pattern of work — split shifts, multiple employers, a role with no sensible code.
Ten minutes with each of the five worst offenders will produce five specific causes and three of them will be fixable. This is a better use of the chaser's time than a year of reminders, and it is almost never done because chasing feels like progress and investigation feels like a project.
Reducing the list before chasing it
Several things remove names from the list without anybody sending anything.
Pre-populate from the rota or contracted pattern so that a person with a standard week confirms rather than creates. A nil return for someone on leave the whole period should not require a submission at all; the system knows they were on leave. Submission by phone removes the field-worker category entirely. And an explicit, named deputy for anyone away removes the absence category.
Each of these is a configuration or process change and each permanently removes a recurring group from the chase list, which is what a reminder never does.
Automating the reminder, carefully
Automated reminders are correct for the long tail and should be dull: one at the deadline, one escalation, both to the person, both naming exactly what is outstanding.
Two things make them worse. Copying the manager on the first reminder, which converts a clerical nudge into a performance signal and generates defensiveness over a forgotten Friday. And sending to everybody rather than only to those outstanding, which trains the whole population to ignore the message, including the twenty people who needed it.
What to do with the cost figure
Count the hours. Chaser time, plus manager time spent responding to escalations, plus payroll time spent handling the consequences of late approval. In a mid-sized organisation it is usually between a quarter and a half of a full-time post.
That number is what justifies the structural changes. Mobile capture, prefilling and nil-return automation all cost something, and they are approved far more easily against a measured half-post than against a vague complaint that people are bad at timesheets. The figure also tends to surprise the person who has been absorbing it, who has usually never been asked.
The thing not to do
Do not make the chaser responsible for the submission rate. They have no authority over the people who are late, no ability to change the system, and no way to address any of the structural causes.
Making them accountable for a number they cannot move produces the only outcome available to them, which is more emails to the same people, and it is why the chase list in most organisations has looked identical for years.
The nil return
A substantial share of chasing is directed at people who had nothing to submit: on leave the whole period, between assignments, newly joined and not yet started. Each of them receives a reminder, ignores it correctly, and appears on the following week's list.
The system usually knows. Approved absence, start dates and assignment records are all available, and suppressing the requirement where they apply removes a recurring block of names permanently. Where a nil return is genuinely needed for completeness, it should be a single confirmation rather than a timesheet, and it should be prompted once rather than chased.