top of page

Jeopardy Management  Tool (JMT)

PROBLEM

The Control Centre (CC) agents in Montreal were finding it difficult to manage the status of all jobs in a day. They needed visibility on all jobs and all technicians on shift to ensure all the work is completed accordingly.

 

SOLUTION

The Jeopardy Management Tool provides agents with a table view of all jobs and a gantt chart of technician schedules to allow agents to easily manage the status of all jobs and ensure technicians have adequate work to do.

User Research

Conducted on-site research, shadowing CC agents to understand their process in managing jobs

Wireframing + Prototyping

Led UX and UI design on wireframes, creating a hi-fi version of app design on Sketch / InVision

User Testing

Conducted user tests of the app and feedback sessions with CC agents to vet process

ROLES 

CONTEXT & RESEARCH

The CC agent's role is to ensure that all jobs scheduled for service each day are completed in a timely manner by all technicians on shift. 

 

While their process was complicated and involved several steps, the most major problem lied in not having a bird's eye view of all jobs at once after they have sorted out which jobs need to be completed on that day in the morning.

A CC agent would be responsible for the status of jobs from his or her assigned region. Jobs were assigned into standard intervals. If a job was not completed by the end of the interval, the job would be considered in jeopardy.

Their CMO today involved having to manually follow up on each job using a tool that was made over 20 years ago. They would have to keep tabs manually on each job to ensure techs completed them on time, or to find out if any action was required to bring the job closer to completion (i.e. contacting the customer, same-day escalations).

One major piece to this project is that this CC focused on Wireless Home Internet (WHI) work, which was usually done by vendors. As a result, the CC agents worked closely with the agents from the vendors. 

To explain processes better, first, the left diagram (or the one above) shows the general process of an agent's morning:

  1. Before the technicians started their day, the agents received a list of all jobs to be worked on for the day at 6AM from the vendor.

  2. By 8AM, the CC agents have all the jobs loaded to the technicians' boards for the day.

  3. The rest of the day consists of the jeopardy management work mentioned earlier, ensuring that all jobs were completed on a timely manner.

Because there was a need to view technicians and their loads, the concept of a "Technician View" was brought up at this point on top of the general view to monitor job statuses (Job View).

 

Second, the right diagram below shows the jeopardy management process flow of a job on the agent's board depending on the status of the job. It shows the action required to be done by the CC agent in order to resolve the jeopardy.

EXISTING SOLUTION

A look into the company's existing softwares brought us to an existing Jeopardy Management Tool used by the Central region's CC. It consisted of 3 main panels:

  1. (On landing) A filter panel to choose types of jobs and intervals to focus on

  2. A general page of the quantity of all jobs for the chosen filters

  3. A drill-down page based on region and type of job to see a filtered list of jobs and their statuses

 

While the tool gave a bird's eye view of all jobs by region, there was not much focus given to the UI with lots of text and conflicting colours that were not accessibility-friendly. ​The Central JMT also did not have vendor actions, as the Central region did not have vendor work to account for. These factors led to a consideration for a completely independent design.​

 

Search + filters

Job counter

per status

Job cards without actions (job ID, job type, tech ID, appointment time)

Main (with Divider) (+no faces).png

Messaging tool for contacting vendors

Job cards with actions (job ID, job type, tech ID, appointment time, action)

When a job card was clicked on, a detailed panel would appear to provide a more detailed account of the job, such as the vendor this job is from and an action or remarks history between the CC agent and the vendor agent to ensure proper communication was held on each job and no context was left out when handling jeopardies.

 
Main (Expanded) V2.png

Detailed job panel

General job details (job type, tech assigned, appointment, region)

Vendor information

Related job information

Action / Remarks History between agents via a chat message thread interface

Tech View

A tech view was new to the existing JMT, as there was not an existing view to see how technicians were loaded with jobs. It was crucial that agents knew when technicians were overloaded so they weren't causing other jobs to go into jeopardy. Conversely, knowing when techs were underloaded helped agents determine which other technicians could take the jobs from overloaded technicians.

The Gantt view was based on the interface from another existing software in the Central region used for dispatching jobs on technicians. The WHI team also did not have access to this tool and had no previous experience in using it. However, the agents liked the Gantt view to show technician load, as it clearly indicated which technicians had too many jobs in one interval and which techs also had openings to load jobs to.

Each row in the gantt consists of one technician and his/her jobs for the day. All jobs are loaded onto the tech's board in the morning, so they will all be stacked to start at the beginning of the day, and it is left up to the technician to plan out the best route through the day to get through all the jobs. Each job's time bar will adjust in position as time progresses.

A technician can fall into 2 types of jeopardies from the Tech View perspective:

  1. Overloaded: if the tech has too many jobs lined up in a single interval (i.e. duration of work exceeds duration of interval)

  2. Skill set: if the tech is assigned to a job that the technician does not have the skill set for

 

