The Start Shift button vanished after one wrong tap
On release day 17 field staff ended their shift by accident and could not start another. The fix reached every phone without a new app release.
You ship a new version of the field app. By mid-morning the first complaint arrives: the Start Shift button is gone. The man who reported it had started his shift at 09:46, ended it at 10:59, and now could not start another. Until midnight, the app considered his working day over.
He had ended it himself, by accident. He was not alone. Seventeen people ended a shift before 11:47 that morning, against one and two on comparable days, and fourteen of those seventeen did it within ten minutes of starting. That is seventeen people in a field sales team at Aries Agro, a crop-nutrition manufacturer, unable to record their working day until the next morning.
What was actually going on
Two separate things combined.
The new app header used one button that changes in place: after you tap Start, the same spot on the screen becomes End. The old screen had two separate buttons, so a double tap landed on a disabled Start and did nothing. On the new header, the second tap of a double tap ended the shift.
Then a rule on the server made the accident permanent. The server rejected any second start on the same day, with the message that the day’s shift had ended. A harmless slip became a lockout.
We nearly got the size of it wrong. Partway through, one of our own queries converted the time zone twice and made shift starts look as if they had collapsed to 28 a day. The corrected figure was 541 starts before 11:45 against 609 and 640 on the two days before, which is normal. Only the early-end spike was real.
What we changed
The fix went to the server only, with no new app release, because the installed app decides what to show from the server’s answer. If the server returns the open shift, the app offers Start again. All 17 people could start again with no data repair.
While we were there we found that every part of the system that looked up today’s shift took the day’s earliest record. After a stop and restart that is a finished shift, so the code would have ended the wrong one and missed the live one. That was fixed too, along with a count of days present that had been counting shifts instead of days.
We tested start, end, start again, refused while running, end, and a third start, with real requests, on both the test and live systems.
What it did not fix
The single button still invites accidental ends. They are now recoverable, but each one still pollutes the average shift length. Separating the buttons, or ignoring a second tap that comes too quickly, waits for the next app release.
We also changed the database rule to allow at most one open shift per person per day, which is what actually stops double taps and repeated offline uploads. That change is on the test system only. The live database has 852 person-days with more than one open shift and needs tidying first, so the code was written not to depend on it.
The pattern, for anyone releasing an app to a field team
When a new screen changes what a button does, count how often people do something right after using it, on release day, and compare it with a normal day. A spike in early endings was the whole signal here.
Then ask what happens after a mistake. A rule that says a day can only be started once is reasonable until a phone makes it easy to end one by accident.
Where this ends up
Sazinga Field treats the server as the source of truth for whether a shift is open, which is why a fix could reach every phone without anyone updating the app.