Buying Operations by the Hour: A Bet Against Automation

In July, ISG published a piece for sourcing executives with a line worth reading twice: an application management agreement can be “contractually alive and commercially obsolete.” Their argument is that contracts signed today may still be running in 2030, by which point embedded agents will be doing work that today is billed as human effort, and a contract that measures value in effort will be measuring the wrong thing.

You do not have to believe any particular forecast about AI for the practical half of that to bite. It already bites, and it has nothing to do with agents:

If you pay for operations by the hour, you have hired someone who isn’t motivated to automate, because their revenue drops every time they automate.

That is not an accusation. It is arithmetic, and it is worth understanding before you sign a three-year contract.

Start with the strongest objection

A good provider automates anyway. Reputation is real, clients talk, and nobody survives in Swiss IT services by billing hours for work a script should do. All true.

But this objection treats automation as an attitude. It is an investment, and somebody has to propose it.

Operational quality almost always comes from work done in advance. An alert that stops firing, an upgrade that runs unattended, a restore that is tested rather than hoped for: behind each of those are engineering hours that have to be spent long before they pay for themselves. Under an hourly model, you pay for those hours, and that is fine. The problem sits one step earlier. The provider is the one who has to propose the work, and every such proposal cuts into their future revenue. So the question is not whether they want to automate. It is why they would ever raise it.

Raising it is their move to make in any case. You see your invoice. They see which recurring manual work lies behind it and which part of that could be scripted. A proposal that was never made leaves no trace: no rejected quote, no line in the minutes, nothing you could pick up in a quarterly review. The automation you are missing is the one you never heard about.

Some providers raise it anyway: to win the next contract, because engineers cannot be hired on demand and freed capacity is the only way to grow, or simply because you do not keep good people by having them repeat the same manual work for years. All real. None of it makes automation revenue-positive under an hourly model, though. Revenue-neutral at best, because the hours saved have to be sold to somebody else. And those motives are not yours. They are not in any contract, and you cannot check whether they still hold.

Three ways to pay for operations

Time and materials

You pay for hours. This rewards presence, and it is honest about what it is: you are buying access to people.

It is the right model when you cannot specify the work in advance, which is exactly why it fits consulting and does not fit a running service.

Per ticket, or per incident

You pay for the volume of incidents. This is worse and more common than it should be because it looks like paying for results. It rewards the provider that handles many tickets efficiently, not the provider whose systems generate few tickets. ISG makes the same point from the buyer’s side: the strongest provider may not be the one that resolves the most tickets fastest, but the one that prevents incidents from becoming tickets at all. A per-ticket contract cannot tell those two apart and pays the first one more.

Fixed fee per instance, per service, or per service level

You pay for a running outcome, priced before anyone knows how much work it will take. Now automation moves to the other side of the ledger. Every incident the provider prevents, every upgrade it automates, every alert it tunes out of existence lowers its own cost of delivery, and it keeps the difference. Your price does not move. Neither does your service level. What changes is what the provider is trying to achieve: fewer incidents, rather than more billable hours. That is the alignment you are buying, and it is worth more than the discount you would have negotiated.

This is the model we use for the running operation. Application operations is priced per application and per service level indicator, from CHF 800 per month, so a bad month for your service does not become a bigger invoice. It is also why we can publish the comparison plainly: matching that 24×7 coverage in-house would require four to six engineers at CHF 150,000 to 200,000 per year each, and we deliver the equivalent for less than the cost of half a full-time engineer. That number is only possible because automation is our margin, not our lost revenue.

Be suspicious of anyone claiming their model has no hourly component at all, including us. Our line runs along the layers, and what draws it is authority rather than technology. Platform and infrastructure, meaning the Kubernetes substrate, the managed data services, and the servers, storage, and network underneath, are patched, change-managed, and backed up inside the fixed price. A platform patch that breaks something is ours to fix, so we apply it without asking. Your container image stays yours, because only your test suite knows whether your product survives a bumped extension. Application-specific engineering you ask for on top, such as CI/CD work, observability, or a business continuity test, is quoted separately, and so is consulting.

The usual objection to that is: then our dependencies are our problem. The workable answer is Renovate in your CI/CD. Updates arrive as pull requests, your tests are the gate, your team merges. Automated from your side without moving the decision.

So the distinction that matters is not whether a provider ever bills by the hour. It is whether keeping your service running is billed by the hour. The incentive works on the fixed layer, and that is the layer where most of the work comes from.

How this looks from the outside

You will not see a provider’s pricing model in their behavior. You will see its symptoms. Monthly change freezes. A Jira ticket to add a DNS record. A four-week lead time on a configuration change that takes ten minutes. Those are the artifacts of a process nobody had a commercial reason to automate, and they are common enough in Swiss enterprise IT that “avoid change freezes” is something buyers type into search engines.

These symptoms are not only about missing automation in the background. They are about who is allowed to press the button. A provider can have the DNS change fully automated internally and still make you file a ticket. Automating internally saves them cost. Giving you self-service deletes a line from the invoice. Under an hourly model, there is no commercial reason to do it, and under per-ticket pricing, there is a reason not to.

