Choose a Digital Employee provider by assessing a real process: the assignment, data, demonstrable output, integrations, controls and total cost. Ask for verifiable evidence and agree acceptance criteria before expanding the work. A persuasive demonstration alone does not establish whether the service fits your systems and responsibilities.
Before the demonstrations, give everyone the same brief
Selection becomes difficult when every provider answers a different question. Describe a recurring task, its frequency, the entities involved, the available sources and the output a person currently needs to check. Add two or three real exceptions, removing any information that does not need to be shared.
The CFO and Finance team define the outcome and the consequences of errors; IT assesses access and dependencies; procurement collects terms, exclusions and contractual responsibilities. Where privacy or legal expertise is needed, involve the relevant colleagues on the specific questions. Use the same assessment sheet for each proposal so that responses can be compared on evidence.
Establish the work and the data it requires
1. Scope: where does the assignment start and finish?
- Question
- Which steps are completed, which are only prepared and which remain outside the assignment?
- Evidence to request
- A workflow showing inputs, outputs, entities, exceptions and work assigned to people.
- The answer should clarify
- Who supplies each input and when the work counts as finished. “We handle invoices” does not establish whether the result is a collection of documents, a proposal or a posted entry.
2. Data: what is actually needed?
- Question
- Which data enters the process, where does it go and who can access it?
- Evidence to request
- A map of data flows, parties involved and proposed retention and deletion arrangements.
- The answer should clarify
- Which data is essential, which access needs approval and which information should not be shared. Ask the provider to explain any use of the data by third-party services.
3. Output: what result can we inspect?
- Question
- Can you show a complete result linked to the sources used to produce it?
- Evidence to request
- An inspectable example using authorised or synthetic data, with manual steps and limitations declared.
- The answer should clarify
- How the team will check the result in its own tools. A presentation or video does not replace inspection of the final document, status or case.
Check systems, permissions and quality
4. Integrations: what makes the proposed connection feasible?
- Question
- Have you checked our system, version and available connection methods?
- Evidence to request
- A list of available interfaces, prerequisites, restrictions and checks still to be completed.
- The answer should clarify
- What has been demonstrated and what needs development or authorisation. An ERP name on a slide does not establish compatibility; use the ERP integration checklist to explore the detail.
5. Permissions: who can approve work and stop it?
- Question
- Which actions require approval, and how is access revoked?
- Evidence to request
- A permissions matrix and a demonstration of a blocked action, an approval and the stopping procedure.
- The answer should clarify
- Who retains operational authority and who provides cover when they are unavailable. Permissions, approvals and error controls need to be tested against the agreed workflow.
6. Quality: how do we decide whether the result is acceptable?
- Question
- Which criteria allow our team to accept or reject the output?
- Evidence to request
- Representative cases, expected results and a record of observed errors.
- The answer should clarify
- Which defects prevent launch, who judges ambiguous cases and which checks are repeated after a change. An overall quality figure is useful only when its sample, method and limitations are explained.
7. Errors: what happens when a step fails?
- Question
- How are missing data, duplicates and operations with uncertain outcomes handled?
- Evidence to request
- An exception test showing notification, ownership and a check of the recovery outcome.
- The answer should clarify
- Who sees the problem, what stays on hold and who authorises a restart. Also ask how the outcome is reconstructed if the destination system does not return confirmation.
Assess the agreement for the life of the service
8. Cost: what does the quotation include?
- Question
- What are the setup charge, recurring fee, included limits and any additional charges?
- Evidence to request
- A quotation stating assumptions about volumes, entities, integrations, support and changes of scope.
- The answer should clarify
- What changes the spend and which tasks remain with the internal team. Use the Digital Employee cost guide to compare equivalent items and avoid counting a charge twice.
9. Support: who helps after launch?
- Question
- How do we request support, and what happens when a connected system changes?
- Evidence to request
- Channels, coverage, priorities, any contracted response times and the allocation of maintenance work.
- The answer should clarify
- The difference between acknowledging a problem and resolving it, who provides updates and which changes need a new estimate. Software availability does not itself establish round-the-clock support.
10. Accountability: who is responsible for each step?
- Question
- Which duties belong to our business, the provider and the other parties involved?
- Evidence to request
- The contracting entity’s identity, operational responsibilities, third-party dependencies and applicable contractual terms.
- The answer should clarify
- Who approves the scope, who manages incidents and who handles a dispute. The brand, product and contracting company should not be confused.
11. Portability: which materials can we reuse?
- Question
- Can we export data, outputs and operating documentation, and in which formats?
- Evidence to request
- A sample export and a list of available materials, with any restrictions on their use.
- The answer should clarify
- What the business can read or transfer and what depends on proprietary components. An archive of files does not demonstrate that another system can take over the process without further work.
12. Exit: how does the team take the work back?
- Question
- How is the service ended while keeping outstanding cases visible?
- Evidence to request
- Termination terms and a procedure for handover, access revocation, deletion and work in progress.
- The answer should clarify
- Notice, any applicable charges, handover responsibilities and final checks. Exit arrangements belong in the discussion before the service starts.
Third-party dependencies and decommissioning also appear in the NIST AI RMF 1.0, GOVERN 6 and GOVERN 1.7. They are matters to assess throughout the lifecycle, rather than automatic proof of a provider’s compliance or certification.
Finish the selection with a bounded assessment
Propose an assessment of a defined process, using authorised data, an expected output and agreed acceptance criteria. For document collection, illustrative criteria might be that each document is linked to the right case, missing information remains visible and requests outside the assignment reach the designated person. These are example criteria, not a promise of a free trial or a particular launch date.
Agree who will assess the result, which defects require correction and what authorises the next step. A successful result applies to the scope tested: adding entities, sources or write actions means reviewing the conditions again.
To apply these questions to our offering, start with how the Digital Employee service works and bring a real process to the discussion. A useful decision rests on a clear assignment, inspectable evidence and responsibilities accepted by the parties.