Back to blog

The invisible cost of maintaining an automation client

The cloud bill is only one part. Interruptions, access, deployments, incidents and concentrated knowledge can erase margin without appearing in any budget.

The invisible cost of maintaining an automation client

An automation can look profitable on delivery day and stop being profitable six months later.

The proposal usually covers design, development and implementation. Maintenance becomes a percentage or a block of hours. Much of the operating cost, however, does not arrive as planned work. It appears as interruptions, checks, permissions, small changes and context that must be recovered.

The result is a client that produces monthly revenue while consuming invisible capacity.

The cloud bill is not the operating cost

Infrastructure spend is easy to find because it arrives as a consolidated bill. It only represents one layer.

The real cost of maintaining a solution includes:

  • compute, storage and traffic;
  • observability and backups;
  • licences or external APIs;
  • deployment time;
  • alert review;
  • incidents and recovery;
  • credential changes;
  • dependency updates;
  • client support;
  • internal coordination;
  • knowledge retained by one person.

Two clients with the same cloud bill can have completely different operating costs.

The interruption tax

A ten-minute request rarely costs ten minutes.

Someone reads the message, recovers context, finds access, checks the environment, executes the change and returns to their previous task. When the procedure is not standardised, every intervention includes investigation.

To estimate this tax, record for two weeks:

  1. who was interrupted;
  2. how long the action took;
  3. how long returning to the previous task took;
  4. whether the knowledge was documented;
  5. whether the action could have been automated or delegated.

This is not about monitoring people. It makes demand visible when the budget does not.

The cost of exceptional access

Each client tends to introduce different accounts, VPNs, keys, portals and policies.

That patchwork creates work around:

  • joiners and leavers;
  • access recovery;
  • secret rotation;
  • permission reviews;
  • contractor onboarding;
  • emergency response;
  • audits or client requests.

The more exceptional the access model, the more expensive each routine action becomes.

Time is not the only cost. Old permissions, shared credentials and personal accounts also become more likely.

Maintenance without boundaries

“Maintenance included” can mean very different things to an agency and a client.

The client may understand that it covers:

  • any incident;
  • third-party changes;
  • new versions;
  • performance improvements;
  • out-of-hours support;
  • data recovery;
  • minor extensions.

The agency may only have budgeted for fixes and basic updates.

When scope is not observable, every request requires negotiation and the relationship accumulates friction.

A maintainable service defines events: what starts work, which response is expected, what is included and what changes the scope.

Estimating cost per client

Perfect accounting is unnecessary. A consistent approximation is better than impossible precision.

1. Direct cost

Add infrastructure, tools, licences and attributable external services.

2. Shared cost

Distribute common platform, observability or support using an explicit rule: reserved resources, usage, transactions or a fixed base.

3. Planned time

Include maintenance, operating meetings, deployments and agreed reviews.

4. Unplanned time

Add incidents, interruptions, investigation and context recovery.

5. Concentration risk

Identify work with no substitute. It is difficult to price directly, but capacity can be reserved to reduce it.

A simple formula is:

operating cost = direct cost + shared allocation + planned hours + unplanned hours

Compare the result with recurring revenue, not the total value of the original project.

Three clients that look the same

Imagine three automations with €500 of monthly maintenance.

Client A uses a common template, has automated deployments and produces one incident per quarter.

Client B lives in its own account, requires a VPN and needs manual intervention for every release.

Client C shares infrastructure but processes ten times more documents and creates most alerts.

Revenue is identical. Margin is not.

Without attribution, the agency may consider the portfolio profitable while A subsidises B and C.

Metrics that actually help

Avoid building a measurement system more expensive than the problem. Start with:

  • cloud and tooling cost by client;
  • deployment count;
  • minutes of manual intervention;
  • incidents and severity;
  • recovery time;
  • out-of-scope requests;
  • people able to operate the environment;
  • urgent access changes;
  • consumption versus contractual limit.

A monthly review is enough to reveal a trend without chasing every minute.

Margin is protected by designing operations

Higher prices may be necessary, but they do not repair a system that multiplies exceptions.

The most effective improvements are often:

  1. a common environment template;
  2. repeatable deployments;
  3. minimum observability per client;
  4. tagging and consumption limits;
  5. explicit maintenance scope;
  6. runbooks for frequent actions;
  7. a second person able to intervene.

Each improvement reduces variability. Cost becomes more predictable, and the service can be sold without relying on optimistic assumptions.

One question for the next review

Choose one recurring client and reconstruct the last 90 days: spend, hours, interruptions, incidents and people involved.

If you cannot do it, the first problem is not that the client may be unprofitable. It is that the agency does not yet have enough information to know.