AI Is an Operating Model, Not a Tool

Every IT leader I talk to has an AI initiative. Almost none of them have an AI operating model. The two get used interchangeably in board decks, and the gap between them is where the budget goes to die.

So let me pin the term before anything else. An AI operating model is a way of running IT in which the organization consumes its own work the way a customer would, so that operational friction has a structured destination — and becomes the raw material for what AI builds next. That is the whole thesis in one sentence. Everything below is the proof, and one diagnostic you can run on your own org before you read another line: when a person inside your company hits a wall with a tool, where does that friction go?

Here is the distinction I keep coming back to, because I had to learn it the slow way. Adding AI to IT means you took a workflow you already ran and bolted a model onto it — a smarter ticket router, a summarizer, a copilot in the console. The org is unchanged; it just has a faster tool. Running IT as an AI operating model means the way the organization operates — how it finds friction, who it tells, and what happens next — is itself the thing AI reshapes. The first is a purchase. The second is a behavior. You can buy a feature in an afternoon. You cannot buy a behavior.

I want to be precise about what I did and did not do, because this is the part that gets overclaimed. I did not build the models. I ran a 100+ person global IT organization on a $15M+ technology portfolio as the first and hardest customer of the company’s own products, and I owned the loop that turned what we broke into what the product became. That loop is the operating model. The AI features are downstream of it.

The afternoon you can buy, and the loop you cannot

Walk into most enterprises and you will find AI features everywhere. A deflection bot here, a generated-summary panel there. What you will rarely find is a standing answer to that more basic question: when a real person inside the company hits a wall with a tool, where does that friction go?

In most orgs, it goes nowhere. It becomes a ticket, the ticket gets closed, and the friction evaporates without ever reaching the people who could remove it at the source. That is the failure mode, and no model fixes it, because it is not a model problem. It is an operating-model problem.

At GoTo, my organization ran the company’s own products — GoToResolve for service management, GoToConnect for voice, GoTo Webinar — internally, at enterprise scale, alongside and often ahead of paying customers. We called it the Customer Zero program internally. The mechanics were unglamorous: we used the products hard, we logged where they failed under real load, and we routed that friction directly to Product Development and Product Management through dedicated Slack-to-Jira channels — not as complaints, as a queue. IT ran as an internal MSP with a real intake, not a comment box.

The number that makes this real is the integration rate, not the submission count. On the ticketing track, my org sent 233 feature submissions into the product organization and 46 percent were integrated into the actual product; a separate asset-management track ran higher, at 57 percent across its own set of requests. I lead with the rate deliberately, because the temptation is to brag about volume. Volume is cheap; anyone can file requests. The signal is that roughly half of what we surfaced was real enough to ship. And the loop did more than ship features: it caught real defects before customers ever felt them — on the order of $38,000 in bugs surfaced internally before they reached a paying account, plus the run-rate we retired by decommissioning the tools the product replaced. A feedback loop where roughly half the input changes the product is an operating model. A suggestion box where nothing comes back is a morale problem with a logo on it.

Why the AI tool came after the operating model

The clearest proof that this is a model and not a tool is that the tool was a consequence of the model, not the reverse.

We built Tech-E, an AI support assistant, inside GoToResolve. It deflected 28 percent of Tier-1 tickets and lifted CSAT by 12 points — and I have written about those mechanics in detail in 28% AI ticket deflection: what we actually built. What matters for this argument is the order of operations. Tech-E did not arrive because someone decided IT should “do AI.” It arrived because Customer Zero had already put my team’s hands deep inside GoToResolve as daily users, which meant the surface where an AI assistant could actually help — and the failure data to point it at — already existed. The operating model created the conditions. The feature filled them.

Run that the other way and you get the demo that never ships. Buy an AI assistant for a product your team doesn’t use the way your customers do, point it at tickets your team has never had to close itself, and you get a pilot that reports up beautifully and changes nothing. The plot is always the same: impressive launch, quiet retirement, a line in next year’s budget asking what happened to the last one. A graveyard of pilots, all of them well-attended at kickoff.

The one test for an AI operating model

So here is the claim I will put my name on — and the version of it a generalist actually can’t sign.

The surface-level test is easy to state: does your organization consume its own work the way a customer would, so that friction has a destination? A consultant could write that on a slide. The part a consultant can’t write is why the feedback is good enough to act on, and that comes from a structural fact, not a process. My organization had no escape hatch. We could not switch vendors to dodge a flaw in a product the company itself sold. When GoToResolve broke under our load, we could not file with someone else and wait — the fix had to come from inside the building, which meant the bug report had to be specific, reproducible, and honest enough for Product to act on it the same week.

