Who looks after an automation once it is live?

Running does not mean correct

A connection can stay green while records are incomplete, tasks reach the wrong person or an old rule keeps running. Technical health is one part of the process.

The useful question is whether the business case completed as expected. Did the approved information reach delivery? Was the customer update sent once? Can somebody see the cases that stopped halfway?

Name the signals before launch

A process needs a small set of signals that prove movement and completion. Tool-level alerts belong in that set, but they are not enough.

For a client onboarding route, useful signals might include an accepted start record, all required items present, delivery owner notified and no duplicate live case. The exact checks follow the business promise.

Give every failure a recovery owner

Some failures can retry safely. Others need a person to correct information or decide whether the work should continue. The recovery route should state both.

If the builder is the only person who understands the failure, the owner will eventually become the support desk by forwarding screenshots and chasing a response. Agree responsibility, contact route and expected handling before the process becomes normal work.

• What can retry without creating a duplicate?
• Which cases need a business decision?
• What information is needed to resume safely?
• Who tells the affected person when timing changes?

Routine maintenance has a boundary

Credentials expire. Providers adjust fields and limits. A team member changes role. These are foreseeable parts of running a technical process.

A new pricing rule or service line is different. It changes business behaviour and needs a new scope, test and acceptance decision. Treating additions as maintenance hides risk and makes the monthly relationship unclear.

Provider problems still need a local response

Nobody outside the provider can guarantee its availability. Process Care should not pretend otherwise. It can detect the failure, stop safely, preserve the case and resume or route it when service returns.

This distinction belongs in the agreement. The provider owns its platform. The process owner decides the business fallback. The technical care role handles the agreed monitoring and recovery around it.

Care can reduce dependence over time

Good care keeps operating notes current and makes changes visible. The client should know which accounts, providers and rules the process depends on. They should be able to leave with a current description of how to operate and recover it.

The aim is dependable work, not permanent mystery. A clear care boundary allows Marc to own the technical upkeep without making the business hostage to its builder.