To pass an invoice, complaint or service request on without anyone hunting for context, record the minimum the next person needs, name who takes the next step and show the status. A document is only useful once it becomes a case with a named owner.
An attachment lands in the shared inbox. Someone opens the file, reads a few details and forwards it with the question ‘what do we do with this?’. The second person searches for an earlier email, checks the spreadsheet or asks in the chat which customer it concerns. The document itself is accessible, but the work around it has not been handed over.
This is a common point at which to look closely at one specific type of document. Not to reorganise every process in the business, but to settle one simple thing: what the person taking over needs in order to do their step without rebuilding the context. A wider approach starts with one documented process. Here we focus only on handing over a document or request.
A document is not a case yet
A PDF, a form or a message with photos is only the start of the work. To become a case ready to handle, the team has to recognise its type, link it to the right context and name the next move.
A service request is a good example. It can arrive as a form, an email or a scanned document. Before the person planning the job receives it, they should be able to answer a few basic questions: which customer or machine it concerns, what has been described, when it arrived and whether there is material needed for the next assessment. If something is missing, it is not a ‘nearly ready’ request. It is a separate case that needs more information.
The same pattern works for other documents, without pretending they all look the same. An invoice might go to checking with the counterparty’s reference, the date received and the original file. A complaint might need to be linked to a customer, a description of the issue and the material the assessment will rely on. In each case the aim is not to make the decision automatically. The aim is to prepare a package that lets the right person make that decision at the right step.
Agree the minimum set before handing over
The minimum set does not need to be a detailed form or a long list of fields. It should answer one question: can the next person start their particular step? It is best defined for one type of document at a time, rather than as one universal form for the whole business.
Document → case
Three short steps.
- Document arrivesKeep the source.
- Check completenessEnough to work with? Missing → clarify.
- Create the caseLink the document to its owner.
The table below is an example of what such a package might contain. It is not a legal requirement or a ready-made template for every workflow. The fields need to be matched to the document and to how your team works.
| Package item | What should be visible | Example for a service request |
|---|---|---|
| Document type | What the team is dealing with | Service request |
| Case or counterparty ID | Link to the right case, customer or machine | Customer and equipment number |
| Date received | When the document was accepted | Date the form was received |
| Fields required for this type | Information needed for the next step | Description of the fault and where the equipment is |
| Attachment or original | The source file, or where it is kept | Photos and the request form |
| Completeness status | Whether the package can be passed on | Ready to pass on / details missing |
| Next step | Who takes over and what they do | Planning the service visit |
It is worth separating three messages that often blur together in one inbox: ‘not read’, ‘details missing’ and ‘needs a decision’. The first means the document is waiting to be recognised. The second means it has been checked but does not meet the conditions to move to the next step. The third applies to a complete package waiting for assessment by the named role. A blank field tells you none of these things. It leaves the person who opens the case later to guess.
In formal administrative processes there is a clear distinction between asking for missing information and passing a case on. A private business does not need to copy that process or its deadlines. The useful principle is simple: missing data should be a visible state, with a description of what needs adding, rather than an unclear handover.
Four states that keep handovers clear
For a single workflow, four simple states are often enough:
received → recognised and checked → ready for the next step
From the ‘recognised and checked’ stage there is also a separate, visible branch:
recognised and checked → exception to clarify → once completed: check again
Complete document?
Two routes, one loop.
Complete?
- NoClarify what is missing.
- YesMove on to the work.
Complete it and check the same case again, without opening a new one.
Received means the document has been accepted at the agreed entry point, but the team has not yet decided whether it is complete or who it belongs to. The source material and the date received should be visible.
Recognised and checked means someone has identified the document type, read the necessary details and compared them with the minimum set. It is not yet a decision about an invoice, a complaint or a service job. It is a check that the next person will get the information they need for their own work.
Ready for the next step means the package has an owner, the required fields and a clear note of who should take it on. For example, an invoice may be waiting for approval, a complaint for assessment, or a service request for scheduling. In this state the recipient should not have to search other channels for basic context.
Exception to clarify means passing it on now would be premature. This state is not an error in the process description. It is a deliberate place for incomplete, unreadable or unusual cases. The team can see why the package cannot move on and what needs to happen for it to return to work.
Microsoft Learn documentation describes an example approval workflow, in which a request goes to a named person and the decision and comment can be saved with the record.1 This is only an example of workflow mechanics, not a recommendation of a tool or a universal model. For your own process, keep one limited idea from it: next to the file, the state and the result of the previous step should be visible.
Hand over to a step, not to a general inbox
A handover is complete when it is clear not only where the document is, but also what the next piece of work is. In practice the note can be simple: ‘invoice check’, ‘complaint assessment’ or ‘plan service visit’. For each of these steps, name the role or person taking it on, the expected action and the input state of the package.
One case holds the whole context
- SourceWhere from?
- OwnerWho is running it?
- DeadlineBy when?
- Next stepWhat next?
Don’t hunt for context in four places.
This separates preparation from the substantive decision. You can read the details from a document, arrange them and attach them to the case, but the decision to approve an invoice, how to handle a complaint or the scope of a service job stays with the accountable role. That way, automation, if your business chooses to use it, can cover the preparation and handover steps rather than pretending to decide cases on its own.
Our process automation work may be relevant here. Discuss one specific document step, its entry point, its state and its exceptions, without assuming an integration or a result already exists.
An exception should not look like a closed case
An unreadable file, a missing customer identifier, a changed document layout, or missing information needed for further work should not disappear among routine handovers. If such a case is marked the same as a complete package, the next person either rebuilds the problem or leaves it without a clear next move.
A minimal exception note can have three parts: what is missing or unclear, who will clarify it, and what has to happen for the document to return to the normal flow. For a service request this might be ‘equipment number missing’, the case owner responsible for contacting the customer, and the condition ‘identifier added to the request’. For an invoice it could be an unreadable attachment, and for a complaint a lack of material that identifies the case.
Most importantly, the exception should not look like a closed case. The status should say that work has stopped for a specific reason, not that the document has been dealt with. Only once the details are added does the package return to checking and can then be prepared for the right step.
One check at the end of each day
At the end of the day you do not need a detailed report to check whether the workflow is clear. Three questions are enough: how many documents are waiting for completion, which are not yet attached to a case, and which have no next step named.
The aim is not to impose one response time or one metric on every business. Such a review helps you see your own state: whether documents stay at the point of entry, whether exceptions are described, and whether complete packages reach the right step. Only on that basis can you decide which part of the workflow needs tightening.
If you want to go through one real type of document, including its incomplete and unusual versions, book a free consultation (20 minutes). The conversation can start with defining the minimum set, the visible exception and the next step, without committing to changes across the whole business.
- Microsoft Learn: Create and test an approval workflow with Power Automate. The documentation is an example of one workflow model, not a recommendation of a product or a universal way to organise document workflows. ↩