Demand Intake and Pipeline Visibility
Building a front door for automation demand — a self-service intranet intake page, BA-led feasibility review, and full Jira and Confluence pipeline visibility that kept the programme and its stakeholders aligned from first request to production delivery.
Without a structured intake process, automation demand arrives through informal channels — emails, corridor conversations, escalations from line managers. Some of those requests are strong candidates. Many aren't. And without a way to capture, assess, and prioritise demand systematically, delivery teams end up managing a backlog they can't see clearly, and stakeholder expectations without the tools to do it.
The problem compounds over time. A programme that handles ten requests informally can just about function. At fifty, the absence of a structured pipeline becomes a source of friction — between the CoE and the business, between what was promised and what can be delivered, and between the team's capacity and the demands placed on it.
The CoE needed a front door. A way for the business to understand what automation could do for them, self-assess whether their process was a viable candidate, and submit a request that gave the team enough information to begin assessment — without requiring a meeting every time something new came in.
Beyond intake, the programme needed to turn that demand into a visible, manageable pipeline — one where requests could be assessed, prioritised, and tracked through delivery in a way that kept everyone, from the requesting team to the relevant head of department, informed without manual effort at every stage.
A healthy pipeline requires more than a way to receive requests. It needs a mechanism to educate the business, a process to assess and validate what comes in, and the tooling to make the full lifecycle visible to everyone with a stake in it.
Intranet intake page
An intranet page accessible to everyone in the business explained what RPA is, what makes a good automation candidate — rule-based, repetitive, stable, high volume — and what doesn't. It set expectations on timelines and outlined the process for submitting a request. By educating the business before the first conversation, it filtered out the weakest candidates early and meant that requests arriving for review already reflected some understanding of the criteria. The front door did some of the assessment work before anything reached the team.
BA-led feasibility review
Every request was reviewed by a BA who sat down with the requesting team to assess feasibility in detail. The assessment covered whether the process was a genuine RPA candidate, whether the supporting systems were stable enough to automate against, and whether RPA was the right technology — or whether a different approach would better serve the requirement. This gate ensured that what entered the pipeline was viable, and that stakeholders understood why a request might not proceed before it became a source of expectation. Heads of department and the RPA team jointly prioritised what was confirmed as feasible.
Jira and Confluence visibility
Jira tracked every request from initial submission through prioritisation, analysis, development, testing, and production handover. Confluence held the process documentation — solution designs, test records, runbooks — linked back to the corresponding Jira ticket. The result was a pipeline the entire programme could see: what was in queue, what was in analysis, what was in build, what was approaching production. Stakeholders could see where their request stood without asking. The team had a clear picture of capacity and load across the delivery lifecycle.
The intranet page acted as the first filter. Requests that came through it arrived with some understanding of what the team would assess — which meant the BA review could focus on depth rather than starting from first principles on every engagement.
The BA feasibility review was where most of the judgement happened. A strong candidate had clear criteria: it was rule-based, the supporting systems were stable, and the volume justified the development investment. When RPA wasn't the right answer — because the process was too variable, the system too unstable, or the volume too low — that assessment happened at the design stage rather than after development had already started.
Jira and Confluence closed the loop. The pipeline was always visible — to the CoE, to the heads of department involved in prioritisation, and to the business teams who had submitted requests. Communication that previously depended on someone remembering to send an update became a structural feature of how the programme operated.
A pipeline the CoE could see, manage, and communicate — from the first request to production delivery.
Requests arrived through a consistent channel, were assessed against consistent criteria, and moved through a delivery lifecycle that was visible to everyone with a stake in it. The business knew what to expect. The team knew what was coming. And prioritisation decisions were made by the right people, with the right information, at the right time.
Pipeline & Demand in ROM2 asks whether the CoE has a structured and visible way to manage automation opportunity from identification through to delivery. The intake process, feasibility assessment, and pipeline tooling aren't administrative overhead — they are what determines whether the right work gets built, in the right order, with the right people informed throughout.
Assess your CoE's pipeline and demand maturity →