Dispatch Hub Call Transfer

Product Designer

1 month

What is Dispatch Hub?

Zello Dispatch Hub is a centralized push-to-talk dispatch platform that helps dispatchers support the frontline faster. 


One of the key use cases of Dispatch Hub is drivers calling in dispatchers for help. Ideally, the first dispatcher that answers the call is able to assist,

however, that is not always the case.

Previously, if dispatchers could not help, they had no choice but to end the call and ask the driver to call again so they can be placed back in the pending calls list.

Over a couple of weeks, I explored explorations, iterated high-fidelity prototypes, and went through multiple rounds of internal x-functional critique sessions to land on the final design.

Previous User Flow

Dispatcher accepts a call from pending

Dispatcher ends a call w/o help

This was a huge pain point for our users when dispatchers could not offer assistance during the initial call. It resulted in dispatchers and drivers repeatedly calling and hanging up until they successfully connected with the appropriate counterpart.

Key Areas of Focus

Based on customer calls, user interviews, and general feedback, we decided to focus on these key areas:

  1. Allow users to send calls to pending

  1. Allow users to transfer calls to another dispatcher

    a. On the dispatcher’s receiving end, have them accept/acknowledge the call

    b. On the driver’s side, give them feedback that their call was transferred to another dispatcher

Iteration Explorations

In the early stages of my exploration, I tried many different approaches and shared these early iterations with the design team and the product manager:

Success and error states

  • Placement

  • Toast vs. banner

  • Tooltips

Copy explorations

  • Modals

  • Headers

  • Subtitles

Initially, we considered implementing a feature that would allow dispatchers to leave each other messages (audio or text) when transferring calls. However, due to that feature increasing scope and our desire to first validate if our users would actually use this feature, we decided to simplify the flow by completely removing this step.

Since the Dispatch Hub platform is responsive, it was important to keep in mind how content would scale at different screen sizes and adjust components based on screen size.

Feedback Sessions

Due to time constraints and limited resources, I did not have a chance to hold external user interview sessions but had the opportunity to have internal x-functional critique sessions, where I shared my explorations with other designers, product managers, and engineers. In the end, we were able to come up with a solution that everyone agreed on.

After the last round of iterations, the product manager of the project let me know that after a discussion with engineering, implementing one of the solutions would take a significant amount of work. I had to make a quick pivot, but in the end, was able to come up with a solution that everyone agreed on.

Transfer Call Back to Pending

Pending active call user flow

More options

Select dropdown

Loading state*

Moved to pending

Dispatchers are now able to move an active call to pending and confirm that the call was moved back to pending successfully.

*The loading state isn't necessarily part of the flow, but a state to handle longer loading times.

Other screens

Error state

History screen

In addition to the primary user flow, I also had to take into account other screens and scenarios. For example, I considered how the system would handle errors and what the display would be like on the history screen when a call was successfully moved back to the pending status.

Transfer Call to Another Dispatcher

For transferring the call, there are two distinct flows: sending and receiving the call.

Sending call user flow

More options

Select dispatcher

Confirm transfer

Successfully transferred

The process of transferring a call to another dispatcher follows a similar flow to moving an active call to a pending state. However, in the case of transferring, we introduced a confirmation modal that requires the user to confirm their action. We implemented this additional step to prevent errors and provide a clear decision point. Once a dispatcher selects "Confirm Transfer," they lose control over the transfer.

Other screens

Transfer unavailable

Error state

History screen

Again, similar to pending active calls, I had to consider additional states such as errors, history screen, and what would happen if there were not any dispatchers to transfer calls to.

Receiving call user flow

No calls

Successfully transferred

Initially, we considered having the dispatcher receive a list of "transferred calls" that they could choose to accept or put back in pending. However, implementing this solution would require additional effort from the developers, and we realized that it did not address the original problem. If the dispatcher didn't accept the call, the drivers would still be stuck in a pending state.

To streamline the solution, we made a few changes. We now only allow dispatchers without any active calls to receive transferred calls. Additionally, I utilized an existing component to highlight the cell and replace the subtitle with a description indicating who transferred the call.

Two-panel view for successful transfer

Select dispatcher

Successfully transferred

On larger screens that have two-panel views, I employed modals to display user lists and confirm critical actions. However, I made a conscious effort to minimize the use of modals whenever possible, as they have the potential to interrupt users' primary workflows.


After a month of release, we had 26% of networks with five or more dispatchers use this feature - the goal we had originally set was 20%.

It also improved the time drivers got answers by 30%.