Scheduling is one of the biggest pain points for Amazon CS Associates globally. Shifts are assigned quarterly with little room for change — and often don't reflect the hours associates can actually work well.
I initiated this project after seeing scheduling consistently surface in satisfaction data. The idea: let associates submit preferences and feed them into the scheduling engine at assignment time. Leadership picked it up quickly, and I partnered with Product to build it into AtoZ — Amazon's internal scheduling tool.
Associates are hired to meet business demand — not necessarily to work the hours that fit their lives.
Amazon CS recruits based on when contact volume is highest. Schedules are assigned quarterly and largely fixed once set. Workarounds like shift swaps exist, but the core problem remains: associates have no input into the schedule they receive. This consistently ranked among the top drivers of dissatisfaction and attrition.
Existing workarounds put the burden on associates to fix a problem the system created. I wanted to address it upstream, at the point of assignment.
Global Complexity
Labour laws vary by country. Some associates have fixed shifts in their contracts. No single solution works everywhere.
Raised Expectations
Asking for preferences creates an implicit promise. If the shift doesn't change, disappointment is worse than never being asked.
Fairness at Scale
Preferences overlap heavily — most people want daytime. Someone has to get a less desirable slot. How do you make that fair?
No Existing Metric
There was no way to measure how well a shift matched someone's preferences. We needed to invent one.
Before designing anything, we ran a global survey across US, EU, and India to understand what associates actually wanted from their schedules.
It's not just the hours
Days of the week and break timing mattered just as much as start time.
Shift structure matters
Some preferred one long shift; others wanted two shorter shifts with a break — especially caregivers and long-commute associates.
86% prefer daytime
Preferred hours clustered heavily around local daytime — directly conflicting with peak demand. We couldn't give everyone what they wanted.
The bar is lower than expected
Associates said if even 1 out of 3 schedules reflected their preferences, they'd feel meaningfully better. This reframed what success looked like.
The more detailed the preference input, the higher the expectation — and the higher the disappointment when it isn't met.
Early iterations
We explored ranked preferences (Preference 1, 2, 3 — fallbacks if the first can't be met), shift structure options (one long shift vs. two shorter shifts), and "block hours" where associates mark times they absolutely cannot work.
After testing with associates, the problem was clear: a long, detailed form set expectations the system couldn't meet. The more options they filled out, the more they expected to get exactly what they entered.
We scaled back to one preference set: preferred days, preferred hours, and shift type. Simple enough to set honest expectations. Specific enough to be meaningful.
One preference set, not many
Multiple ranked preferences implied a higher chance of fulfillment. One set kept expectations calibrated.
No "block hours"
Asking what they refuse to work felt like a commitment we couldn't honor. We focused on what they prefer.
Shift type as a preference
One long shift or two shorter shifts — a real need from research, without adding model complexity.
Transparent communication
Preferences are considered, not guaranteed. The UI needed to make that clear upfront.
We wanted to be upfront and clear about what to expect, so associates don't feel they've been given a false promise.
When not everyone can get what they want, how do you make the outcome feel fair?
I worked with Product to design a scoring mechanism that feeds directly into the scheduling engine — making fairness something the system actively optimizes for.
Preference Fulfillment Rate
Measures overlap between assigned hours and preferred hours. 100 = complete match, 0 = no match. Scores accumulate across cycles.
PFR as a scheduling input
Associates with lower accumulated PFR scores get priority in the next cycle. Those who've consistently received unfavorable shifts move up the queue.
Fairness over time
No single cycle satisfies everyone. But over multiple cycles, the system balances out. The goal is equity across cycles, not perfection in any one.
Built into AtoZ — the scheduling app associates already use — so there was no new tool to learn.
Piloted in India with 400 associates. Results validated the core hypothesis.
PFR Score Improvement
84.2% → 89.4%Compared schedules 6 months before and after adoption. Average PFR rose by 6.25% — a meaningful increase in schedule-to-preference alignment.
Associate Sentiment
29%29% of pilot associates reported that Preference Based Shift Assignment helped them get more desired schedules.
Rollout
India + EUFollowing a successful pilot, the feature launched to all associates in India and the EU, with further expansion planned.