Most attendance tools can tell you the exact second someone tapped 'check in.' Far fewer can tell you whether that check-in was actually late — because lateness isn't a property of a timestamp, it's a property of a timestamp relative to a shift. Without a shift, 9:04am isn't late, early, or on time. It's just a number.
That's the gap we closed with shift scheduling: a lightweight way to define working patterns and assign them to people, so every other calculation in the product — lateness, overtime, payroll — has something real to measure against.
How shifts work
A shift in Attenzo is deliberately simple: a name, a start time, and an end time (optionally tied to a location). An admin creates a handful of these — 'Morning', 'Evening', 'Weekend' — once, and then assigns each employee to one from the Team page.
- Shifts are org-wide, not per-employee, so updating 'Morning shift' to start ten minutes later updates lateness rules for everyone on it, instantly.
- Assignment lives on the membership, not the person — if someone moves teams or their schedule changes, reassigning them takes one dropdown, not a support ticket.
- A check-in can still explicitly name a different shift than the one someone's assigned to (useful for a one-off covering shift), and that explicit choice always wins over the default assignment.
From shift to lateness, automatically
The moment an employee checks in, Attenzo compares the check-in time against their shift's start time, in the organization's configured timezone and grace period — a per-org setting, because a five-minute grace period is generous in some cultures and pointless in others. Anything past that grace period accrues as late minutes on the attendance record, visible immediately to their manager, no end-of-month reconciliation required.
The same shift powers overtime math on check-out: worked minutes beyond the organization's standard workday roll into overtime, multiplied by whatever overtime rate the org has configured. It's the same underlying data doing double duty — one shift assignment feeds both 'was this person late today' and 'how much overtime pay do they owe this month.'
Why we didn't build a drag-and-drop calendar first
It's tempting to start a scheduling feature with a beautiful weekly calendar grid. We didn't, on purpose: a rotating, per-day, per-person calendar is a genuinely hard scheduling problem, and building it before the simpler 'assign a standing shift' case would have meant shipping neither. Most small and mid-sized teams don't rotate people through a dozen different patterns a week — they have two or three shifts and assign people to one of them for a long stretch of time. We built for that reality first, and the door is open to add per-day overrides and rotation on top of it later, without needing to redesign lateness or payroll math around it.