Building in-house makes sense when you have the skills, ongoing capacity and a clear reason to control the solution. A managed service may cover work you prefer to entrust to a provider, provided it is defined in the contract. A mixed model divides responsibilities. The decision must include testing, maintenance, support and an exit route, as well as a successful prototype.
The prototype works. Who maintains it from tomorrow?
Your team demonstrates a convincing result using a few documents. That is a useful step, but the business decision also depends on what you have not yet seen: an incomplete document, a temporarily unavailable source, a change to the business system and the absence of the person who built the workflow.
The choice concerns who designs and maintains the solution. You can develop it in-house, purchase a managed service with a defined scope or divide the work. Every option still needs an internal process owner, acceptance criteria and someone to intervene when behaviour changes.
Consider an illustrative example: the prototype reads a due date from an export. Following an update, the field name changes. Who detects the problem? Who stops an incomplete result being used? Who updates the data handling, repeats the tests and authorises a restart? Concrete answers matter more than a general promise of a “ready-made” solution.
What the three models require
In-house development. Your team builds and runs the process using technologies selected by the business. This makes sense when the process is distinctive, the skills are available and you can assign ongoing capacity to its development. One person's availability for an experiment does not establish that you have a team for a continuing service. Check who covers their absence too.
A managed service. You entrust a provider with the design and management activities included in its proposal. This may suit you when you want a point of contact for that work without organising every activity internally. Establish what is actually covered: maintenance, monitoring, changes and support may have different limits or conditions. The word “managed” does not assign every responsibility.
A mixed model. Your internal IT team might maintain data access while a provider configures part of the process. This can make good use of existing skills, but it needs a documented boundary. If data retrieval fails, both parties must know who makes the initial diagnosis and who coordinates recovery. Two contacts without an owner for the problem add handovers rather than coverage.
Complete the matrix with evidence
Record a name, document or demonstration for each row. Do not award scores from one to five: an essential responsibility without an owner does not become acceptable because other rows score well. Use the same process and criteria for all three options.
Scroll the table horizontally to read every column.
| Verifiable question | In-house development | Managed service | Mixed model |
|---|---|---|---|
| Who has the skills and capacity? | Name the technical owner, cover and allocated capacity. | Ask about available roles, scope and support arrangements. | Record which skills each party provides and who coordinates. |
| Who accepts the working process? | Record test cases and approval by the process owner. | Include the same cases and criteria in acceptance testing. | Define an end-to-end test as well as tests of individual components. |
| Who detects and handles an error? | Check alerts, their recipient and the recovery procedure. | Ask what is monitored, who intervenes and what response times are agreed. | Agree initial diagnosis, handover and ownership of the problem. |
| Who updates integrations? | Assign technical access and maintenance of dependencies. | Distinguish included updates from separately quoted changes. | Map who maintains each connection and approves changes. |
| Who can use and modify components? | Check licences and rights for the components you adopt. | Ask for terms covering code, configurations, instructions and documentation. | Document rights and restrictions for every component, including shared ones. |
| How is a new version checked? | Show regression tests and a rollback procedure. | Ask how changes are communicated, tested and accepted. | Establish who authorises a version involving both parties. |
| How much work remains internal? | Count development, operation, review and exceptions. | Count the internal owner, approvals and service exclusions. | Include coordination and handovers between the two teams. |
| What happens when you change solution? | Check documentation and dependencies on individuals or platforms. | Ask about export formats, exit support, timescales and costs. | Test whether components can be replaced separately. |
The guide to integration with ERP and business systems makes the technical questions more concrete. Where an answer depends on access that has not yet been verified, record it as an open condition rather than an existing capability.
The cost inventory to request
Request the same inventory from the internal team and the provider. For every item, identify who bears the cost, what is included and what could change it. Compare the options over the same period, volume and service level.
- Analysis and preparation
- Time spent describing the process, organising data, collecting examples and defining the output.
- Initial implementation
- Development or configuration, connections, permissions, documentation and handover.
- Checks before use
- Test cases, permission checks, corrections and business acceptance.
- Recurring operation
- Service, licences, infrastructure and applicable usage charges, without adding components already included elsewhere.
- Supervision and recovery
- Review time, exception handling and manual work during interruptions.
- Maintenance and development
- Updates to systems and dependencies, new rules, further testing and support.
- Exit and replacement
- Exports, transferable documentation, migration and the handover period to the next solution.
The guide to Digital Employee costs helps distinguish initial investment, ongoing management and remaining work. Internal hours consume capacity even when they do not generate a new invoice; released hours become cash savings only when an actual expense changes.
Make ownership and continuity concrete
Separating data, code, configurations and third-party components prevents misunderstandings. Rights to use, modify and transfer them depend on applicable contracts and licences; paying for a project does not establish those rights automatically. Ask what you would receive when the relationship ends, and test whether the documentation lets another person understand the process.
The NIST AI Risk Management Framework covers roles, post-deployment monitoring and dependency management throughout the lifecycle. It is a reference for forming questions; citing it does not certify a provider. The provider selection guide covers further points to check in a proposal.
You may choose an in-house build for a strategic capability you intend to maintain, a managed service for work you want to entrust to a provider, or a mixed model with precise boundaries. Before deciding, ask each option to explain how it would handle the renamed business-system field in the opening example. How it works is a starting point for discussing the process and responsibilities to agree for Digital Employee.