This is Workforce Optimization Suite,
Manage Workforce, to improve Efficiency
Project Overview
Workforce Optimization Suite is aimed at increasing the efficiency of the working of this complex machine that is a customer service operation or Contact Centre.
It comprises of modules to facilitate the planning and optimizing
-- Forecasting, Scheduling, Rostering, Intraday.
My Role
-
Contributing to product requirements
-
Product Vision development
-
Contributing to metrics measurement
-
Interaction design
-
Presentation to stakeholders
-
User Research and Usability testing (team effort)
-
Design Documentation (Product Decisions, Rationales)
-
Planning and interfacing with Development team and other stakeholders
-
Feedbacks to Design Systems
-
Creating and maintaining design language
Team Setup
-
1 UX Designers
-
1 Product Managers
-
1 to 3 Research Experts
-
1 Architect
-
3 to 4 Front-end Developers
-
8 to 12 Back-end Developers
- 15+ Users with monthly to bi-monthly interaction and testing.
Project Duration
-
The product runs of Agile development methodologies.
-
It has fast release cycles.
-
I've worked dedicatedly on this product for 18 months.
Tools
-
Sketch
-
Powerpoint
Context
Workforce Optimization Suite is aimed at increasing the efficiency of the working of this complex machine that is a customer service operation.
It begins with a Forecast, gauging the number of chats or calls that can be predicted at within any given half hour interval of any given day, month or year; and then also predicting the number of agents that would be required to cater to those chats or calls.
It is then followed by a Schedule, which is slotting the number of agents of different proficiencies to be scheduled to a particular workshifts for these predicted number of customer requests.
This schedule, when takes into account the agent's planned time-offs, proficiencies, personal preferences, circumstantial changes, shrinkage, and so on, gives out a who is to come at what time, list. This is the Roster process.
The Intraday module then takes the baton and ensures that the balance between number of chats/calls and agents is maintained within the ongoing shift. It slots the break times for the agents according to the demand in the funnel.
Metrics such as agent concurrency, handle times, utilization and shrinkage, contribute to facilitate this optimization. It also aims to accommodate client campaigns surges and anticipated sporadic changes such as festivals and events.
USERS
WFO would affect all strata of the Contact Centre. However, the main actors within the Planning, Forecasting, Scheduling, Intraday modules would be:
The primary user for forecast is the Workforce Manager, and the Planner
The user of the forecasted data as well as Intraday are the Team Lead and the RTM.
WFM
Userbase ~ 5
Planner
Userbase ~ 5
Team Lead
Userbase ~ 50
Real Time Manager
Userbase ~ 5
OBJECTIVES
Since the product looked at increasing the efficiency, design needed to bring in the human aspect to the whole maximizing each metric paradigm. This led to quite a few metrics to be added to the prediction models while also debating on the least actionable time for forecasting.
Influencing the product roadmap for the whole Suite was another objective which needed to be backed by robust research and documentation.
Since there was a transition of two product managers, the objective was also to gain the trust of the dev team as well as the users.
CHALLENGES
The whole act of using algorithms to optimize the workforce meant that a lot of roles would be reduced. Thus, gaining the user's trust was the most challenging aspect of this activity. One way proposed was by staggering the deployment.
The intraday part also meant that the massively human aspect of the team leads / RTM, needed to be integrated into the product algorithms, this identification of those was a challenge.
Design-wise there was a need to get out of the excel based data entry paradigm, which was a challenge both technically as well as from the user's mental model.
Learnings
WHAT WENT RIGHT?
Design Sprints
One of the biggest achievements that I can vouch for was the initiating of the culture of having Design Sprints to set up product roadmap, vision and strategy and bringing all the stakeholders on the same page.
Initiated by my manager and I, I learnt that the impact Design Sprints can do in a short period of time. It has since become my go-to starting method in the design process.
Involvement of designer in all aspects of product development
The transition of the product management lead me as a designer more accountable and responsible for the product. This involved asserting the need of the product, to chalking down the feature details and story prioritizing. This was also when I got the first hand understanding of the business implications of design and development of design.
Testing
Testing was conducted at each milestone, i.e. right after a rough mockup, after high fidelity mockup, after HTML implementation, and the developed staging environment. A/B testing too was carried out till the HTML phase. This even helped in sensitising the stakeholders about design implications.
Documentation
This project was perhaps the most robust documented. Design decision document and vision were the highlights. This served as reference to other products and future designers.
WHAT COULD HAVE BEEN DONE DIFFERENTLY?
Rolling out of application
The forecasting application runs on a central forecasting algorithm. The design's viewpoint was to embed the output of this algorithm inside the current task flow and functioning and evaluate the accuracy of the algorithm while also increasing its adoption. The product management's viewpoint was to have an interface and deploy it to the user.
Minimum Forecasted Time Period
The forecasting algorithm looked at half hour, while the short breaks were for 15 minutes. My opinion was that the forecasting should haven been done for this shortest break period or 15 minutes, or even the same as the AHT, to get a richer forecast. However, the accuracy of the forecast in such smaller intervals was a technical challenge.
Metrics which drove the chat funnel
The Intraday metrics such as Concurrency, AHT, etc. drove the change to the chat funnel. This thus made the system very mechanical in my opinion. One of the inclusions here should've been the ability for each agent to choose their workload.