An Automation Center of Excellence (CoE) is the small team that turns scattered bots and scripts into a managed programme: it decides what to automate, sets standards, runs the platform and proves the value. Many organisations set one up after their first few automations succeed, and then stall. This guide covers how a CoE is organised, who you need, and the seven challenges that most often get in the way, with practical fixes for each.
Key takeaways
- A CoE exists to choose the right work, build it to a standard and prove the value, not just to build bots.
- Most organisations do best with a hybrid model: a central team owns the platform and governance, business units build with support.
- The biggest risks are people and process, not technology: unclear goals, resistance to change, weak pipelines and no measurement.
- Track a small set of metrics from day one: hours returned, error rates, bot uptime and cost per automation.
Choose an operating model
The first decision is who builds automations. There are three common models, and many organisations move from one to the next as the programme matures.
| Model | How it works | Strengths | Watch out for |
|---|---|---|---|
| Centralised | One team builds, deploys and supports everything | Consistent quality, easy governance | Becomes a bottleneck as demand grows |
| Federated | Business units build their own; CoE only sets standards | Scales fast, close to the business | Duplicated effort, uneven quality |
| Hybrid | CoE runs the platform, reviews and complex builds; units build simpler automations | Balance of speed and control | Needs clear rules on who builds what |
Core roles
- CoE lead / sponsor: owns the roadmap, budget and business case; ideally reports to a senior operations or technology leader.
- Process analyst: documents processes, estimates benefits and writes the design document.
- Solution architect: sets technical standards, reusable components and the platform design.
- Developers: build and test automations; in a hybrid model, “citizen developers” in business teams build simpler ones.
- Support / operations: monitors bots, handles failures and manages releases.
- Change and training lead: often part-time, but essential for adoption.
In a small organisation one person may hold several of these roles. What matters is that each responsibility is owned by someone.
Seven common challenges, and how to overcome them
1. Unclear objectives
Without clear goals, the CoE builds whatever the loudest team asks for. Tie the programme to two or three business outcomes, such as faster month-end close or shorter customer response times, and judge every idea against them.
2. Resistance to change
Employees may see automation as a threat to their jobs. Explain early what will change, involve the people who do the work in designing the automation, and show how the freed time will be used. Teams that help build automations tend to become their strongest supporters.
3. A weak pipeline of ideas
After the obvious candidates are done, many CoEs run out of work. Make it easy to submit ideas through a simple form, run discovery workshops with each department, and use process data to find repetitive work people don’t think to mention.
4. Automating the wrong processes
Unstable, exception-heavy or soon-to-be-replaced processes make poor candidates. Score every idea on volume, rule clarity, stability and benefit before committing development time. Our do’s and don’ts of RPA include a checklist for this.
5. Scope creep
An automation that tries to handle every exception takes months and breaks often. Agree the scope in a design document, automate the main path first, and route exceptions to a person.
6. Fragile bots and no support model
Bots break when screens, files or passwords change. Set coding standards, use shared components, test in a separate environment, and agree who fixes a failed bot and how quickly. Where an API exists, prefer it to screen automation.
7. No proof of value
If you can’t show results, funding dries up. Record a baseline before each build and report the same metrics every month.
Metrics worth tracking
| Metric | Why it matters |
|---|---|
| Hours returned to the business | The simplest measure of capacity freed |
| Error or rework rate before vs after | Shows quality gains, not just speed |
| Bot success rate / uptime | Reveals fragile automations early |
| Time from idea to production | Shows whether the CoE is a bottleneck |
| Cost per automation and payback period | Supports the next budget request |
Avoid reporting “number of bots” as the main success measure. Ten small bots that save an hour a month each are worth less than one that removes a full-time manual process.
A 90-day starting plan
- Days 1–30: appoint a sponsor, agree goals, pick the platform and set up development, test and production environments.
- Days 31–60: deliver two or three quick wins with clear baselines; publish standards and an idea-submission form.
- Days 61–90: report results, build a prioritised pipeline for the next two quarters, and decide whether to train citizen developers.
Choosing a platform is part of the first month; compare options in UiPath competitors and see where AI fits in RPA vs intelligent automation.
Frequently asked questions
How big should an automation CoE be?
Many start with three to five people: a lead, an analyst, one or two developers and part-time support. Size it to the pipeline, not the other way round.
Does a CoE only work with RPA?
No. A modern CoE usually covers RPA, workflow tools, integrations, document processing and AI, choosing the right tool for each process.
When should we introduce citizen developers?
Once standards, governance and support are in place, usually after the first few months. Without them, citizen development creates unmanaged bots.
Leave a Reply