Attendance that never quietly becomes absent
Attendance is not just a record of who came to work. It is the input to somebody’s pay, and it is wrong more often than anyone admits.
Overview
A manufacturing workforce system: thousands of employees across multiple plants, hundreds of supervisors, run on Excel.
Ten modules, built from requirements rather than redesigned from an existing interface. Employee, shift, holiday and calendar masters; individual and supervisor attendance; bulk workforce operations; loan requests and approvals.
The thing that makes shop-floor workforce management different from office HR is what an attendance record is attached to. Not just a person and a date — a site, a machine, and a work order. Hours do not only decide what someone is paid. They decide which job the cost lands against.
- Domain
- Manufacturing workforce operations
- Scale
- Thousands of employees · hundreds of supervisors · multiple plants
- Modules
- Employee, shift, holiday and calendar masters · individual and supervisor attendance · bulk operations · loan request and approval
- Role
- Workflow, inter-module planning, information architecture, screens
- Scope boundary
- Payroll inputs, not payroll calculation. An existing payroll engine stayed as it was.
- Year
- 2026
- Shipped
- Yes, and in use. Nothing was instrumented, so this study describes what the system does and claims no percentages.
Fig 0Where an hour travels
Employee
Starts the day, breaks, ends it.
Attendance
A record: person, date, site, machine, work order.
Supervisor review
End break, mark error, force day end.
HR corrections
Bulk fill, holiday apply, shift reassignment.
- Existing, unchanged — scope boundary
Payroll engine
Salary
Every screen in this study sits somewhere on this line, and everything on it flows one way.
Project
Workforce and payroll operations
Ten modules for a manufacturing workforce running on spreadsheets across multiple plants.
Role
Workflow and information architecture
Inter-module planning and screens, built from requirements rather than redesigned from an existing interface.
Outcome
Spreadsheets → validated payroll input
Attendance, leave, shifts, holidays and approved loans became validated inputs into an existing payroll engine.
The problem
Excel.
Thousands of employees, hundreds of supervisors, several plants — and the payroll every month depended on spreadsheets being correct.
Attendance in a spreadsheet has one property that matters more than any other: it has no idea what it does not know. A blank cell and a genuine absence look identical. A shift that ends at 6 AM the next morning is whatever the person typing decided it was. A correction and an original are the same cell, one overwritten by the other, with no trace that anything changed.
None of that is visible until payroll is wrong, and by then the argument is about a number rather than about a record.
Scope: inputs, not calculation
The project covered the operational workflows that generate payroll inputs rather than payroll calculation itself. Attendance, leave, shifts, holidays and approved loans became validated inputs into an existing payroll engine rather than replacing how payroll was calculated.
That boundary is worth stating plainly, because it decides what every screen is for. Nothing here computes a salary. Everything here decides what the thing that computes salaries is allowed to be given.
Fig 1Where attendance sits
Attendance is nested under Payroll in the navigation rather than beside it. That is a claim: attendance is not record-keeping, it is payroll input.
Shipped
- Payroll
- Attendance
- Salary processing
Nested. Attendance is something payroll consumes.
Not this
- Payroll
- Attendance
One level up, beside it. That reads as record-keeping with a life of its own.
Who used it
Four surfaces, and they are genuinely different jobs.
- 01
- EmployeesRun their own day — start it, break, end it. They see their assignment and their own timeline. They approve nothing.
- 02
- SupervisorsWatch a shift in progress and intervene when a session goes wrong. They can end a break, flag a record as wrong, or close somebody’s day.
- 03
- HR and operationsHold the masters — shifts, holidays, attendance types, calendars — and run bulk corrections across a month.
- 04
- ApproversClear loan requests, which is the one place in the system where a decision becomes a recurring deduction from someone’s salary.
An HRMS has a property most enterprise software does not: many of its users are also its subjects. A supervisor’s action is a decision about another person’s pay. That shapes what the interface is allowed to do quietly.
What a shift actually is
The shift master looked like reference data and turned out to be the policy layer.
A shift carries a start and end time, and then: grace in, grace out, late mark after, early out before, minimum working hours, maximum working hours, break deduction, allow overnight, and a week off.
Every one of those is a rule about when a person is considered to have shown up. None of them is a fact. Late Mark After 15 min is a decision somebody made, and it is the difference between a full day and a half day for a person who arrived at 09:16.
Two numbers sit next to each other in the shift detail: Total Span 10h 00m and Total Working 8h 00m. Elapsed time and paid time, never collapsed into one figure. That pair is the whole problem of shift attendance stated in two fields.
Two of the eight shifts cross midnight. A night shift running 22:00 to 06:00 is one shift and two calendar days, and the interface draws it that way — the timeline preview renders the bar crossing the axis rather than describing the situation in text.
Decisions
Two that were mine, and what each cost.
Two bulk-fill behaviours instead of one
Approvers review loan requests in batches. Requests arrive incomplete — missing an EMI start date, missing a recovery pay head — and the approver has to complete them before anything can be approved.
The obvious design is one panel of fields and one apply button. It is also ambiguous, and the ambiguity is invisible until someone loses data: does apply mean fill what is blank, or set this value on everything I have selected?
Those are different jobs. Setting a common EMI start date across a batch is the second. Completing eight half-finished requests without touching the values people already entered is the first. A product that ships one button has silently picked one and left the other user to find out.
I shipped both, named apart, in the same panel.
Cost
Two buttons where every competitor has one. An approver cannot clear a batch in a single click, and has to understand a distinction before acting. That is real friction on a screen whose entire purpose is speed.
Why that was the right trade
The failure modes are not symmetrical. The cost of the wrong choice in one direction is an extra pass over three requests. In the other it is silently overwriting a figure an employee entered about a loan against their own salary. Ambiguity is cheap to design and expensive to recover from.
Grouping attendance failures by cause, not by person
A month of attendance across a plant produces a lot of records the system cannot resolve. Not disputes — gaps. A punch that never arrived.
The natural grouping is by employee, because employees are what the rest of the system is organised around. It is also the wrong one.
The exception panel buckets flagged entries by cause: missing check-in, missing check-out, missing timeline, missing end day. Each bucket carries its own counts — entries and employees, separately, because they differ.
Cost
An employee’s problems are scattered across four buckets. Anyone who wants to see one person’s whole bad month has to go somewhere else for it, and that view had to be built separately rather than falling out of this one.
Why that was the right trade
Thirty-two missing check-outs is one decision applied thirty-two times. One employee’s mixed handful of four different problems is four decisions. The work is shaped by the cause, so the interface is shaped by the cause.
Fig 4Issue buckets
Grouped by cause, with entry counts and employee counts kept apart.
| Cause | Entries | Employees | Decisions |
|---|---|---|---|
| Missing check-out | 32 | 9 | 1 |
| Missing check-in | 18 | 14 | 1 |
| Missing end day | 11 | 6 | 1 |
| Missing timeline | 7 | 7 | 1 |
| Same month, grouped by employee instead | 68 | 31 | 31 |
Bulk actions that show what they cost
Bulk editing is where workforce tools do the most damage, because the action is one click and the consequence is hundreds of records.
Three things follow from that, and all three are in the screens.
The change is previewed as a diff, per record. Applying a holiday across a date range opens a preview showing Current → New for every affected entry — P → H — with a summary above it: attendance type, date range, total changes, affected employees. One hundred and thirty-five records across fourteen pages, searchable. It is not summarised into “135 records will be updated”, because that sentence is easy to approve and impossible to check.
Fig 5Preview before apply
Per-record diff, not a summary.
| Employee | Date | Current | New |
|---|---|---|---|
| Holiday · 12–14 Aug | 135 changes | 47 employees | 14 pages |
| A. Kulkarni | 12 Aug | P | H |
| R. Bhosale | 12 Aug | P | H |
| S. Naik | 13 Aug | P | H |
| M. Pawar | 13 Aug | A | H |
| … 131 more, searchable |
Application is staged and the stages are visible. Reassigning shifts for a crew runs as a job with four named phases, each with its own counter: validating employees, checking current shift assignments, applying changes, updating records. The second phase exists because a reassignment is a change to something that already exists, not a fresh write.
Nothing is destroyed silently. Shift masters carry created-by, created-on, updated-by and updated-on. The supervisor console links to an audit log from the live session summary.
The supervisor problem
A supervisor watching a shift is looking at a live board: ninety-five employees, eighty-four working, six on break, three not started, and a count of sessions with problems. Each row shows the machine or line the person is on.
When a session goes wrong — a break running an hour and twenty-two minutes against a shift that allows fifteen — the supervisor gets three actions, and choosing between them is the design.
- 01
- End breakThe supervisor knows the person came back and the punch failed. Correct the record.
- 02
- Mark errorThe supervisor does not know what happened. Flag the record as wrong and leave it for someone who can find out.
- 03
- Force day endClose the person’s working day.
Mark error is the one that matters. Without it, a supervisor facing a record they cannot explain has exactly two options: edit it to something plausible, or ignore it. Both produce a clean-looking attendance sheet that is quietly wrong. A flag is worse-looking and better — it says the system does not know, in a place where somebody will see it.
Force day end is styled as destructive, because it is one person deciding another person’s day is over, and that decision reaches payroll.
The edges
Attendance has a sixth state. Present, absent, half day, weekly off, holiday, overtime — and Issue. Issue is not an attendance outcome. It is the absence of one: a day the system cannot resolve into any of the other five. Giving it a place in the legend means an unresolved day looks unresolved on the calendar instead of defaulting to absent.
Assignment has a history. An employee is assigned to a site, a machine and a work order, and that assignment can change mid-month. Because hours are attributed to a job, moving someone between machines changes which job their cost lands against — so the change is a recorded event with its own history view, not an edited field.
Empty and loading states are designed. The loan approval queue has both. An approvals screen that is empty is not a failure — it is the normal state most of the month, and it should say so rather than looking broken.
What I would do differently
Approve All does not say what it does with the batch it cannot approve. The screen holds eight requests: five ready, three with missing fields or validation errors. The instruction says errors must be resolved before approval. The button says Approve All. Whether that approves five and leaves three, or refuses entirely, is not answered by the screen — and both are defensible. It needed either a different label or a disabled state, and got neither.
Partial failure of a long-running job is undesigned. The shift mapping job shows fifteen of twenty-four applied. Nothing in the flow says what an operator is looking at if it stops there. A half-moved crew is a worse state than either a completed move or a failed one, because nobody knows it happened.
The bulk-fill panel explains itself badly. The two behaviours are right. The words around them are not. The panel is headed Bulk Fill Missing Fields, and directly under it sits Applies to all selected employees unless overridden — a sentence that describes one of the two buttons while appearing to describe both. An approver reading top to bottom gets a consistent story about fill-missing and then finds a button that does something else. The decision survived review; the copy around it did not get the same scrutiny, and on a screen where the whole point is disambiguation that is the part that had to be right.
All three have the same shape: the happy path and the failure path were both designed, and the state in between them was not.
What the work rests on
Five rules, each of which cost something above.
- 01A bulk action must state which of its two meanings it has. Fill the gaps and overwrite the values are different jobs. Naming only one of them is a data-loss bug with a friendly interface.
- 02Show the diff, not the count. “135 records will be updated” is easy to approve and impossible to verify. Current → New, per record, is neither.
- 03An unknown is a state, not a default. A day the system cannot resolve is marked unresolved. It does not quietly become absent.
- 04A correction is a record. Marking a session wrong beats editing it to something plausible, because the second one produces a clean sheet nobody can audit.
- 05Attendance is money. Every screen that touches an hour is touching somebody’s pay, and is designed at that weight rather than at the weight of a form.