That constraint is the moat. The reason roughly half of our submissions integrated is that they came from an organization that couldn’t route around the pain. A detached pilot never produces feedback of that quality, because a detached pilot always has an exit. The friction was real because it was ours, with no door marked “other vendor.”

And it was a deliberate choice, not an accident of org chart. We kept running the company’s own product internally even in the stretches when it broke in our hands and a commercial alternative would have been quieter to operate. We chose to be the org that finds the bug first and owns the awkward conversation with Product — and the cost was real: we absorbed failures our peers got to read about in a release note. The return was a product surface we understood better than anyone outside it, and an AI assistant with somewhere credible to stand. I would make that trade again.

What this means if you’re standing up AI in IT

A few things I would tell anyone trying to do this on purpose rather than by accident.

• Decide what surface you will run as Customer Zero before you buy a single model. If your company sells software, that surface is your own product. If it doesn’t, the surface is the platforms your IT org itself ships to employees — the service desk, self-service, provisioning, the internal automations. Either way, the operating model is the substrate and the AI is what grows on it. If there is no surface your own team lives inside daily, you are buying features with nowhere to root.
• Instrument the friction, not just the wins — with one named path. Stand up a structured intake (a Slack-to-Jira channel routed to whoever owns the product or platform, reviewed on a fixed cadence) and report the integration rate on that cadence. Count the rate, not the submission volume — the first measures whether the loop is real, the second measures whether your team can fill out forms. A working threshold to hold yourself to: if fewer than one in three of the friction items your team surfaces ever ships, you have a suggestion box, not an operating model.
• Expect to go first, and staff the conversation that follows. Being the hardest customer of your own tools means finding the failures before anyone else and owning the discussion with Product when their thing broke in your hands. Price that in: name an owner for the IT-to-Product feedback queue, and budget for the fact that your org will log some defects before customers do. That is the cost. The compounding is the return.
• Keep the feature roadmap and the operating model in separate boxes. Features are bought and retired. The model — who finds friction, who hears about it, what happens next — is built once and pays out across every tool you ever add. Confusing the two is how the budget line for “AI” becomes a graveyard of pilots.

None of this requires you to build models. It requires you to decide that IT is not a place where software gets consumed and tickets get closed, but a place where the organization’s own friction is the raw material for what comes next. That is a leadership choice long before it is a technology one — which is why executive readiness isn’t a title so much as the willingness to own that loop and answer for it.

The case study for how the loop ran day to day is in the GoPilots write-up. This piece is the thesis that sits above it: the loop is the product. The AI is what the loop happens to be made of this year. Next year it will be made of something else, and an organization that built the model will absorb that the way it absorbed this one. An organization that only bought features will be back in the market, wondering why last year’s transformation already needs replacing.

AI is an operating model, not a tool. The tool is the part you can see. The model is the part that decides whether the tool was worth buying.

Common questions

What does it mean to run IT as an AI operating model instead of a tool?
An AI operating model is a way of running IT in which the organization consumes its own work the way a customer would, so that operational friction has a structured destination and becomes the raw material for what AI builds next. Adding AI to IT, by contrast, means bolting a model onto a workflow you already run — a smarter ticket router or a console copilot — leaving the organization unchanged but faster. The first is a purchase; the second is a behavior. The test is whether friction has somewhere to go rather than evaporating into closed tickets.

What is the Customer Zero program and how does it prove AI is an operating model?
Customer Zero is the internal program in which an IT organization runs the company’s own products — at GoTo, GoToResolve, GoToConnect, and GoTo Webinar — at enterprise scale, alongside and often ahead of paying customers, then routes the friction it finds to Product Development through structured Slack-to-Jira channels. On the ticketing track, 233 feature submissions went to the product organization and 46 percent were integrated; a separate asset-management track integrated at 57 percent. A loop where roughly half the input changes the product is an operating model; a suggestion box where nothing returns is not.

Why did the AI support assistant come after the operating model, not before?
Tech-E, the AI support assistant built inside GoToResolve, deflected 28 percent of Tier-1 tickets and lifted CSAT by 12 points. It existed because Customer Zero had already put the IT team’s hands deep inside GoToResolve as daily users, which created the surface where an AI assistant could help and generated the failure data to point it at. The operating model created the conditions; the feature filled them. Buying an AI feature for a product your team doesn’t use the way customers do produces a pilot that reports up and changes nothing.

What is the single test for whether an organization has an AI operating model?
Does your organization consume its own work the way a customer would, so that friction has a destination? The surface version of that test is signable by anyone. The part that makes the feedback credible is structural: an org with no escape hatch — one that can’t switch vendors to dodge a flaw in a product it sells itself — is forced to produce specific, reproducible feedback, because the fix has to come from inside the building. Where friction has nowhere to route, AI compounds on a surface the team understands; where it does, AI accumulates as disconnected features.