Choosing software for a trade firm,
and what to actually compare.

Feature lists do not separate these products, because in a demo they all work. What separates them is the pricing model, whether site will actually use it, how long until it is genuinely running, what happens to your data if you leave, and what happens when you need something the product does not do. Compare those five and the field narrows quickly.

Why every demo goes well

A demonstration is a rehearsed path through prepared data by somebody who uses the product every day. It is not dishonest and it is not useless, but it tells you very little, because the parts that fail in real life are the parts a demo is structured to avoid: the difficult job, the operative who will not use it, the month three when the novelty has gone.

So the useful question in a demo is not whether the software can do a thing. It nearly always can. It is what happens on the day it is inconvenient.

One practical technique that costs nothing: bring the job you are least sure about rather than a clean one. Ask them to model the messy subcontract, the variation nobody instructed properly, the package that went wrong. A vendor who can show you their product handling your worst job is telling you something a demonstration of their best case cannot.

The five things that actually differ

1. The pricing model, not the price. Per user, tiered bands, per active project, or flat for the organisation. The model decides how the bill behaves as you grow and, more importantly, whether you will end up rationing access. The detail is in what trade and construction software actually costs.
2. Whether site will use it. The single biggest determinant of whether any of this works, and almost nothing to do with the office half of the product. Ask specifically what they have to type to open it on a wet Monday, and whose name is on it (more on that below). Every one of those is a legitimate reason not to do it today, and the failure mode is documented in why field rollouts stall in week three.
3. Time to actually running. Not time to an account being created. Ask how long until hours are coming off site through it and applications are being produced from it, and what the customer has to do in that period. Every implementation costs you your own people's attention, and a vendor who says none is required is describing a rollout that will fail.
4. What happens if you leave. The question nobody asks in a demo. Can you export your jobs, documents, photographs and history, in what format, how quickly, and at what cost. A vendor comfortable answering that is telling you something about how they expect to keep you.
5. What happens when you need something it does not do. Covered under the questions that decide fit, because it is the most revealing question available to a buyer.

Every vendor can tell you what their product does. The ones worth shortlisting can tell you what happens when you need something it does not.

A sixth belongs on that list and will not sit on it, because it cannot be scored the way the other five can. Everything above is demonstrable: you can watch it, read it or ring a reference about it. What the support arrangement is actually worth is bought on description and only found out afterwards, which is why it is worth testing on its own before you sign.

Five questions vendors answer badly

Ask these in every demo and write the answers down. The pattern of answers separates products more reliably than the features do.

• What will we still be doing in a spreadsheet after this? The answer tells you how far the product will bend to fit your process.
• Which of your customers stopped using it, and why? Vendors have churn. One who claims otherwise is either very new or not answering.
• What does it cost in year three? Including the uplift mechanism at renewal.
• What happens when the person who championed this leaves? Adoption usually survives on one internal advocate, and the vendor should have a view on what happens when that person moves on.
• Can I speak to a customer like us who is not on your case studies page? The reference nobody prepared is worth more than the one who was.

Two questions that decide fit

Two more belong in writing before any demo, because the answers are commercial rather than demonstrable. A vendor can show you a screen. It cannot show you what happens in month four.

Whose name is on the staff app your operatives install? An operative asked to install their employer's app is being asked to do something ordinary. Asked to install a product from a company they have never heard of, on their own phone, they have a reason to leave it until later. Ask to see the app store listing your operatives would search for. It tells you whose name they will see before anybody installs anything.

Are changes to fit your process included, or charged? Every firm finds something in month four: an approval route, a valuation form, a report the directors want in their own words. Ask whether that change goes on a roadmap, onto a day rate, or into the fee you already pay. The answer is the real cost of fit, and it is rarely in the quotation unless somebody asks.

Both questions sit beside the rest of the decision in the buyer's guide to construction management software for UK contractors. That guide also compares named vendors on what their bill scales with.

Scope: one system or several

There is a genuine argument on both sides and the honest answer depends on your business.

Several specialist tools can each be better at their own job than one platform is at any of them, and if one part of your business is genuinely unusual, a specialist product for that part may be the right call. The cost is the rekeying between them and the fact that no single place holds the position.

One system trades some specialist depth for the position being in one place and the data being entered once. That trade is usually right for a contracting business where the pain is assembling a picture rather than any single function being weak, and usually wrong for a firm with one very unusual requirement and otherwise simple needs.

The test worth applying: write down the three questions you most often cannot answer quickly. If they all need information from different tools, integration is your problem and one system is the answer. If they all sit inside one function that your current tool does badly, buy a better version of that tool.

Making the decision

Three practical points that shorten most procurements.

Decide who this is for before you look. A product chosen by the office for the office and then handed to site is the commonest way this money is wasted. If site is the group whose behaviour has to change, site has to be in the decision.

Score against your own list, not the vendor's. Write your five criteria before the first demo and score every product against them. Vendors are skilled at moving a conversation onto the ground where they are strongest, and a written list is the only defence.

Be honest about whether you need it yet. Compare the cost against what the current arrangement actually costs you, in hours assembling positions, applications paid short, retention never chased and plant hired twice. If that number is smaller than the licence, the answer is no, and any vendor telling you otherwise is selling.

Where to start, on Monday

Before you book a single demo, write two lists. The three questions about your business you most often cannot answer quickly, and the five criteria you will score products against. Half an hour, and it changes every conversation that follows.

Then, when you do book demos, bring your worst job rather than your cleanest. What you learn from watching somebody handle it is worth more than the rest of the meeting.