Introducing AI: software, an internal team or an agency?

Compare the same intended outcome. A subscription, a new employee and a managed integration project contain different services. Without a common scope, prices appear comparable while data preparation, connections, approvals and operation fall to different people.

Describe an ordinary case from intake to completion. Five questions define the assignment before a delivery model is chosen:

• What information is required?
• Where does it come from?
• Which systems must change?
• Which decisions remain human?
• How will completion be demonstrated?

A useful comparison brief might be: “Match new service enquiries to existing customers, create an actionable task and prepare a reviewed reply. Put ambiguous cases into a work list.” That includes CRM access, matching rules, duplicate prevention and an owner for exceptions.

If the brief simply asks for AI in sales, every supplier can offer something different. A software vendor demonstrates chat, a developer proposes a custom application and a consultant offers a workshop. Each may fulfil its stated assignment while leaving your actual process unresolved.

The table compares the three routes and their combination: when each often fits and which internal work remains.

This is not a ranking. A suitable built-in feature can remove the need for custom development. A partner can implement on existing software. An internal employee can take over after a specialist builds the initial connection. Plan those handovers explicitly.

Existing features. Check whether your current specialist application supports the task. An existing approval step or export may reduce the additional integration needed. Ask to see the precise operation: a general CRM integration says little about custom fields, attachments or the status information you require.

Representative cases. Use representative approved cases. Can the software identify an existing customer reliably, leave an ambiguous case open and allow correction? What happens when the connected account expires? A polished standard demonstration does not automatically answer these questions.

Shared responsibility. SaaS shifts parts of technical operation to the provider while retaining customer responsibilities. Microsoft, for example, describes continuing responsibility for data, identities and configuration in its cloud models. This is organisational guidance, not an interpretation of your contract. Microsoft shared responsibility, checked on 26 September 2026.

Limits. Standard software becomes less suitable when important business rules require permanent manual workarounds. Record those gaps. Three hours of daily rework are part of total cost, not a minor limitation attached to a cheap subscription.

Ongoing portfolio. An internal role is particularly relevant when the business needs to develop and maintain a continuing portfolio of automations. The person needs access to business teams, clear priorities and time for documentation, testing and operation.

Cover and review. Hiring one person does not create a complete team. Who covers their leave, reviews a security-sensitive design or resolves conflicting demands from departments? Settle those questions before recruitment so that the role does not absorb development, support and undefined process ownership simultaneously.

Workload. Estimate the real workload. One integration project may not justify a permanent position. Conversely, a growing set of business-critical workflows may make repeated isolated external assignments inefficient. Assess a realistic several-month backlog, including maintenance and changes.

Skills. Evaluate skills against actual work. Writing good prompts does not automatically imply an ability to build dependable integrations. An experienced developer may need support understanding your business processes. A concrete assignment is more informative than a long list of fashionable tools.

Escalation. Provide an escalation path for issues beyond the internal role’s expertise. A small company may sensibly combine one internal owner with specialist support. The operating model should acknowledge those boundaries instead of expecting one person to cover every technical and professional discipline.

Capability. Labels such as agency, consultancy and software house do not establish capability. Ask who implements and supports the work, what the deliverable is and how it will be accepted. A partner should explain difficult cases, not just demonstrate the ideal path.

Project and operation. A bounded project might include design, implementation, test cases, training and handover. Describe subsequent operation separately. Which failures are monitored, who renews credentials, who checks API changes, what response times apply and what requires another commission?

Accounts and handover. Use customer-owned or clearly assigned accounts. If every connection belongs to a supplier employee’s private account, changing providers becomes unnecessarily difficult. Handover should include agreed work products, configuration, responsibilities and recovery instructions. Rights to and delivery of the material belong in the agreement.

Business decisions. You still need to make business decisions when an outside partner implements the system. A partner can implement a rule but cannot determine an unusual discount or document requirement correctly when nobody supplies the governing rule. Budget internal participation explicitly.

Three synthetic cases show how the prerequisites change the choice between software, a partner and an internal role.

Small business with a standard need: A team wants to route enquiries received through an existing platform. The application already offers the required rule and work list. Configuration and a short briefing may be enough. A separate AI application would need a specifically identified remaining benefit.

Growing business connecting several systems: A CRM, document repository and internal order list need to work together. Staff can explain business rules but lack implementation time. A partner can deliver a bounded integration while an internal owner retains acceptance, exceptions and future prioritisation.

Business with an ongoing automation portfolio: Several departments need frequent changes and existing workflows support daily operations. An internal role can provide continuity, with external specialists for particular issues. When deciding, plan realistically for how much work staff can handle and who will cover their absences.

These are not customer references or universal recommendations. They illustrate the prerequisites affecting the choice. If process scope changes, the appropriate delivery model may change too.

Common annual model. Use a common annual model: implementation, recurring software and service charges, internal effort, operation and expected changes. For employment, include your actual employer and workplace costs and realistically available capacity, rather than salary alone or a generic internet estimate.

Invented example. In an invented example, the software route costs €200 per month and €1,000 to configure. Add four monthly hours of internal maintenance at an assumed €50 per hour. Year one is €1,000 plus twelve times €400, or €5,800. A partner offer of €5,000 setup and €100 monthly support initially totals €6,200, before adding any remaining internal work and software charges.

The table sets the two invented first-year totals side by side:

Matching scope. Those totals do not yet establish a winner. The scope must match. If only one option includes dependable failure handling or the necessary connection, they deliver different outcomes. Beside every amount, record the task included and the assumption still needing verification.

Internal capacity. For internal capacity, ask how many useful hours the actual backlog requires each month. A handful of hours is difficult to use as the sole justification for a full new role. Sustained high demand can make internal knowledge valuable in ways a single project price does not capture.

Cost of delay. Also compare the cost of delay. A cheaper option that cannot be delivered within the needed period may leave substantial manual work in place. Use your observed workload to assess that effect rather than inventing a revenue figure.

A good pilot shows how requirements are clarified, failures explained and changes documented as well as whether the technology works. Include an ordinary case, an exception and an outage. Ask whether a second person can understand the process from the documentation.

Agree beforehand which findings support continuation and which require postponement or a smaller scope. Without decision criteria, a pilot can become a series of demonstrations. Its most important uncertainty should be easier to answer afterwards.

The voluntary NIST framework also considers dependencies and risks involving third parties. A practical procurement question follows: who carries which responsibility after the project ends? NIST AI RMF Core.

Establish which information can be exported, how accounts can be transferred or recreated and what documentation remains available. An exported file is useful only when the next team understands its meaning and dependencies.

Clarify what can continue after a provider change and what would need rebuilding. Not every proprietary feature can move. That is not automatically a reason to reject a product, but it should be consciously accepted and included in the economic decision.

The next useful step is therefore a comparable process brief and a named internal owner. Identify remaining gaps, then choose the model that covers that particular assignment, including operation and handover, convincingly.

Agree a simple change process too: who describes a new requirement, estimates effort and consequences, and approves implementation? Without it, a clear initial scope can gradually expand. Later discussions about additional costs should rely on recorded decisions rather than different recollections of what was intended.

These guides cover the decisions that follow the choice between software, an internal team and an agency:

• AI automation: tasks, selection and implementation
• AI automation costs: a first-year budget for SMEs
• AI workflow approvals: who checks which action?
• BMD and AI: existing features and useful additional workflows
• n8n, Make and Power Automate