Who Fixes It When It Breaks

It usually comes about twenty minutes into the conversation, and it usually comes out apologetically, as though it were a rude thing to ask.

So who fixes it when it breaks?

It is the best question in the meeting, and the answer tells you more about what you are buying than anything on the proposal.

Three answers, and what each one costs you

"We do — that's what the retainer covers."

Fine, as long as you know what you are agreeing to. The system runs, but your ability to keep it running is rented. If the relationship ends, or the firm does, you are looking at a rebuild rather than a handover. That is not necessarily wrong — plenty of businesses rent things they could theoretically own — but it should be a decision rather than something you discover in year three.

"It runs on our platform, so it doesn't break."

This means the system is not yours. It is an account on somebody else's software with your data in it. Ask what happens to the workflows if you stop paying. If the answer is that they stop, you have bought a subscription with a setup fee, and the price of leaving goes up every month you stay.

"It runs in your tools, and here's the documentation."

This is the answer you want, and it is the least impressive to hear, because it does not sound like much of a service. It is also the position this firm argues for in how it thinks about the technology it builds, so treat the following as an interested party describing its own preference — and check it against whoever else you are talking to.

What "you own it" has to mean to be worth anything

Ownership gets claimed a lot and defined rarely. Concretely, it should mean four things.

The system runs in accounts you control — your CRM, your phone system, your calendar, your subscriptions, paid on your card. Not a middleware account someone else administers on your behalf.

Somebody in your business can see how it works. Not necessarily rebuild it — see it. There is a document that says what happens when an inquiry arrives, in what order, and what each piece is doing. If that document does not exist, nobody can maintain the thing, including the people who built it, eighteen months later.

The failure modes are written down. Every automated process has states where it does something unhelpful. A system that has never been described in terms of what it does wrong has not been thought about properly.

Someone is named. Not a company — a person inside your business who is responsible for noticing when it stops behaving. This is the part most projects skip, and it is the part that decides whether a small problem is caught in a day or discovered in a quarter.

The thing that actually breaks

In practice, these systems rarely break in the dramatic sense. They drift.

A field gets renamed in the CRM and a routing rule silently stops matching. Someone adds a new inquiry source and it is not wired in, so those inquiries land nowhere. A team member leaves and their calendar link stays in the booking flow. The system does not error. It carries on doing exactly what it was told, which is now slightly wrong.

Drift is why the named person matters more than the support contract. A support contract responds to a reported problem. Drift does not report itself — someone has to notice that the numbers look a bit thin this month and go looking.

Which is the same failure that created the original problem, one layer up. If nobody owns the inquiry, inquiries go missing. If nobody owns the system, the system quietly stops catching them. It is the pattern described in most automation fails because nobody designed the workflow first, arriving a year later than usual.

How to ask it so you get a real answer

"Who fixes it when it breaks" is easy to answer reassuringly. These are harder:

• What specifically stops working if we stop paying you? The answer should be nothing, or a very short list you can live with.
• Show me the document a new operations hire would read. If it does not exist yet, when will it, and is it in the scope you are signing?
• What are the three most likely ways this misbehaves, and what does each look like from our side? Anyone who has built and run one of these can answer immediately. Anyone who has only sold one cannot.
• Who on our side is named as the owner? If the answer is that you do not need one, that is the wrong answer.

None of that requires you to be technical. It requires you to be unembarrassed about asking, which is a lower bar and, for some reason, a harder one.

The honest reason this question is asked apologetically is that it sounds like distrust. It is not. It is the same question you would ask about a boiler, a lease, or a hire — what happens to this when the person who set it up is not here.

Anyone who takes it badly has told you something useful.

Several of the other questions worth asking before you sign are collected in the FAQ, including the ones where the honest answer is that you do not need this.