I would rather hand a customer a working tool than teach them a process. That has always been true, and until recently it was expensive enough that it rarely happened.

It's close to free now. A CSM who can't write code can build something genuinely useful in an afternoon, and hand it to a customer who is stuck. That's a real improvement in what customer success can deliver, and I don't want to talk anyone out of it.

But watch what happens next.

Three People, Same Logic, Three Places

One CSM builds a tool in a no-code app to solve a recurring customer problem. Another CSM, working a different book, builds the same thing as a chat artifact. Someone in ops builds a proper agentic workflow that does the same job.

Same underlying logic, three interfaces, three places it can be changed. A tool for everything, and a system for nothing. And now three things go wrong at once.

It drifts. Each version gets improved independently. Six months later nobody can say which one reflects current thinking, so some of your customers are running last quarter's logic and nobody knows which ones.

It duplicates effort. Three people maintaining three versions of one thing. The tooling built to save time is now consuming it.

It walks out the door. The tool lives in a personal account. When that person leaves, and they will, their customers keep using something you can't reach, can't update, and can't switch off. You have a customer-facing dependency you don't control and possibly can't see.

This is shadow IT, except the shadow is pointed at your customers.

The Fix Is Ownership, Not Permission

The obvious response is to centralise: nobody builds anything without approval, everything goes through a queue.

That kills the thing that made it valuable. The reason a CSM can solve a customer problem on Tuesday is that they didn't have to ask. Put a gate in front of it and you're back to filing tickets and waiting, which is the situation this replaced.

So separate the two questions. Who is allowed to build, and who owns what gets built.

Building stays distributed. Ownership doesn't. Anything customer-facing lives in organizational accounts, is cataloged somewhere a new hire could find it, and has one version marked current. If two people have built the same thing, that's a merge, not a coexistence.

None of that slows anybody down on Tuesday. It just means Tuesday's work still exists in a year.

This Is the Argument for CS Ops

Customer success organizations have historically justified an ops function through reporting and tooling administration, which is a thin case and usually loses.

This is a better one. Your team is now producing customer-facing software. Not documents, not decks. Software, in the hands of customers, built by people whose job isn't building software and who will eventually work somewhere else.

Somebody has to own that. Not to gatekeep it, and not to build it all themselves, but to make sure what gets built belongs to the company and stays current. That's an operational function, and the cost of not having it doesn't show up until the day it shows up all at once.

The wider version of this argument, including the two related traps, is in the talk. There's also a short audit if you want to know how exposed you already are.