Customer Service Rep persona
This feature showcases the process of towing a locomotive from the shop and ensuring all the relevant work orders are completed.
Unlike a car, you don't drive the locomotive out of the shop once the work is completed.
1. The CSR journey
-
The page provides an overview of the application, acting as the home screen.
-
The top blue box provides a high-level view of the locomotive, such as its current location, locomotive codes, etc
-
WO status = work order status, which must be completed for the work/ task to be closed.​
-
Complete means the task is complete, which disables the reason code on its right.​
-
Exception means the task isn’t complete, but needs to be closed for the locomotive to be towed
-
An exception requires a reason which is why the reason code is attached to the section..more on this below.
Here's some quick context on this case study.
Here's some quick context on this case study.
Ticket managment
Here's some quick context on this case study.
01
Objective:
-
Our team was asked to come up with a Quest Proof of Concept (PoC) where the goal would be to devise a Fleet Management application addressing the use case of a STAT order fulfillment that would allow the Customer Service Representatives (CSR’s) to:
-
Manage master data for Customers, Routes, Labs, Fleets, and Drivers
-
Assign/Scheduled routes as changes dictate
-
Receive and update customer information (on demand)
-
Ensure smooth data flow/integration
02
User Segments:
-
Customer Service Representative (CSR) receives tickets and assigns drivers based on their availability and proximity to the origin and destination.
-
Drivers are informed about the pending dispatch and can accept or deny it.
03
Challenges Addressed:
-
Understanding the complicated maintenance processes, the features, and the workflow
-
Understanding interactions across departments to cohesively address locomotive maintenance and repair.
04
Process
The goal was to complete all discovery up front (Research, Interviews, CJMs, Low-Fidelity Designs, Information Architecture, and User Testing) and secure buy-in from all critical stakeholders before transitioning the work to the Delivery Process.
Once in the delivery process, we would further refine the agreed-upon flow and designs from the discovery track to patch holes and expand on missing details.​
05
Design Considerations:
This process was done by working closely with the lead UI and backend developers to ensure what was created was feasible in an SAP-backed environment​
06
Outcome & Impact:
The outcome was a clear vision for the product before it ever reached the development team, and that work could be queued up in the backlog and picked up at a designated time with minimal churn.
We conducted a series of interviews with product owners, system operators, and mechanical crews to understand their roles and functionalities.
We then delivered detailed customer journey maps and personas to the PMO team, highlighting our findings and insights.
2. Reason codes
​
-
As mentioned above, reason codes are needed for exception work orders.
-
There’s a scroll with the entire list of reason codes
-
A reason code must be selected to complete the work order, which must all be completed for towing the locomotive..
Order fulfillment
A criticial and final phase in getting anything delivered.
Interestingly, there's an app to help it, and even more interestingly, I got to work on it.
3. Initiate
​
-
For towing to be initiated, each work order must be closed or exceptioned.
-
Once the appropriate selections are made, the towing will be initiated.
4. Complete work orders
​
-
Once the towing is initiated, the screen is disabled, and a modal pops up in the front for verification.
-
The modal confirms if the relevant work orders with their numbers are completed. To proceed, the user clicks Yes.
5. Override
​
-
Once the towing is initiated, the screen is disabled, and a modal pops up in the front for verification.
-
It also disables the other work order menu as the options are completed.
6. In-transit
​
-
With the work orders completed, the user must set the locomotive status to in transit.
-
He will need to update the reason code and the status date and time updates.
7. Reason codes
​
-
Similar to work orders, reason codes are needed to change the servicing of the state.
-
In this case, the reason code is set to Bad Order
8. Update
​
-
In-transit prompts an additional section for the destination shop with a section for comments​
-
Here the user can add the destination and his relevant comments for the towing process​
9. Complete
​
-
Updating the locomotive details now reflects the locomotive being towed.
-
The green modal signifies that the locomotive details are successfully updated.
Parting thoughts
01
The towing feature is one of the many features incorporated into this application to create a user-friendly interface.
02
It provides provisions to verify the work orders and provides a way to improve application efficiency.
03
The modals at various stages of the process verify that work orders are completed.
04
The buttons get enabled when relevant work order functions are complete, which emphasises consistent feedback to the user, making the interface more intuitive.
05
Additionally entire sections are blocked out after the relevant tasks within are completed.
A reasonable conclusion of why this interface makes sense.
A reasonable conclusion of why this interface makes sense.
9. Complete
​
-
Updating the locomotive details now reflects the locomotive being towed.
-
The green modal signifies that the locomotive details are successfully updated.
Project Dynamics
Team
Four/4 designers- I worked on several features but am showcasing this particular feature.
Client
A major freight and locomotive company with operations across North America-United States, Canada and Mexico.
Timeline
Built over a period of 2 months as part of an application build spanning more than a year.