When one department finishes its work, that doesn't yet mean the next one has a task assigned. Between the status "sale closed" and the start of implementation, it has to be clear what triggers the next step and who is responsible for it.

Take a simple example: a company sells a service that needs implementing. The salesperson signs the contract, records the agreed scope and contact details in the CRM and closes the sale. Every condition for starting the implementation is met. A few days later the customer asks when the work begins, and the implementation team doesn't have the case on its list. From the board's point of view the sale is done, and the delivery has nobody assigned to its first step.

That doesn't have to mean the salesperson slipped up or the implementation team is overloaded. It may be that the company never defined when the next task should be created, who it should go to, and how to tell it has been picked up. Before anyone starts improving communication between departments, it's worth checking whether the next piece of work was ever handed to anyone at all.

Information, a task and ownership are three different things

Three moments are worth telling apart:

• The information arrived. The implementation team knows about the signed contract, but that doesn't yet say what task it's supposed to do
• The task exists. A specific activity has been defined and made available to the right person or the team's queue
• Ownership has been taken. It's known who will carry out the next action, for example because the task was assigned to them by name, or because they picked it up from a shared queue

A task can be correctly routed to a queue while nobody has picked it up yet. On the other hand, if the company assigns tasks directly to named people, that assignment may already establish ownership. Don't add a mandatory confirmation just so the system has one more status. The distinction between the people entitled to take a task and its actual owner is familiar from task management models too.

With a small number of cases, an email can be enough, as long as it names a specific task and a recipient, and the company can tell who is responsible for responding. Sending the information, though, is no proof that the next piece of work has been accepted.

When can the next stage begin?

In the example above we assume the data is complete. In other cases a signed contract alone may not be enough: starting the implementation may require an approved scope, a contact person or additional kick-off data.

So you need to separate the event that triggers the check from the conditions that allow the work to be handed over. If the required scope is missing, the right decision may be to hold the implementation and name the person who fills the gap. Not every case that failed to move on has been lost.

A status in the CRM can trigger the next task perfectly well, provided the company has agreed what it means and what conditions apply. The problem isn't the status itself. It's a missing rule, or a rule that doesn't do what it should. As the first part of this series showed, a status in a system means only what the company decided beforehand it should mean.

Six points for one handover

The process owner can describe a critical transition with a step handover card, a simple working tool proposed by Codino. It isn't a formal standard. The card helps the company agree exactly what has to happen between the end of one stage and someone taking ownership of the next.

The deadline in the last row is an example, not a universal norm. Each company sets it according to how much the handover matters. Separately, it should name the owner of the rule, responsible for keeping it current.

Six points don't mean six new statuses in the CRM. If a task goes straight to a specific person and, under the company's rules, that means they own it, a reliable record of the assignment is enough. With a shared queue, you need a way of telling who actually took the work. Taking the task is not yet the same as delivering the implementation.

How to find where a case stopped

The card describes the agreed way of working. When a particular case doesn't move on, you still need a diagnosis of what actually happened.

The conditions weren't met. If required data or a decision is missing, the task shouldn't have been triggered early. Name the gap and the person responsible for closing it.

The conditions were met, but the task never appeared. First establish whether a rule exists that creates the next task. If not, the process owner has to define one. If it exists but didn't fire, check how the rule runs in the system. This may not be a collaboration problem between departments at all.

The task appeared, but went to the wrong recipient. The assignment, the queue or the rule for choosing the assignee is wrong. Fix the routing rule.

The task reached the right queue, but nobody picked it up. Check who was supposed to respond and by when. If the cause is an overloaded team, the handover rule itself may be fine and the problem is capacity.

If the task already has the right owner and the work still isn't moving, don't automatically call it a handover failure. The causes then lie further along in delivery, for instance in the gaps between activities the previous part was about.

What exactly should the board get?

To start with, it's enough to check one important transition on a handful of real cases. The result should be a completed card and a short note: which condition or responsibility wasn't met, what that conclusion rests on, and who is responsible for the next step.

An example result for the case from the beginning of this article:

Contract signed: yes. Scope and kick-off data: complete. Task for implementation in the agreed queue: not found.

Conclusion: the required task was not found in the agreed queue. It isn't known yet whether the task was never created or was created and sent somewhere else.

Next decision: the process owner checks whether a rule for creating the task and the right recipient has been defined. If it has, IT establishes whether the task was created and where it went. If there is no rule, it has to be agreed first.

This is a hypothetical example. It shows why a missing task in the expected place is an observation, while a missing rule, misrouted work or a rule that didn't fire are different possible causes. One case can help you tell them apart. It doesn't yet say how often the problem occurs across the company.

It's also worth testing a case where the conditions for the next stage aren't met, and one where the task correctly reached the queue but was never picked up. That tells you whether the process can start work, hold it deliberately, and react when nobody owns it.

Only after a check like that does it make sense to decide whether a procedure and an email will do, or a feature of the existing CRM, or a simple automation. Salesforce's documentation shows that a CRM can trigger actions after a given event once conditions are met. But the technology won't decide for the company when the next task is supposed to be created.

When one department has finished its work, the board should be able to establish not just who was notified, but who was given which next action. Without that, the problem can stay invisible until the customer asks when the work is going to start.