Support is the part
you cannot demo.

Every other criterion can be tested before you sign. You can watch the software work, read the contract, check the integrations and ring a reference. Support is the one thing bought purely on description, and the only one you will use every week for years. That is why it sits near the bottom of most selection matrices with three words next to it, and why it decides more outcomes than the feature list above it.

Why support gets under-weighted

It is not carelessness. A scoring matrix rewards what can be evidenced, and support resists evidence in a way features do not. A vendor can show you a variation being raised in eleven seconds. Nobody can show you what happens at ten to four on a Thursday when the thing will not do what it did yesterday and there are two hours left to get an application out.

So the row gets filled in with whatever the vendor wrote in the tender response, everybody agrees it looks fine, and the decision is made on the parts that could be demonstrated. Six months later the same firm is explaining to its board that the software was not the problem, which is usually true and never the point.

How a rollout actually dies

Almost never with a bug. It goes like this.

Week three. A contracts manager needs to raise a variation against a job that was set up wrong in week one. She cannot see how. She raises a ticket at half past two and gets an acknowledgement with a case reference. The variation cannot wait for the case reference, so it goes in a spreadsheet, because that is where variations went for fifteen years before any of this started.

Thursday brings a reply asking her to confirm the version she is on. By then the spreadsheet has three more variations in it and has quietly become the way this gets done. Nobody escalates, because nothing has gone wrong exactly. Six weeks later half the firm is working the old way for half the job, the data in the system is a partial record of a whole month, and the renewal conversation is about whether the software was any good.

The software was fine. The gap was four hours wide on a Tuesday afternoon, and it was never closed.

Nobody cancels a rollout. They stop using it instead, one workaround at a time, and call it a software problem at renewal.

What the support words on a spec sheet mean

Five phrases do most of the work in a support section, and none of them means what a reader assumes.

• Response time. Time to an acknowledgement, not to an answer. A four-hour response target sits perfectly comfortably alongside a fortnight to a fix, because the two measure different things.
• Resolution time. The number that matters, which is why it is far less often quoted. Ask for it, and ask for the median rather than the target.
• 24/7 support. Sometimes a staffed desk. Sometimes a monitored inbox, with anything real waiting for the morning regardless. The phrase does not distinguish between the two, so ask which one you are buying.
• Tiered support. A first line that works from a script and holds a queue. It handles volume well, and it is also why a question specific to your setup can take several exchanges to reach somebody who recognises it.
• Named account manager. A commercial relationship, not a technical one. Useful at renewal, rarely useful at ten to four on a Thursday.

None of these is dishonest. They describe real models that work for products with tens of thousands of customers. They are worth decoding because the words sound like a promise about the Thursday, and they are not one.

The boundary nobody asks about

Here is the question that separates support arrangements, and almost nobody puts it in a tender: what happens when the problem is real, it has stopped work, and it is not your product?

The spreadsheet the QS has used for six years has stopped adding up. The Microsoft 365 account will not send, so nothing has gone out since yesterday afternoon. There is a printer in the site office that nobody can talk to. Every one of those stops the job as effectively as a bug would, and every ordinary support agreement is scoped to the vendor's own software, which is reasonable, defensible, and leaves the firm holding a problem it cannot fix.

We take those. Firms bring us spreadsheets that have stopped adding up, 365 accounts that will not send and printers nobody can talk to. None of it is Unibuild and we look at it anyway. That is not a favour extended now and again when there is time. It is what the arrangement is meant to be, and it is written here because it is easy to promise and hard to fake: ask any vendor for the last three times they helped with something outside their own product, and listen to whether the examples are specific.

What to ask any vendor, including us

Seven questions. All short, all answerable in a sentence, and the ones that produce a careful non-answer tell you as much as the rest.

1. Who answers when I ring? Name the role, not the department.
2. Is there a queue and a case number in front of that person, or not?
3. What is the median time to a useful answer, as opposed to the response target in the contract?
4. Can I reach somebody who is able to change the product, and how often does that actually happen?
5. What is out of scope, and what do you do when the problem is real but not yours?
6. Who covers August, and Christmas?
7. What does support look like in year three, when we are no longer a new customer?

The sixth is not a trick. Every support model has a holiday problem and the honest ones can describe theirs.

The limits of the way we do it

A small team answering the phone directly does not behave like a large support organisation, and the differences are not all in our favour.

There is no round-the-clock cover. Formal hours are UK working hours; replies outside them are common in practice but they are not a promise and should not be bought as one. There is no contractual service level with penalties attached, which some procurement processes require and ours would fail. And a model built on reaching the people who built the software depends on there being few enough clients for that to stay true, which is a fair thing to test: ask what happens to it as the client list grows, and expect a specific answer rather than a reassuring one.

If you need a 24-hour desk across time zones, or an SLA with liquidated damages in it, that is a real requirement and we are the wrong shape for it. Better to find that out now than in month three.

Where to start, on Monday

Ring the support line of every vendor on your shortlist before you buy anything from any of them. Not the sales number. The support number, as a customer would, with a real question about something the product does.

Time how long it takes to reach a person, then how long it takes to reach one who understands the question. Write both numbers down next to the licence cost. That one afternoon will tell you more about the next three years than the whole demo did, and it is the only part of the decision you can test for free.