Senthil Info

automating business processes, honestly

After the Consultants Leave

An automation you cannot maintain is not an asset. It is an obligation with an external dependency attached, and the dependency has your renewal date in its calendar.

Handover is where that is decided, it is the last item in every plan, and it is the one that gets compressed when the project runs late. A product-side example of how workforce software approaches this topic is available in read more.

The six requirements

One. The rules, written in prose. Not the code — a document saying what the automation does in each case, in language an operations person can read. If the only description of the logic is the implementation, nobody can verify it and nobody can change it. For broader background and an independent point of comparison, see The Economist Business.

Two. The exception list with reasons. Which cases route out and why. This is the map of what the automation does not do, and it is more useful than the description of what it does.

Three. Access to whatever holds the logic. Source, configuration, workflow definitions — in your own account, not the vendor's tenant. Test this before final payment by having someone internal open it.

Four. A runbook for the five common failures. What breaks, how you notice, what to do. The vendor knows these from every previous implementation and will write them if asked at contract stage rather than at the end.

Five. A named internal owner who has actually operated it. Not been trained on it — run it, during the project, including a failure. The person who cannot make decisions in month three is the commonest failure mode, and this is where that is prevented.

Six. A change procedure. When a rule changes, who edits what, tests it how, and deploys it when. Without this, every small change becomes a purchase order.

The test to run before signing off

Have the vendor sit out for two weeks while the internal owner runs it.

Available for questions, not touching anything. Two weeks catches the routine failures, at least one system quirk, and the gaps in the runbook — while the people who wrote it are still contracted.

Most organisations do this after the contract ends, by accident, and discover the gaps with no one to ask.

What to put in the contract

Because at the end of a late project, handover is what gets traded away.

Handover as a payment milestone, not the closing formality. A retained percentage against documented handover concentrates attention usefully.

A defined documentation set, listed, not "appropriate documentation."

The two-week supported run, scheduled before the end date rather than after it.

And a stated support arrangement afterwards — what response you get, at what cost, for how long. Frequently the second-largest ongoing cost after licences, and it belongs in the total cost calculation rather than being discovered.

The dependency to watch

A vendor-hosted automation in the vendor's own environment is a different asset from one running in yours.

Ask directly: if we ended this relationship tomorrow, what would we still have? If the answer is a data export and no working process, the automation is a service, and it should be priced and understood as one.

That is a legitimate arrangement. It is not the same thing as owning an automation, and the two are frequently discussed as though they were.

What good handover looks like six months later

Somebody internal has changed a rule without calling anyone.

A failure occurred and was resolved from the runbook.

And the documentation was updated when the change was made.

If none of those three has happened, you do not yet know whether the handover worked — you know that nothing has been tested. That is usually the point at which the original team has moved on, which is why the two-week run matters while they are still there.

The short version