Incoming call scheduler
Admins use Incoming Call Routing to decide where a business location's calls go: which numbers ring where, on which schedule, on holidays and when staff step away. I redesigned it so setup is done once, every number is visible, and nothing fails silently, without breaking a single existing schedule.
The problem
Routing settings were spread across screens in an inconsistent legacy interface, and six issues kept coming up:
- 1Repeated setup.
Holidays were entered by hand on every scheduler.
- 2Confusing holiday types.
Single, fixed and moveable dates each worked differently, so holidays were hard to set up correctly.
- 3All-day holidays only.
A holiday's routing applied to the whole day. Calls couldn't go to a different number for part of it.
- 4No feedback.
Changing the default scheduler, or a number's scheduler, gave no confirmation.
- 5Away mode outside the portal.
Letting staff forward their calls during a break was set up outside the portal.
- 6Silent failures.
Unhappy paths showed no errors, so admins could think a setup worked when it didn't.
How I learned this
- SupportConversations with users and the support team
- Tickets and dataRecurring routing problems in support tickets
- StakeholdersReviews with product and engineering
- TestingSessions on the working prototype
Before and after
Screens from the old page next to the new one. Brand and data are fictional.
Main page
Before: Schedules in one long list, and a warning that said what was wrong but not what to do.
After: Tabs for schedulers, numbers, holidays and away mode, and a warning that says what happens next.
Editing a schedule
Before: Every time slot was added through its own pop-up.
After: Time slots are drawn on a weekly calendar, in one editor with tabs.
Holidays
Before: Picking a holiday type meant reading the rules for each kind of date first.
After: One form: recurring or one-time, fixed or movable date, all day or specific times.
Design decisions
Each problem got a direct answer in the new page:
- Holidays entered per schedulerLocation holidays set once, reused by any scheduler
- Confusing holiday typesOne holiday form: recurring or one-time, fixed or movable, all day or specific times
- All-day holidays onlyHolidays can be all day or a time range, each with its own destination
- Number assignments hard to readEach number's scheduler and destination easy to scan, with unassigned ones flagged
- No feedback on changesClear notices, including before a number is moved to another scheduler
- Away mode set up outside the portalAway mode rules in the page: where calls go, and the PIN staff enter on their phone
- Silent failuresWarnings that say what will happen until the problem is fixed
- Settings across several screensOne page with tabs, and a scheduler editor for numbers, time slots and holidays
Redesigning without breaking what's live
Admins had already built schedules that were routing real calls every day. The redesign couldn't ask anyone to start over: every legacy schedule had to carry over as it was and keep routing calls exactly as before.
So the new model had to represent everything the old one could. Location holidays sit alongside each scheduler's own custom holidays, which take priority, so existing setups keep working while new ones get the simpler path.
Outcome
- Live with admins
- The redesigned page is live and in daily use.
- Nothing rebuilt
- Existing schedules migrated as they were.
- Built on the library
- Prototyped in code on our shared components. Mockups to code
What I learned
The riskiest problems were the silent ones: an admin who thinks a setup worked is worse off than one who sees an error.
- Designing for the data people already have matters as much as designing the ideal flow.
- Removing repeated steps did more for admins than any visual change.