From Triggers to Tasks: A Guide to Efficient Work Dispatching in Operations

Have you ever wondered what makes the most efficient teams tick like clockwork? It all starts with understanding two game-changing concepts: triggers and dispatching.

What is a trigger?

Every process needs a starting point—something that kicks things into gear. This is what we call a “trigger.” It’s like the spark that sets the whole process in motion. Without a clear trigger, your process just sits there, waiting for something to happen ; or worse, it can start without any need to start.

Example: In our bakery, the trigger could be a customer placing an order for a dozen croissants or getting the morning batch ready to refill the display case. For our tech support company, the trigger might be a customer submitting a support ticket, asking for help with a problem. These triggers tell the team, “Hey, it’s time to get to work!”

Types of triggers

Triggers can come from all sorts of places, depending on the kind of process you’re dealing with.

• Customer-driven:
  Actions initiated by customers, such as placing an order or submitting a support ticket.
• System Alerts:
  Automated triggers based on anomaly detection, error alerts or low stock notifications.
• Internal team requests:
  Initiated by another team member of departments, such as assigning tasks. Escalation, de-escalation and double checks fall in that category most of the time.
• Scheduled events:
  Recurring tasks that are set to start at a specific time, like daily inventory checks or monthly updates.

Example: In the bakery, a scheduled task might be to start baking the first batch of croissants at 5 a.m. every day. A customer-driven task could be when someone places an order for a dozen croissants. An internal team request might be the owner asking the bakers to prepare a special batch for an event or requesting a daily sales report. Meanwhile, a system alert could be an automatic notification that the stock of flour is running low, prompting a restock.

Choosing the right trigger

Updating the trigger could be the first way to improve a process. For example, moving from an asynchronous trigger, such as a scheduled event, to a real-time trigger can have a tremendous impact.

Example: Every morning at 8 am, an ops manager exports customer cases for the team to handle that day. As new cases are assigned, agents must check updates since the export. For instance, starting a case at 2 pm requires verifying payments made between 8 am and 2 pm on another platform. While each check takes seconds or minutes, with 2,000 cases daily, the time adds up significantly.

Priorities

Not all tasks are created equal—some need to be handled right away, while others can wait a bit. This is where prioritization comes in. Before tasks are dispatched, it’s crucial to set their priority so the team knows what needs to be tackled first.

Example: In tech support, a system alert about a server issue might be a high priority and get handled immediately, while a routine request for a password reset might be less urgent. In the bakery, a large catering order due in a few hours would take priority over preparing the standard morning batch.

Setting priorities helps avoid situations where an important task gets forgotten in a backlog or a low-priority task eats up time that should have been spent elsewhere.

Dispatching work

Once the trigger goes off, it's time to get the work to the right person or team. This is what we call dispatching.

Let's go back to our Customer Support example. The trigger is customer-driven: it's when a customer sends an email to the support address. How is the choice of operator determined?

The first type of dispatch is the manual dispatch: when a new alert is done, an operator is in charge of dispatching the customer requests.

Each time there's a new alert, they receive a notification and they assign, based on parameters they know.

It's cumbersome for the dispatcher, so what we're often seeing in our customers is the batch manual dispatch. Every morning, someone is in charge of dispatching all the tasks done in the previous days to the available operators.

In that example, Bill assigns the new customer request to Jane, because her queue of work is smaller than Anna and John.

Word of caution. Manual dispatch creates bottlenecks. For example, Bill’s queue can become overwhelming, slowing everyone down. Batch manual dispatch helps address this, as we’ll see later.

The second type of dispatch is the automated dispatch: the manual work is automated based on a set of rules. For example, all customer requests about invoicing and billing are dispatched to the billing team, the ones about renewals to the legal team and all the rest to the support team.

In this example, Anna automatically gets the new customer request because her work queue is smaller than the rest.

There is a third type that is a mix of the previous two, the hybrid dispatch: you can automate part of the dispatching, but there will be some manual dispatch. Let's consider the biggest customer who reaches out with questions on the general support channel. He will not be automatically dispatched, and the manager will manually direct them to the right person.

One type of hybrid dispatch is the on-demand dispatch where tasks are being dispatched on the fly, in real time, automated in some ways but human-controlled most of the time.

Dispatching moment

In the previous examples, we saw the dispatch being done directly when the trigger happens, and added to an operator's queue, waiting for them to tackle this task.

This can lead to issues: if this task is of high priority, but the previous task in the operator workload is taking longer than expected, then it will negatively impact the lead time. Or if someone is suddenly sick and unable to work and has a backlog full.

Another way is to delay the dispatching to when an operator is available. That way, the task is dispatched when it can be done.

In that case, John is available: either because his backlog is empty or because all his tasks are blocked. He can ask for a new task, and the dispatching mechanism can happen at that moment.

In real-life scenarios, it's usually a mix of both: the automated dispatching when an agent is available, but some manual dispatching.

Common Dispatching Logics

When it comes to getting tasks out to the right people, there are a few tried-and-true methods:

Round Robin

This one’s all about keeping things fair. Work gets handed out evenly, so everyone gets their turn, and no one ends up overloaded. This ensures equality of volumes.

Example: In a support team, every new ticket is automatically assigned to the next available agent in a rotating sequence, ensuring all agents handle a similar number of tickets.

FIFO (First In, First Out)

Tasks get tackled in the order they come in, so the oldest tasks get done first.

Example: A customer submits a support ticket at 8 a.m., and another at 8:15 a.m. The team processes the 8 a.m. ticket first to ensure customers who reach out earlier aren’t left waiting unnecessarily.

LIFO (Last In, First Out)

It's the opposite of FIFO - the newest task gets handled first, pushing older ones back.

We've also seen teams switching every day between FIFO and LIFO to reach their KPIs.

Common Dispatching Logics

Redispatch refers to the process of reassigning a case that has already been initially dispatched. For example, an agent begins working on a case but is unable to complete it—whether due to workload constraints or unexpected unavailability.

Redispatch is not the same as escalate. Escalate means the ticket is assigned to a different team - whereas redispatch is another agent from the same team who will be assigned to this ticket.

Capacity limit

Redispatch refers to the process of reassigning a case that has already been initially dispatched. For example, an agent begins working on a case but is unable to complete it—whether due to workload constraints or unexpected unavailability.

If you aim for equality of volume, one of your operators can be overloaded with tasks, the next one being dispatched before they finish their previous one.

In that case, you could implement a capacity limit: an operator can only have a certain number of tasks on their backlog.

Unexpected unavailability

If one of your operators has started working on a subject but is suddenly incapacitated to finish it - the usual case is a sick leave, you may want to redispatch after a while. We strongly recommend our customers to implement a redispatch after feature. If the task takes too long to close or nothing is done on this account, it should be redispatched to another agent.

These two automations are game-changers to help you close tickets faster, and ensure you keep your KPIs.

Why does it matter?

Dispatching logic impacts the overall experience. When work is dispatched efficiently, everything moves faster, with less stress and fewer errors. Tasks don’t pile up, and the right people handle the right jobs, making it easier for the whole team to stay on track. Plus, when you have a clear system for dispatching, it’s easier to spot problems early and fix them before they turn into bigger issues.

We will see in later lessons how dispatching impacts the overall performance of a process.

Curious to learn more? Download this free ebook and learn everything you need to know about customer operations.

Go to Class 4: Getting Work Done.