Case study · SuperPunch
Scheduling a team of thirteen.
Scheduling is where everything starts in a contact centre. Get the shifts
wrong, and the exceptions, payroll, and attendance scores cascade. It's the
most consequential module in the SuperPunch platform — and the one with
the most unresolved design debt when I joined.
Project
SuperPunch
B2B SaaS · Internal
workforce
management
platform for contact
centre operations
Timeline
2020 – 2025
5 years · Schedule
module active
throughout
My role
2020 – 2022
Junior → Mid UI
Designer
2023 – 2025
Sole Designer (UI +
UX)
Collaborators
Product
Management
Engineering
Workforce
Operations
Context
The module nobody questioned
I didn't design the original version. By the time I had any real ownership, the patterns were
already set. What I did was spend two years watching supervisors use it, filing away the
friction points, and waiting for enough organisational space to actually fix something.
This is a retrospective. Some decisions held up. Some didn't. And some problems I saw
clearly but couldn't move on — until now.
Problem diagnosis
What was broken, and why it mattered
The colour system told you something was wrong. It didn't tell you what.
Four shift states. Confirmed, pending swap, conflict, leave. Visually, confirmed and pending were both blue —
one slightly lighter, one slightly darker. At a glance, across a grid of thirteen agents and seven days, that
distinction disappeared. The conflict state was red. Red implies urgency. But the actual conflict was a data
discrepancy between SuperPunch and Aspect, a legacy tool the company was phasing out. The system's
own advice was "always follow SuperPunch." There was nothing to act on. The red was lying.
The modal was the wrong container for the job.
Shift configuration involves a date, a start time, an end time, break scheduling — broken into individual slots
down to the minute, because in a contact centre environment, breaks are that regulated — repeat rules, and
multi-agent selection. Cramming all of that into a modal dialogue meant the form had to scroll internally. The
calendar disappeared behind the overlay. Supervisors lost their spatial reference entirely.
Two buttons. No workflow.
Save. Save & Publish. That pairing implies a draft-to-approval pipeline — a familiar pattern from any
publishing tool. But there was no draft state visible anywhere. No one knew where a saved draft went. No
approval status surfaced after publishing. The buttons promised a system that didn't exist.
The People Picker assumed everyone had a unique name.
Agents on this platform come from Winnipeg, Hyderabad, Bangalore, Manila, Cebu, Kingston, Las Vegas, and
Phoenix. Singh is one of the most common surnames in India. Filipino and Jamaican naming conventions
produce frequent duplicates. A flat name dropdown, with no ID, no role grouping, no filtering — that's not a
minor UX inconvenience. In a scheduling context, selecting the wrong Navdeep Singh has payroll
consequences.
Design decisions
What I changed, and the thinking behind each decision
Modal → side drawer
Before
A modal dialogue that covered the calendar
entirely. The form scrolled internally. Supervisors
had no spatial reference while configuring a shift
— they couldn't see which days were already filled.
After
A right-side drawer that slides over the calendar
without obscuring it. The full week remains visible.
The form breathes. Nothing scrolls internally.
Context is preserved throughout the configuration
process.
Conflict colour: red → amber
Red means "act now." A data discrepancy between Aspect and SuperPunch doesn't meet that
bar — the system already tells you to ignore Aspect. Amber correctly signals "worth noting, no
action required."
Night shifts got their own green treatment too. Because night shifts cross midnight. They're
structurally different from daytime shifts, and treating them identically creates real ambiguity
in how they display on the calendar.
When a supervisor opens a conflicted shift, the drawer now opens directly on the Conflicts tab — with
a side-by-side comparison of the Aspect and SuperPunch schedules. The conflict tab label carries a
passive amber signal visible from the calendar before you even click.
Draft and approval made visible
Before
"Save" and "Save & Publish" with no visible draft
state, no approval tracking, and no way to know if
a submission had been received.
After
"Save draft" and "Submit for approval" — with a
persistent status bar at the top of the calendar
showing whether the week is draft, pending
approval, or published. The workflow is legible
without adding navigation.
People Picker rebuilt as a platform pattern
Search accepts both name and employee ID. Because when you have three Navdeep Singhs
on a team, you need the ID. Agents are grouped by role — Team Leader, CSR Level 2, CSR
Level 1 — because that's how supervisors actually think about their teams. A filter for
unscheduled agents means that at the end of a planning session, finding the gaps takes
seconds.
This isn't just a scheduling component. Every multi-agent selection across the platform has the same
problem. The People Picker is a system-wide pattern, and this is where it gets defined.
Product thinking
The edge case that changed how I think about constraints
At some point I asked: should the system prevent a supervisor from scheduling the same
agent twice on the same day? Seems obvious. Prevents accidents.
Then I thought about night shift workers. Someone working 11 PM to 7 AM — their shift starts
one calendar day and ends on another. A calendar-day rule would make it impossible to
schedule the tail end of a night shift and a midday training on the same date, even when
those two windows don't overlap at all.
The right constraint isn't one shift per calendar day. It's no overlapping time windows for the same
agent.
Two shifts on the same date are fine, as long as they don't intersect. It's a small rule change —
but it affects how exceptions get calculated, how payroll reads the data, and how compliance reports
are generated.
That's the part of scheduling design that isn't really about UI. The UI just has to make the logic
legible enough that supervisors trust it.
Reflection
What I'd still want to validate
The approval workflow is a proposal
In production, I'd want to know who the actual approver is — a workforce manager, a regional
lead, an automated rule — and what a typical turnaround looks like. That changes how
prominent the status bar needs to be, and whether the submit action needs to trigger a
notification to the approver.
The People Picker grouping is an assumption
Grouping by role assumes that supervisors think in role tiers when building schedules. This
may not always be true — in some contexts, team membership or physical location may be
more relevant groupings. This is a hypothesis worth testing before shipping.
What this module taught me
Scheduling looks like a UI problem. It isn't. It's a data integrity problem with a UI on top. The
design decisions that matter most in this module — how conflicts are detected, what a "day"
means for a night shift worker, when a draft becomes a published commitment — all of them
have consequences that ripple into payroll, compliance, and HR. Good interface design here
means understanding those consequences well enough to make them legible to someone
who shouldn't have to think about them.
SuperPunch · Schedule module · Evan Zhai 2025
← Previous case
Next case →
Evan Zhai
Work
About
Contact
This case study
Overview
Problems
Design decisions
Edge cases
Reflection
← All work