Part 3: Plan Ownership, Adoption and Lifecycle

There is a lazy version of the build-versus-buy debate that sounds like this: "Copilot is expensive, so let's build it ourselves." Or the opposite: "Custom apps need infrastructure, so let's just use Copilot."

Both are too simple. The real debate has three cost layers: starting cost, scaling cost and ownership cost.

Productivity tools often win on starting cost. The licence may already exist. The admin centre may already exist. The identity layer is often already in place. The users already know Teams, Outlook, Slack or ChatGPT. You can get to first value without designing a database schema or deploying a backend.

Scaling cost is where the answer becomes less obvious. A vendor tool can become expensive when every user needs a licence, every workflow needs a platform seat, and every workaround creates hidden labour. A custom app can become cheaper at scale when the workflow is repeated often enough and the same product boundary serves many users.

Ownership cost is where custom apps bite. A simple internal AI app is not just a frontend and a model call. It may need hosting, SSO, roles, permissions, data storage, retrieval, model routing, observability, CI/CD, security reviews, support, governance and a plan for derived data.

There is one final trap: teams often judge AI tools by demo quality.

The agent answers a question well. The app produces a useful draft. The workflow runs once. Everyone gets excited. But demos are not systems.

A serious AI capability needs to be evaluated, owned, updated and eventually retired. Without that, the organisation ends up with a pile of agents, prompts, skills, scripts and apps that nobody fully trusts and nobody fully owns. The question is not only "does this work today?" It is: how will we know it still works three months from now?

This is where many productivity-tool rollouts are weak. They measure usage, but not quality. They count prompts, but not outcomes. They celebrate adoption, but do not know whether the work is actually better.

For low-risk individual productivity, light measurement may be acceptable. For operational workflows, client delivery or reusable firm IP, it is usually too weak. OpenAI's agent guidance includes human review, observability and evaluation loops, and NIST's AI RMF frames risk management across the design, development, use and evaluation of AI systems.59

Portability Matters More When the Method Is IP

Vendor lock-in is not always bad. If a company is already deeply Microsoft-based, using Copilot Studio, Teams, SharePoint and Power Platform may be the most sensible path. The organisation can get speed, governance and adoption advantages because the tool sits inside the existing work environment.

It becomes a problem when the firm's reusable expertise gets trapped in a format it cannot move, test, version or improve outside one vendor surface. A firm's proposal method, delivery QA approach, sector research workflow or client onboarding process may become valuable intellectual property. If that IP exists only as hidden prompts, click-ops flows and undocumented agent settings, the firm may own the account but not the method in a portable, improvable way.

Failure Handling and Retirement Need a Plan

AI systems fail differently from normal software. A normal app might crash. An AI app may confidently produce a weak answer, use the wrong source, omit a key exception, summarise the wrong client file or trigger a workflow that looks reasonable but is not.

If the workflow needs exception handling, approval queues, status tracking and rollback, it probably wants an app or at least a more structured workflow layer. Users need to be able to flag bad answers. Admins need to inspect what happened. Sources and tool calls need to be logged. High-impact actions need human approval. Changes need a rollback path.

And eventually, some things should be switched off. Many organisations already struggle to retire old systems; AI can add another layer of stale agents, prompts, skills, workflow automations, Streamlit apps and proof-of-concepts that people still occasionally use.

This is not bureaucracy for its own sake. It is how the organisation avoids turning early AI enthusiasm into long-term operational clutter.

There is one more reason AI projects fail. Not because the model is bad. Not because the app is badly built. Because nobody changes how they work.

Adoption is not the same as access. Giving everyone Copilot, Claude, ChatGPT or a new internal app does not mean the organisation has adopted AI. It usually just means the organisation has created another tool people may or may not remember to use.

This matters when comparing productivity tools with custom apps. Productivity tools often have a lower adoption barrier because they live inside existing habits. Copilot appears in Teams, Outlook, Word, PowerPoint and Excel. ChatGPT or Claude sits in a familiar chat interface. A shared agent can be dropped into Slack or Teams. The user does not have to learn a whole new system.

That is a real advantage. But it can also hide weak adoption. People may use the tool once, get a mediocre answer, and quietly stop. Or they may use it in inconsistent ways, with different prompts, different assumptions and different quality standards. The organisation then has "AI usage", but not a repeatable capability.

Custom apps have the opposite problem. They can give the workflow a much better home: clearer screens, structured inputs, review steps, status tracking, source evidence and role-specific experiences. But they require people to leave their normal flow of work. If the app is not obviously useful, trusted and embedded into the process, it becomes another portal. And people hate another portal.

Adoption Is a Product Problem, Not Just a Training Problem

A common mistake is to treat adoption as a comms exercise: launch email, training session, Teams post, maybe a short demo. Then everyone wonders why usage drops after two weeks.

For AI tools, users need more than awareness. They need to know whether the tool helps their actual job, whether they can trust the output, whether it is faster than their workaround, whether they are allowed to use it with the data in front of them, what good use looks like, who is accountable if the output is wrong, and where to go when it breaks.

Better AI rollouts do not start with "here is the tool". They start with a job. A proposal manager cares whether the system helps produce a better first draft with approved case studies and fewer compliance issues. A consultant cares whether it helps them get to a sharper client answer faster. A partner cares whether evidence is traceable and risk is controlled. A finance user cares whether the workflow saves time without creating audit problems.

This is where custom apps can sometimes outperform generic agents. A custom app can put trust mechanisms directly into the interface: sources, missing evidence, review gates, draft-versus-approved status and feedback capture. But vendor tools may still be better when trust already exists in the work environment. If users trust SharePoint permissions, Teams channels and Microsoft 365 governance, an assistant inside that world may feel safer than a standalone app.

Measure Changed Work, Not Adoption Theatre

AI adoption metrics often stop too early: licences assigned, active users, prompts sent, agents created. These can be useful, but they do not prove value.

A better adoption dashboard asks whether people come back after the novelty fades, whether the tool helps finish a real workflow, whether the process is faster, whether outputs are better or more consistent, how often humans approve or reject AI outputs, where the tool fails repeatedly, and whether proposal cycle time, QA effort or operational backlog actually improves.

High usage can still be low value. A team may send thousands of prompts and save very little time. Another team may use a small internal app twice a week and remove hours of painful manual work. The point is not adoption theatre. The point is changed work.

Champions Need to Be Close to the Work

For consultancy firms, adoption usually needs local champions. Not generic "AI champions" who forward tips. Real champions embedded in the work: proposal champions, delivery QA champions, sector knowledge champions, operations champions and engineering champions.

These people translate the tool into the language of the team. They collect examples, explain edge cases, spot misuse, suggest improvements and keep the system honest. Without that operating model, adoption becomes enthusiasm without ownership.

The adoption question is not "can we deploy this?" It is: can we make this part of the way work gets done? That is a much higher bar.