A request reaches your inbox, a colleague starts work and the customer later asks for something the team never recorded. A shared assignment record gives the people handling an enquiry one place to check the task, responsibility and acceptance conditions. This guide follows a service request from its first message to an accepted result. Use the blank fields and transition rules as a starting model for your own team.
1. Separate an enquiry from an agreed assignment
An enquiry says that someone wants help. It does not establish the scope, delivery date or person responsible for producing a result. Before assigning work, record what the customer needs, what the team will deliver and which questions remain open.
Use one identifier from the first record onward. Put the identifier in internal handovers so a change of colleague does not create an unrelated second task. Keep the customer's original request available to the people who need it, with access appropriate to their role. Do not copy personal details into a demonstration record.
The example throughout this guide is fictional: a service team is asked to prepare a monthly project summary. It illustrates a way of organising work, not a measured case or a contract template.
2. Give the assignment a compact record
Create the record in an existing tool before choosing a replacement. These fields define what the next person needs to accept responsibility.
- Assignment ID and date received.
- Requested outcome and the agreed deliverable.
- Included work and explicit exclusions.
- Required inputs, their location and any missing item.
- Current owner, next action and person receiving it.
- Agreed delivery date, or a clear statement that the date is unconfirmed.
- Acceptance conditions and who will check the result.
- Current state and a dated history of material decisions.
For the fictional summary, the deliverable is one document containing the agreed reporting period, completed activities and unresolved decisions. The inputs are the project notes for that period. The customer asks for the document, the coordinator prepares a complete assignment and the delivery colleague produces it. Choosing this record does not require a specific CRM or a paid subscription.
3. Define states through their exit conditions
The label alone does not tell a colleague whether to act. Pair each state with an owner, an exit condition and the record that confirms the transfer.
Scroll sideways to see every column.
| State | Owner | Condition for moving on | Record to keep |
|---|---|---|---|
| Received | Coordinator | The request has an ID and a person checking it | Receipt and next action |
| Clarification | Coordinator | Scope, inputs and open questions are recorded | Answers and missing items |
| Awaiting agreement | Coordinator | Relevant parties confirm scope, delivery and acceptance conditions | Dated agreement reference |
| Ready for delivery | Delivery owner | The colleague explicitly accepts the assignment | Acceptance or a reason for return |
| In progress | Delivery owner | The defined result is available for checking | Result location and outstanding exceptions |
| Awaiting acceptance | Named reviewer | The reviewer accepts the result or identifies a mismatch | Acceptance or correction request |
| Closed | Coordinator | Acceptance and the final result are recorded | Final reference and closure date |
| Cancelled | Current owner | The cancellation decision and effect on ongoing work are recorded | Decision, unfinished work and owner |
This is an operational model. It does not replace an agreement with the customer, determine legal rights or set payment conditions.
4. Make acceptance of the handover explicit
Sending a message is not the same as transferring responsibility. The coordinator sends the assignment reference and the delivery colleague either accepts it or returns it with the missing items. Until acceptance is recorded, the coordinator remains responsible for resolving that handover in this model.
For the fictional summary, the reporting period is initially absent. The delivery colleague returns the assignment with one question: which period does the customer want? The coordinator records the answer and resubmits the same assignment. The history shows the return and the later acceptance; neither event is hidden by a new task ID.
Separate the date on which a colleague accepts work from the date by which the customer expects delivery. Recording both prevents an internal handover deadline from silently becoming a customer commitment.
5. Handle changed scope without rewriting history
Suppose the customer also asks for a presentation after the summary has started. Record that request as a proposed change. Identify who will decide whether it belongs in the assignment and how it affects the deliverable, required inputs and delivery date.
Keep the previous agreed version and the recorded decision. Do not replace the original scope with the new request and then assess the colleague against the rewritten record. If agreement has not been reached, keep the change visibly pending and state which work continues under the existing scope.
For a cancellation, record who requested it, who confirmed the decision, what work has stopped and where the unfinished result is held. Cancellation is a separate state; it is not successful acceptance. Any contractual or financial consequences require their own agreed treatment outside this workflow guide.
6. Check the result against the recorded conditions
Acceptance starts with the conditions recorded before delivery. In the example, the reviewer checks the reporting period, required sections and availability of the agreed source material. A request for a different deliverable is handled as a scope change, not silently included as a defect in the original summary.
Keep a link to the accepted version and a dated acceptance record. If a correction is required, describe the mismatch and the next action rather than writing only “not ready”. Name the person responsible for producing the correction and the person checking it again.
Do not mark work accepted simply because an internal target date passed. If the reviewer has not responded, keep the actual state visible and agree on a follow-up action. This guide does not create an automatic acceptance rule.
7. Try the model with exceptions before extending it
Use synthetic requests to test the record. One request lacks a reporting period, another receives an extra deliverable after agreement, and a third is cancelled after work begins. Trace who owns each request, what information is missing and which record permits the next transition.
Then try the model on a limited, defined type of real work with appropriate access and existing records preserved. Track the points at which people still need an explanation outside the record. The aim is to find incomplete instructions and unclear ownership; no reduction in errors is claimed without an actual measurement.
8. Connect the handover to the wider process
The first-month workflow plan explains how to choose a boundary, collect baseline records and review one change. The cloud-service size-group study provides a separate statistical view of tool adoption. Buying a tool does not establish that an assignment has a clear owner.
EIS describes digitalisation in terms of developing business processes with information technology. The record and state model here are the publication's practical framework, not a mandated EIS procedure. The guide covers delivery and acceptance; invoicing, bookkeeping services and statutory records remain outside its scope.
9. Source and next action
- EIS: Digitalisation, checked 3 November 2026.
- Start with one recent type of request. Fill the eight fields, identify the first missing input and ask the next person to accept or return the assignment explicitly.