Who Changes It in Six Months?

The repeating job you automate this quarter won't be the same job in six months. That's not a warning about the software. It's a fact about the work. And it's why a good demo, however pleasing, only answers half the question.

A working demo tells you the job can be done. It doesn't tell you who owns it. One short question gets at the difference, and you can ask it in the same meeting without sounding difficult: who changes it in six months?

What the question is really asking

Take whatever you're about to hand over. Say it's inbound enquiries: they arrive, get read, the promising ones get a reply and land on someone's list, and the rest get logged. On the day you sign, that's a set of rules and a few connections that fit the business you have now.

In six months it won't, because the business will have moved on:

• You've added a service the sorting has never seen.
• One partner wants their referrals handled differently.
• The standard reply reads slightly off, because your pricing or your tone has changed.
• The bar for "worth a call today" has shifted, because the team has grown or changed.

None of that is failure. It's what a live process does. So the question isn't whether it will need changing. It's what happens inside your company on the day it does.

Concretely: who changes the wording, the routing and the thresholds? Not who approves the change, and not who raises the request. Who opens the thing, makes the edit, and can tell afterwards whether it worked?

The answers you'll hear

Ask it, and you'll usually get one of three answers.

A name, with a caveat. For example: "Our ops lead, though she'd want a proper walkthrough of how the routing is set." That's a good answer. The caveat is the useful part: it shows you the gap while it's still easy to close.

A process instead of a person. "We'd raise it." "There's a support channel." "It's in the contract." All of that may be true, but describing how you'd ask someone else to make a change isn't the same as being able to make it.

The honest version. "Nobody, probably. We'd work around it." That's worth hearing early, because it's a forecast. Workarounds are how an automation quietly fades: one manual exception, then another, until it's handling a fraction of what it was built for and nobody has said so out loud.

If there's no name, that's your finding. It tells you this will be an appliance rather than a capability: something that produces results you like, on terms you can't adjust.

What you're really buying

• With a name, you own a process. When the business moves, the process moves with it, because someone on your team can move it.
• With no name, you're renting an outcome: results that keep arriving as long as nothing changes, plus a number to call when something does.

Renting can be a perfectly sensible choice. Some jobs are stable enough, or peripheral enough, that nobody on your team should spend attention on them. The trouble is ending up there by accident, and only finding out months later, when the business has moved and the system hasn't.

Name the person before you sign

The moment you name someone, the build gets better on its own:

• That person now has a stake in how easy it is to understand.
• It becomes natural for them to sit in while it's built, rather than receive it finished.
• The handover stops being a document and becomes a person who already knows where things are.

You may also discover that nobody on the team has the time or appetite. That's a real answer too, and much better to have now, because it changes what you should buy.

None of this needs a policy. It's one question, asked in a meeting you're already having, of the people already in the room. The answer tells you more about the next year than the demo did.

If you'd rather work this out on something live than in the abstract, that's what The Catalyst is for: one real problem, built with you, keys handed over.