Search technician

Preset filters to show which technicians are in jeopardy

Filters

Technician

(Tech ID, skill, hours of work, intervals overloaded)

Tech View 01.png

Testing and next steps

5 agents were involved in testing the wireframes. They were brought through a prototype via a task list that tackled managing each type of jeopardy, flipping between both the Job and Tech Views to accomplish each task. All agents easily navigated through every task without much difficulty or assistance.

One crucial piece that came out of the testing was the realization that majority of jobs would actually be stacked in the first column of the Job View - Scheduled / Assigned. As a result, only 1/8th of the screen was in use most of the time, which made it seem impractical to use the Kanban view.

As a result, a new Job View had to be wireframed and tested under tight time constraints to meet development timelines. The Tech View, however, saw no issues, and could be kept the same.

FIRST SOLUTION: KANBAN (JOB VIEW) + GANTT (TECH VIEW)

 

Job View

The idea of Kanban came about with the attention CC agents had to give to the status of jobs. The thought was that, if jobs were organized by status, CC agents can easily prioritize which jobs were most urgent and be able to see right away which jobs required action based on the status. As a result, the Kanban concept had the statuses divide up the jobs in columns. The Kanban would be used as the layout for the Job View.

 

In general, the Job View would become the new landing page as this was the CC agent's primary focus. The filters were tucked as a secondary option and were made smarter in terms of the system being set to a default based on the user's login. In other words, the filters were deemed as a redundant action, since agents didn't change their selections very often, but were forced to each time today in the Central region.

The direction on the new layout was to simplify the experience while giving it a stronger company feel with the branding. Having to handle so many jobs was already complicated enough, so jobs were separated into cards to make them easier to see vs. in rows of a table. A focus was placed on the actions that CC agents had to carry out to ensure no job was left unattended.

Jobs were simplified in representation on the Kanban, fit compactly into cards and focusing on:

  1. The interval times to ensure no jobs were attended to late or missed (as shown by the time bar)

  2. Any resulting action based on the status of the job (as shown by the blue primary and secondary buttons)

Jobs naturally progressed through the first 3 columns: from being Scheduled or Assigned to a technician to the technician being Dispatched or On Site of the customer's premise to the job being Completed. The job would be considered in Jeopardy if it fell out of these 3 statuses, falling into one of the other 5 columns.

Here's a mid-fi wireframe of the Kanban Job View, outlining some other features that were planned:

SECOND SOLUTION: ENHANCED TABLE (JOB VIEW) + GANTT (TECH VIEW) [UNCHANGED]

 

Job View, take 2

Due to the short time given to come up with a new Job View, a quick brainstorming session was done where each member of the team, including Operational members. The team looked to other existing software in the Bell system for similar functionalities and interfaces. After performing a few rounds of rapid prototyping, the designs all aggregated towards a vision that resembled an enhanced version of the existing JMT table format.

 
Rapid Prototyping Session - Sketches.jpg

With this second version of Job View, there was also an emphasis placed in providing more details upfront. A common complaint from the testing was that the users did not want to have to click onto the job and look in the details panel to see all the job's details. Clicking into the job meant an intent to action something, so they wanted the ability to see all the context upfront. As a result, there was a requirement to load the table format with lots of data with the challenge of showing it all without feeling overwhelmed.

Leveraging the actual screen size of the monitors that CC agents used, the table was maxed out to include as many columns needed as possible without scrolling horizontally. Below is a hi-fi wireframe of the final Job View, which focused on improving readability and interactivity with the jobs.

Filters

Search

Job counter per status, colour coded to system colours

Locked job

(one agent can work on a job at a time)

Selected job

(becomes locked for others)

Dashboard - Submitted REASSIGN EDITED - Post FWFM.png

Testing with the same 5 agents was done using this new Job View and the same task flow to handle each jeopardy situation. While results were also positive, the agents preferred this view as they liked (the security of) having access to all the information at a glance.

Simplified message panel 

Messages became preset responses to standardize and speed up the communication

NEXT STEPS: Considerations for future changes

The wireframes were then sent the development team to build the tool. Given the short time frame to build this entire tool in the span of 5 months (including design work), it was inevitable that features would be de-scoped, such as the ability to message other agents. To accommodate the loss of that feature, the messaging system was simplified to ensure agents could only use preset answers that had a singular interpretation to avoid misunderstandings.

The lesson learnt from this project was that change management was a huge piece to getting the users' buy-in on new concepts, as well as having the time to try out new methods. While the Kanban view was not successful in showing majority of jobs, the concept of Kanban did show clearer which jobs were in jeopardy. With further tweaking, the Kanban view can better strike the balance between presenting CC agents with the information which jobs were in jeopardy and the security of knowing the status of all jobs at a glance.

bottom of page