From 100% onshore to 75% automation

A managed-services delivery model rebuilt twice in seven years: offshore first, then automation — with the same three goals that now define what AI is for.

The 2019 column comes from the automation team's monthly report to me, dated April 2019. The 2021 column is the end state as I recall it; the practice was handling on the order of 50,000 tickets a month by then, and exact resolution rates for that year are not something I can reconstruct from memory. I'd rather state that than round up.

My role, stated plainly

I did not build this. I envisioned it, sponsored it, funded it, chose the lead, set the targets, and carried it into customer conversations and SOWs. My automation lead and his team built the automata and ran the program; the deck this page draws on is their report to me. The job of the practice leader is to drive better customer experience, faster outcomes, repeatable outcomes, and lower cost — and to pick the mechanism that delivers all four at once. In 2018 that mechanism was offshore delivery. From 2019 it was automation. Today it is AI. The goals never changed.

The two rebuilds

Onshore to offshore (2018). The practice launched in 2014 with onshore delivery. By 2018 it was running 80% offshore, 20% onshore, without service degradation — the model I had first built from scratch a decade earlier, running an offshore development center in Bangalore from zero to 100+ people. The point of the shift wasn't only cost. It created a delivery organization large enough, and standardized enough, that the next step was possible.

Offshore to automation (2019–2021). Standardized delivery produces standardized tickets, and standardized tickets can be mined. The program ran on a simple loop the team wrote down:

flowchart TD
  A[Analyze the ticket<br/>dumps periodically] --> B[Meet the<br/>tower leads]
  B --> C[Identify the<br/>repeatable tasks]
  C --> D[Collect the SOPs]
  D --> E[Build the workflow]
  E --> F[Test]
  F --> G[Customer approval]
  G --> H[Deploy the automaton]
  H --> A

Every automaton was tied to a documented SOP and approved by the customer before it touched their environment. That approval step is why the program could be sold, not just run: a prospect's ticket history could be scored against the existing library before signing, and in one case 54% of a prospect's tickets were automatable on day one with no new development.

What the program looked like in April 2019

Roughly 8,000 tickets a month across the accounts under measurement, with an automaton executing on about 7,000 of them. That's the "touched" figure. The stricter figure — tickets resolved end-to-end with no human — ranged from 16% to 44% by account, and the report said so explicitly, with the next 5–10 points identified in the pipeline. The library covered Windows, Unix, database, storage, network, virtualization, and backup: memory and CPU remediation, filesystem cleanup, host-down handling, user onboarding and offboarding, patching and post-patch health checks, configuration backups, capacity reports. Roughly 30 more were in the pipeline, and robotic process automation was queued as the next layer for the GUI-bound work — patch consoles, Citrix access, backup tooling — that scripted automation couldn't reach.

The cleanest single result was the flagship account:

xychart-beta
  title "Flagship account — hands-on effort hours per month"
  x-axis [May-18, Jun, Jul, Aug, Sep, Oct, Nov, Dec, Jan-19, Feb, Mar]
  y-axis "Hours" 0 --> 1600
  line [1426, 1290, 1288, 1166, 849, 678, 591, 527, 473, 663, 526]

From 1,400-plus hours a month to about 500, a two-thirds reduction, with the account consuming roughly 4 FTE of effort against 15 allocated in the statement of work. The February bump is in the chart on purpose: a spike in emergency offboarding requests that weren't yet automated. The team's report explained it and named the fix. That is what an honest operations report looks like, and it's the standard I later wrote into my own AI systems as stale never wears fresh and decline, don't fabricate.

What it taught me about AI

Automation and AI are the same project with different tooling. Both exist to make outcomes repeatable, faster, and cheaper. Both fail the same way — when the thing being automated wasn't standardized first, when the approval path is skipped, when "touched" gets reported as "resolved." And both are led the same way: pick the mechanism, fund it, choose the lead, set the numbers, tell the truth in the monthly report.

The specific lessons carried straight into the pricing engine and everything after it: mine the real ticket dumps rather than guessing what to automate; tie every automated action to a written procedure; get the customer's approval before the machine touches their environment; measure "fully resolved" separately from "assisted"; and expect a relapse curve, because the work that resists automation is the work that shows up in emergencies.