Case study 13
The app said synced. The records said otherwise.
A new mobile timekeeping app told people their clock-outs had synced while the records piled up with no end time. Counting the gap every day turned scattered complaints into a reported pattern, roughly two thirds of a full outreach batch were fixed the same day, and the supervisor gets a named list of non-responders before every pay run.
The app showed a success message at clock-out. In the back office, entries with a start time and no end time arrived by the dozen each day. The first response was the obvious one: treat each missing clock-out as one person's mistake and chase it with one email. That handled the row and hid the pattern.
Count the record, not the status light. I counted exceptions every day by entry date and kept a list of names that came back more than once. The same people kept reappearing after doing exactly what the app told them to do. That is not a training problem. It went to the supervisor as a pattern, with names and dates attached, together with placeholder entries that appeared after corrections.
Diff before sending anything. Each morning's list was compared with the last saved copy, so new, carried and cleared rows were separated before anyone was contacted. Test records and anything outside the current period came off first.
Click any image to see it full size. Every file here is rebuilt with invented data.
One person, one message. Outreach went out as a batch: one message per person covering every open date, in the order the queue showed them, with addresses filled in. A first contact template introduced me and asked for the missing time. A repeat template skipped the introduction. Which one a person got came from a running contacted list, checked before every batch.
A confirmation with nothing to fill in. When a reply came in, the time was entered and the same two lines went back: the adjustment has been entered, the error has cleared, no further action needed. No dates, so nothing to get wrong.
Never today. Nothing dated today is ever contacted. An entry from today may still be in progress, and its clock-out is not missing yet.
Named, not counted. Before every pay run the non-responder list is rebuilt name by name from the latest queue and written as each name with its open dates, for the supervisor to call. It is never worked out by subtracting today's fixes from yesterday's total.
Daily Queue Snapshot, Summary tab: Exceptions, Oct 1 to Oct 2
| Diff status | Rows |
|---|---|
| Prior snapshot, Oct 1 | 13 |
| Today, Oct 2 | 12 |
| New | 3 |
| Carried | 7 |
| Updated | 2 |
| Resolved | 4 |
| Reconciles | OK |
Daily Queue Snapshot, Summary tab: waiting on person, by name
| Person | Row IDs | Open dates |
|---|---|---|
| Avery Cole | EX-4559, EX-4642 | Sep 28, Sep 30 |
| Jordan Pike | EX-4562 | Sep 27 |
| Reese Calder | EX-4895 | Sep 10 |
| 3 people | 4 rows |
The results, in bands. Roughly two thirds of a full batch replied and were fixed the same day. Repeat introductions stopped once the contacted list existed. App capture failures reached the supervisor as a named pattern instead of one-off complaints, and every pay run started with names, not a number.
- At first each missing clock-out was chased as one person's error, one email at a time. The pattern only showed once the count was kept by date with repeat names tracked.
- People already contacted got a first contact introduction again. The contacted list started then and is checked before every batch.
- A message went out about an entry that was still in progress. That is where the never-today rule came from.
- Confirmations were rewritten per person with dates and times, and one draft dated an entry wrongly. Confirmations went generic.
Download the Daily Queue Snapshot (xlsx)Live demo: the email template libraryThe Exception Email BuilderThe Queue Diff toolThe Diff playbook (PDF)Your automation is working. It just isn't doing anything.Live demos of the working filesPart of the work in case study 06