Preparing your first Digital Employee means identifying a process owner, a bounded task, usable examples, authorised sources and an output that someone can check. You do not need to document the whole business. You need to establish what belongs in the first assignment, which exceptions return to people and who can accept the result.
Bring a piece of work to the first discussion
“We have a business system and receive a lot of email” describes the setting, but leaves the main question unanswered: what work do you want to delegate? Start with a request the team recognises. Trace how it arrives, who reads it, which information they retrieve and what they hand to the next person. Include steps currently explained in conversation: these may contain rules absent from the written procedure.
Choose a boundary that lets you inspect the result. “Prepare document requests for one team’s cases” is easier to assess than “manage customers”. Identify someone who can resolve conflicting rules as well as the people doing the work each day. Across several entities, establish which company owns the data and permissions rather than treating the group as a single archive.
How it works describes the service’s approach: understanding the process, making rules explicit and testing realistic cases before launch. Your business contributes working knowledge, available owners and review criteria; the exact assignment is agreed against the actual process.
A checklist to complete with the operational owner
Copy these questions into your project document. Beside each item, record the answer, owner and available evidence; use “to be clarified” where a decision is missing. You do not need to attach confidential data immediately: a description and synthetic examples may be enough for the initial discussion.
- Owner: who decides the process rules, and who provides cover? Record the role and the channel for involving them.
- Start and finish: what triggers the work and which deliverable completes it? Describe the exclusions too.
- Examples: do you have an ordinary request, an incomplete one and an ambiguous one? Record the result the team expects for each.
- Usable samples: who checks whether anonymised or synthetic examples may be shared? Examine attachments, filenames and notes as well; removing a name should not be assumed sufficient.
- Sources: where is the authoritative information, and who maintains it? Distinguish the current record from convenient copies.
- Rules: which criteria determine the prepared output? Include a borderline case that two colleagues might handle differently.
- Exceptions: when should work stop, and who receives the case? Specify the context they need to decide.
- Permissions: which reads, updates or communications are you considering? Name the person who can authorise them without putting credentials in the brief.
- Output and acceptance: which example result can you show the reviewer? List the conditions they must check.
- Availability: when can the operational owner, reviewer and IT contribute? Record dependencies and working windows, rather than just a preferred launch date.
A completed one-page assignment brief
This example is entirely illustrative. It concerns document collection preparation in a fictitious service business, rather than a customer or an already available configuration. The brief summarises decisions; any technical detail belongs in the supporting working documents.
Scroll the table horizontally to read every column.
| Field | Decision in this example |
|---|---|
| Assignment | Prepare document collection status for new cases belonging to Company Alpha; do not approve their contents. |
| Responsibilities | The Services co-ordinator decides the rules; the duty contact handles exceptions; IT assesses access. |
| Input and sources | A request with a case code, a dedicated folder and the co-ordinator’s approved checklist. Unidentifiable cases return to the contact. |
| Work to assess | Associate attachments, compare them with the checklist and prepare the status and a draft request for missing documents. |
| Exclusions | No access to other entities’ folders, contract changes, document deletion or communications sent without approval. |
| Exceptions | Two versions with no indication of the valid one, an unreadable attachment or a request outside the assignment: pause that step and show the references to the co-ordinator. |
| Expected handover | A list by case showing received documents, missing items, source references and the person responsible for the next step. |
| Acceptance | The reviewer can identify the correct case, open each authorised source and see omissions explicitly. No draft has been sent in the test cases. |
The brief is useful even when it reveals a problem before work starts. If nobody knows which checklist is current, for example, the next step is to identify its owner. Connecting another system does not fill that organisational gap.
What is needed now, and what can come later?
Assessing the first assignment requires a boundary, an owner, identified sources, examples and an expected result. Moving to tests with real data also requires actually authorised access and agreed controls. Give each outstanding question an owner and a verification step rather than hiding it to make preparation appear complete.
You can defer a perfect taxonomy, a more polished dashboard or expansion to every entity if these are unnecessary for the first result. Do not defer deciding who receives a blocked case. The ERP checklist helps IT investigate versions, interfaces and test environments without turning this brief into a technical specification.
What determines the effort and timing?
The effort grows when rules vary between sites, sources have different owners or the output needs several approvals. Obtaining usable samples and bringing together people who can make decisions also takes time. Naming an owner who has no availability does not resolve that dependency.
Agree small intermediate outcomes: a shared brief, reviewed test cases, checked access and a decision on the result. Record the time your team spends on preparation, review and clarification. The guide to pilot metrics explains how to include this in the assessment, while introducing the work to your team helps you organise participation. You can then start the discussion with a concrete assignment and clearly visible open questions.