Unified Scheduling Experience for IBM's Technical Support Teams
Before this project, scheduling at IBM Support was fragmented Aand managed through spreadsheets, emails, and team-specific tools across thousands of users in over 70 countries. I helped design and spec a unified calendar system that supports field and remote agents, hybrid roles, and real-time editing. The result brought structure and flexibility to a complex, globally distributed workforce.
To honor my NDA, I’ve kept this case study free of confidential info. Designs are my own recreations using public design systems, and don’t reflect IBM’s views.
Role
UX/UI Designer, Technical Spec Co-Author
Team
IBM, CIO Design
Timeline
2024
Disciplines
UX/UI Design, Product Design, Systems Thinking, Design Documentation, Product Strategy
Overview
This project focused on expanding IBM Support's internal scheduling platform to technical support field engineers, remote support engineers, hybrid roles, and technical support managers. For years, IBM’s global support teams operated in silos, using different systems and processes across countries, regions, and product lines. Although scheduling had recently been centralized into one platform, it was still largely manual and difficult to scale. At the time I joined the project, the system could display calendars across teams and geographies, but every schedule had to be input by hand - an unsustainable task for a user base of 25,000+ internal IBM Support's users.
I partnered with product managers, engineers, and architects to design new calendar experiences and co-author the technical specification. Our work introduced role-based views, editing workflows, and the system logic required to support real-time updates and data synchronization across platforms.
Scope & Responsibility
I was involved from the very beginning, shaping both the user experience and the system architecture. Working alongside product managers, engineers, and architects, I helped define how field and remote schedules should be visualized, edited, and managed in a single interface. I also mapped out the backend integration points and contributed directly to the technical specification, which was later approved by IBM's architectural review board.
Design Challenges
One of the biggest challenges was unifying scheduling for multiple agent types while preserving the logic and rules of their respective systems. Field engineers were grouped by service territory, while remote technical engineers were organized by team. Their schedules lived in different systems and followed different workflows. Hybrid engineers, who operated in both capacities, had no centralized calendar, often switching between various tools. As a whole, IBM Support often had to juggle multiple tools such as custom spreadsheets, legacy internal apps, or team-built workarounds just to manage their day-to-day and understand their availability.
We needed to create a calendar that allowed managers to view coverage across regions and skills, while also giving agents a reliable and accurate reflection of their own time. Beyond that, we had to consider editing functionality: who could create or change shifts, add unavailability, or remove entries altogether, and under what conditions. To maintain accuracy, every interface interaction needed to match real-time backend logic.
This diagram illustrates the high-level architecture behind the calendar experience we designed. While the user interacts with a clean, role-aware interface, every action flows through a backend system that validates permissions, triggers sync events, and connects to multiple data sources.
A Calendar Built for Complexity
The redesigned calendar featured two primary views: one for field service managers and agents, and another for teams supporting both remote and field roles. Each view was tailored to the data structure and workflows of its users. Managers could filter by territory or skill, while hybrid agents could see both sets of assignments in one place, with clear visual indicators showing the source of each event.
We implemented in-line editing options such as dragging to adjust time slots and modals for editing event details, while also integrating system-level warnings when a change affected multiple people. For example, if a shift was shared by an entire territory, editing it triggered a warning to confirm the broader impact. This helped prevent accidental changes to schedules across large groups.
We designed a calendar that displayed shift hours, unavailability, and assignments across roles and territories.
Interaction Highlights: Working Hours
Inspired by modular scheduling systems in platforms like Google Calendar and Salesforce Field Service, I designed a centralized Working Hours functionality within STAR: a flexible way for managers and admins to set when agents are available to work.
Working Hours are reusable time templates (like “Mon-Fri, 9AM–5PM, EST”) that can be quickly applied to multiple agents, instead of editing each schedule manually. This made managing large support teams easier, faster, and more accurate, especially across different time zones, regions, and agent specializations.
Working Hours are:
- Reused across agents, teams, and business units
- Customized by timezone, day of week, start/end times
- Color-coded and labeled for clarity in team calendars
Admins can:
- Create templates (e.g., 24/7 support, night shifts, rotating coverage)
- Apply those templates to multiple agents with defined start/end dates
- Customize aliases and colors per org for easier filtering
Key Features
- Template-based scheduling: Admins can define reusable working hour patterns (e.g. "M-F 9–5 PST") by timezone and time slots
- Bulk association via team selection and date ranges
- Conflict warnings for overlapping hours with visual callouts
- Org-specific aliases for customization by business unit
- Color-coded rendering in calendars with hover tooltips
Creating a Working Hours template
Admins can define reusable schedules by selecting a timezone and creating time slots for each day of the week, including support for split or overnight shifts.
Associating Working Hours to Agents
Managers can apply templates to multiple agents with defined start and end dates, while the system flags scheduling conflicts in real time.
Disassocating Working Hours to Agents
Similar to the associating screen, admins can remove templates from agents with a simple team-based picker, including safety warnings and automatic date adjustments.
Privacy & Governance
Because the platform was used globally, privacy compliance was a key concern. In certain regions, agent names had to be anonymized by default unless the agent explicitly opted in to sharing. We designed the calendar to display masked names (e.g., “Agent – Germany 01”) unless the viewer had appropriate access. Visibility settings were configurable, and logic was built into the UI to guide users through privacy rules without disrupting the experience.
Results
- Launched with 100+ preloaded templates migrated from CSP’s legacy system
- Reduced admin scheduling time and manual entry errors
- Improved visibility into agent availability for managers and teams
- Created a scalable foundation for dual-role agent support and rotating shift planning
Project Wrap-Up and Expected Impact
In the final phase, I worked closely with engineering and architecture teams to validate implementation details, finalize flows, and align with backend constraints. Our specification was formally approved by IBM’s Architecture Review Board, and the internal rollout received enthusiastic feedback, especially from architects who appreciated how clearly the design translated complex system logic into an intuitive, flexible experience.
As phased releases continue, the scheduling features are expected to reduce manual entry, support hybrid roles, and streamline workforce planning for over 25,000 IBM support agents across 70+ countries. Early feedback has been overwhelmingly positive, and I’m proud to have contributed to a system that brings clarity, control, and scalability to such a critical part of IBM’s support infrastructure.