Find the moment a request loses its owner
A training enquiry arrives successfully. The form shows a confirmation, the inbox contains the message and the CRM has a record. Three days later, nobody has replied. Every individual technology appears to work, but the service has failed at the handoff.
This fictional example illustrates a common investigation question: what proves that responsibility moved to the next person? Receipt and ownership are different facts. A notification may tell several colleagues that something happened without making any of them accountable for the response.
Reconstruct the actual sequence
Choose a recent representative case and write its events in order. Record when the request arrived, where it appeared, who first saw it and what happened next. Use the evidence available rather than rewriting the sequence to match the documented procedure.
In the example, the coordinator assumed the course manager would answer because the enquiry concerned prerequisites. The course manager assumed the coordinator would arrange a call. The record remained marked “new”, which described its origin but gave neither person a useful instruction.
Identify the decision that has no owner
The missing step is not necessarily another reminder. Somebody needs to decide whether the enquiry can be answered directly, requires course-manager input or should be declined. Each route needs a responsible person and a state that the team can interpret.
The organisation might agree that the coordinator owns the request until another named person accepts it. Alternatively, a triage role might assign work explicitly. The right rule depends on the team. What matters is that responsibility does not disappear during a transfer.
Test absence and disagreement
Suppose the usual course manager is away. Does the request remain with the coordinator, move to a substitute or wait with an honest explanation to the customer? If two people both answer, is that harmless duplication or a risk of conflicting commitments?
These cases reveal whether the process relies on a particular colleague's memory. A shared queue can help, but only if its states and actions reflect the agreed responsibility. Renaming an inbox folder “workflow” will not settle the rule.
Choose one change to evaluate
A first improvement might add a named owner and a deliberate acceptance step to the current tool. It might instead change the intake questions so routine enquiries can be answered immediately. Avoid introducing several changes at once if that makes it impossible to understand what helped.
For a limited comparison period, record requests with no owner, time spent identifying responsibility and cases that received conflicting replies. Define the measures before reviewing the result. Do not claim that a shorter response time was caused by the change if volume or staffing also changed materially.
Carry the rule into the handover
The operating notes should explain how an item is assigned, how absence is handled and who resolves an unclear state. A new colleague should be able to recognise work that is waiting on the customer separately from work waiting on the organisation.
If development is needed, the acceptance example should follow one request through transfer, absence and completion. The CRM integration service can address record movement, while project planning helps assign the decisions. The software should make the agreed ownership visible, not invent it.