"Automate, Fix, or Hire": A Decision Framework for Automation Portfolio Investment

The automate/fix/hire framework classifies every submitted process problem into exactly one of three investment categories before development begins: automate (the process is a genuine, well-qualified automation candidate), fix (the root cause is a broken or missing system capability that should be addressed directly), or hire (the volume and judgment requirements exceed what automation can responsibly handle, and the real gap is capacity). Getting this classification right at intake - rather than discovering it mid-build - is what keeps a portfolio's investment aligned with its actual problems.

Why a Third Category Beyond 'Automate or Don't'

Most intake processes implicitly assume a binary: either a submitted problem is automatable or it gets rejected. That binary misses a large and costly category - problems whose real solution is neither automation nor rejection, but a different kind of investment entirely. A process that's broken because the underlying system lacks a feature isn't solved by automating around the gap; it's solved by fixing the system. A process that's genuinely too judgment-heavy and low-volume to justify AI or RPA investment isn't a rejected idea; it may simply need a person.

The Automate Path

This is the classic outcome: a process with clear, recurring volume, a stable current state, and a well-matched automation pattern (see The 7 Automation Patterns). It clears the Problem-First qualification gates, scores well on the deterministic engine, and produces a positive, defensible ROI case. This path leads directly into backlog refinement to determine whether it's citizen-developer or expert-developer scope.

The Fix Path

Root-cause analysis during intake sometimes reveals that automating the visible symptom would embed a system limitation permanently rather than resolve it. IntakeOS tags these candidates explicitly as system_fix rather than automation, and the report leads with that finding - a deliberate, amber-banded callout designed to stop a team from automating their way around bad architecture. Routing these to the right owner (usually an application or platform team, not the automation CoE) prevents wasted development effort and the maintenance burden of a workaround that outlives the reason it was built.

The Hire Path

Some submitted problems fail automation qualification not because the process is unclear, but because the honest answer is that the organization needs more capacity doing genuinely judgment-heavy work that doesn't follow learnable patterns - the kind of work covered in the 'agent vs. workflow vs. RPA' decision tree in Agentic AI vs. RPA vs. Workflow Automation. Recognizing this path explicitly, rather than quietly declining the intake, gives a CoE something concrete and useful to tell a frustrated business sponsor: not 'no,' but 'this needs headcount, not automation, and here's the data that shows it.'

How Classification Changes Portfolio Conversations

• Leadership sees three distinct investment categories instead of a single undifferentiated 'automation backlog,' which makes budget conversations more precise.
• System-fix candidates get routed to the team that actually owns the fix, rather than silently absorbed into automation scope.
• Hire-path findings give a CoE evidence-backed standing to recommend headcount, rather than being expected to automate every request regardless of fit.
• The automation-only backlog becomes more credible because it no longer contains disguised system fixes inflating its apparent size.

Frequently Asked Questions