Be careful with the causation here: blast radius, segregation of duties, and audit obligations are real reasons to route a production change through a control. The question is not whether a control exists. It is whether it is a guardrail or a queue. A guardrail is a pull request with a policy check, an approval, and an audit trail: your team makes the change itself, and the control clears in minutes. A queue is the same claim without the work behind it. Guardrails cost the provider engineering time once and nothing afterward. Queues bill per occurrence.

The same holds for the change freeze itself. Freezes also come from real risk management, audit windows, and thin test coverage, and a well-run provider can have one for good reasons. The question worth asking, therefore, is not whether the freeze exists. It is whether it has been shrinking. A provider whose economics reward automation can tell you that its manual surface is smaller than it was three years ago, and roughly by how much. A provider billing by the hour has no such trend to report, and will usually not have measured it.

“Fixed price just means they cut corners”

The honest form of this objection is that a provider who is paid the same whether they do the work well or badly will drift toward doing it badly.

The answer is that the service-level agreement prices the downside into the provider’s own accounts. Availability commitments and service credits mean that under-investment shows up as a bill the provider pays itself. That is a real mechanism, and it is the reason fixed-fee operations work at all.

It is also the reason a fixed-price project is not the same thing. A project ends. Once it has been delivered, there is nothing left to hold, no credit to claim, and the operating model afterward is your problem. Continuing operations is the only arrangement in which the provider is still standing there in year three when the shortcut it took in year one surfaces.

Where consulting is exactly right

None of this means “don’t hire consultants.” We sell consulting ourselves at CHF 250 per hour, and we are not about to pretend otherwise.

Hours are the correct instrument for a bounded change: an architecture review, a migration, a platform assessment, training your team. The scope is uncertain, the engagement ends, and paying for effort is the only honest way to price something whose shape you cannot know in advance.

The mistake is a category error, not a supplier error. It is buying a continuing operation as an open-ended stream of hours, and then wondering in year two why the same alert keeps firing. Design the change as a project. Buy the operation as a service. Our own partner network runs on precisely this split: consultancies design and build the platform, and we operate it, because carrying 24/7 operations inside a consulting business quietly eats the consulting margin.

The exit question almost nobody asks

Here is the sharpest thing in the ISG piece. Every exit clause you have ever read covers the data. ISG’s version is one step further: can the customer retain the intelligence embedded in the operating model?

After three years of operation, the valuable artifact is not the database dump. It is everything that was learned about running your workload: the runbooks, the alerting thresholds tuned against your actual traffic, the upgrade procedure that survived contact with your extensions, the restore drill, the infrastructure definitions. If all of that lives in a provider’s proprietary tooling, then your exit right entitles you to your data and a fresh start from zero. You will rebuild three years of operational knowledge, and you will rediscover it the same way it was discovered the first time: one incident at a time.

So ask the question directly: is the automation that runs my service open source, and do I get it?

For us the answer has a good shape because the tooling is public. Project Syn and Commodore, which configure and operate the clusters, AppCat, which defines the managed services themselves, and K8up, which runs the backups, are public on GitHub under BSD-3-Clause and Apache-2.0. Your team or a new provider can read exactly how your service is operated, and run the same tooling, without asking us. What operates your service is not a black box you rent, it is a GitOps repository that belongs to you. What exactly changes hands at the end of a contract belongs in the contract rather than in a blog post, but a provider whose automation is proprietary cannot give you a good answer, no matter how the clause is worded.

Where a human still has to decide

ISG’s other useful correction: “human in the loop” is too generic to mean anything. The better question is which decisions require a named human, and it should be answered in writing before the operating model changes, rather than after accountability is disputed.

Reasonable candidates: approving a release into production, granting a security exception, accepting production risk, and calling a major incident. Ask your provider to name theirs. Be suspicious of an answer that is a slogan, and be more suspicious of a provider claiming its operations are autonomous. Ours are not. They are automated, which is a different and more auditable claim, and for a regulated organization, it is the one that survives an audit.

What to ask before you sign

1. Does my price move with the hours you spend, or with the service I receive?
2. If you cut your effort on my account by half next year, who keeps the difference?
3. What do you measure besides availability and time to repair? Anything about prevention?
4. When I leave, do I get my data, or my data and the automation that ran it?
5. Is that automation open source, or yours?
6. Which decisions will always require a named human on your side, and which on mine?
7. Which parts of this are a bounded project, and which are a continuing operation? Are they priced differently?
8. How much of what you do for me today was manual three years ago? What changed, and can you show me the trend?
9. What can my team change without you, and has that list grown or shrunk over the last two years?

ISG is right that the greatest risk is not applications that manage themselves. It is signing a long-term agreement that cannot adapt when they do. The nearer-term version is simpler and needs no forecast at all: do not sign an operations contract that pays your provider not to automate.

VSHN operates open-source infrastructure for regulated Swiss organizations since 2014. We are Switzerland’s first CNCF Kubernetes Certified Service Provider, a Red Hat Premier Certified Cloud and Service Provider, and ISO 27001 certified. The running operation is priced per application and per service level, not by the hour. Get a cost estimate for operating your application.

Sources:

• ADM 2030: When Applications Manage Themselves. Dr. Daniel Gerster, ISG, July 28, 2026
• VSHN service levels and support plans. VSHN product documentation
• Project Syn and AppCat, BSD-3-Clause, and K8up, Apache-2.0. Licences verified on GitHub, 4 September 2026