Introduce a Digital Employee by explaining which work you want to change, involving the people doing it and making responsibilities, workload and open decisions visible. Listen to concerns without promising that roles or jobs will remain unchanged. The first discussion should produce an understandable assignment and a practical way to report and investigate problems.
Start a discussion about the work that will change
If you present the project solely as a way to “free up time”, practical questions remain unanswered: who will check the outputs, which activity will come off the schedule and how will that time be used? Before the meeting, separate the project’s objectives from organisational decisions already made and those still to be taken.
You can explain that you are assessing a bounded task without suggesting that this makes concerns about roles irrelevant. If staffing or assignment decisions exist, communicate what you can with the relevant decision-makers. If they have not been made, identify the open question and who will address it. An explicit uncertainty is more useful than a guarantee you cannot keep.
The starting question is not “how do I convince everyone?”, but “what would make this change understandable and testable for the people doing the work?”. The guide to people, digital delegation and mixed teams helps distinguish a decision about work from an abstract comparison between people and software.
Involve the people who know the awkward exceptions
Ask those doing the work to bring an ordinary case, one that needed clarification and one poorly explained by the written procedure. Have them include calls, informal checks and corrections: these are real work, rather than noise to remove from the diagram.
Invite the people receiving the output as well as those preparing it. A list that is quicker to produce could take a colleague longer to review. The reviewer needs an opportunity to explain which sources and context they require; the manager must be able to narrow the first assignment when those conditions are unavailable.
Do not ask people to contribute as an additional task with no room in the schedule. Identify which activities will be replanned to allow for examples, testing and training. The first-project preparation brief turns these observations into responsibilities and questions to resolve.
A 45-minute agenda for the first meeting
This illustrative agenda should be adapted to your team’s situation. Its timing covers the meeting, not project activation. Share a short process description beforehand and provide a way for people to raise questions privately with the manager if they prefer.
Scroll the table horizontally to read every column.
| Suggested time | Topic | What the team should leave with |
|---|---|---|
| 5 minutes | The manager explains the problem, objective and decisions already made. | A clear separation between confirmed decisions and open questions. |
| 10 minutes | The people doing the work trace a case and the current workload. | Visible steps, including informal work and review. |
| 10 minutes | The team discusses exceptions and unacceptable results. | Cases to test and situations in which the process must stop. |
| 10 minutes | The manager, reviewer and IT clarify roles and support. | Who approves, who answers a problem report and how work continues while it is pending. |
| 5 minutes | Concerns and unresolved decisions are collected. | An owner for each question and an agreed opportunity to update the team. |
| 5 minutes | Preparation, training and the next discussion are agreed. | Assigned tasks with room in the schedule and criteria for reviewing them. |
Finish with a short record that the team can correct. The meeting does not demonstrate unanimous agreement or replace decisions that belong to management. Its purpose is to avoid everyone leaving with a different understanding of the assignment.
Questions you need to answer as the manager
- Precisely which work is changing?
- Name the tasks, inputs and handover. If you are still choosing the process, say so; do not present an already decided solution as an open consultation.
- Who will perform the additional checks, and with what time?
- Identify the role, arrange cover and show which other work will be replanned. Do not assume that people can fit supervision around their existing workload.
- What do we know about roles and staffing?
- Separate approved decisions, possibilities and undecided matters. For open questions, identify the decision-maker and when they will return to the discussion without promising an unknown outcome.
- How will we use the trial’s data?
- Explain which process data you will collect, who will see it and which decision it supports. Clarify whether it also concerns individual work; do not let a process measure implicitly become a judgement of people.
- What happens if I report an error?
- Define a channel, the minimum context to supply and the person who responds. A report should lead to investigation and a visible outcome rather than a request to trust the system.
- Who can suspend the work, and how does it restart?
- Describe operational authority and controls and the temporary route while the issue is examined. Explain which actions remain prohibited during an interruption.
An example that does not conceal uncertainty
Imagine a co-ordinator planning to delegate preparation of document requests. A colleague asks, “If it works, what happens to the time I currently spend on this?”. An illustrative answer is: “During the trial, I’m asking you to review drafts and report exceptions; we will replan the other work needed together. We have not yet decided how to redistribute the workload after the trial. That decision belongs to the function manager, and we will discuss it at the agreed review, including the time spent checking outputs.”
That answer is appropriate only if it accurately describes the situation. Do not copy it to conceal a decision already made. The manager’s task is to connect words with something people can check: capacity for the trial, a named owner and a subsequent update.
Provide practical training and review the impact
Training should let people practise an ordinary review, an exception and a stop: consulting sources, rejecting an output and asking for help. Check that the colleague can perform the required steps rather than treating attendance at a presentation as sufficient. Training for assigned roles and collecting feedback are addressed in GOVERN 2.2 and GOVERN 5 of the NIST AI RMF 1.0.
At the next discussion, examine preparation and review time, waiting exceptions, interruptions and difficulties reported by the team. The pilot metrics help you interpret results beyond the tasks performed by software. If the workload has simply moved to another colleague, revise the workflow before expanding it.
How it works explains assignments and human handovers within the Digital Employee service. Decisions about the organisation of work remain with your business. The project should make how those decisions are made and checked clearer, rather than covering them with a technological promise.