Consultative IT vs transactional: I build solutions for needs, not products off a shelf

Here's where I land on consultative IT vs transactional, and I'll say it before I justify it: a transactional provider sells you a thing, a consultative one solves your problem, and the difference shows up in your bank account about a year later. Transactional is fine when you already know the exact answer. The trouble is that most small businesses don't, so they get sold the box that's easiest to sell rather than the one that fits, and they wear the cost of that mismatch for years. I work the other way around. I find out what you're actually trying to do, what you've already got, and where it's really hurting, then I build the smallest thing that fixes it. Often that's cheaper than what you walked in expecting to buy. Sometimes it's a free setting and no purchase at all.

What "off the shelf" actually costs you

A shelf product is engineered to sell to the most people, not to suit you. That's not a criticism of the product; it's just what it's for. It has to be the safe pick for a huge range of buyers, which means it's specced to the imaginary average customer. The catch is that almost nobody is average. You've got a double-brick building, or a back shed the signal won't reach, or three staff and a busy season, or a tight month and a job that can't wait. The off-the-shelf answer over-delivers on the stuff you'll never touch and quietly under-delivers on the one thing that actually matters to you, and you pay full freight for both halves.

I see it most with the all-in-one upsell: the bigger plan, the fancier box, the "future-proof" tier. Future-proofing is the word people reach for to justify selling you more than you need today. Real future-proofing is buying something you can add to, not capacity you'll never grow into: the same logic that runs through owning your stack instead of renting it, where the rented version keeps charging you for headroom you don't use.

Needs first, product never

The order matters more than anything else here. Transactional starts at the product and works backwards to a reason you should own it. Consultative starts at the need and only reaches a product if one's genuinely required. When I sit down with someone, I'm not thinking about what I can sell; I'm asking three things:

• What are you actually trying to do? Not "I need new WiFi": the job underneath it. Staff dropping off calls in the back office is a different problem from a warehouse that needs coverage, and they have different, cheaper answers.
• What have you already got? Half the time there's gear on site that does the job once it's set up properly. Throwing it out to sell you a replacement is the transactional reflex. Making it work is usually the right call and the cheaper one.
• What'll still make sense in three years? The right answer is the one you don't have to redo. That's not the most expensive option; it's the one that fits how you'll actually grow.

Answer those honestly and the solution mostly designs itself. And here's the part that makes people suspicious until they see it: the answer is frequently less than they expected. A re-configuration instead of a replacement. One properly-placed piece of kit instead of a system. Sometimes a setting change and a "you don't need to buy anything." Most people have been conditioned to expect every IT conversation to end in a quote, so a recommendation to spend nothing reads as a trick. It isn't. It's just what working to the need looks like when the need is small.

The anti-sales-pitch: prove it before you sign

This is the bit that separates real consulting from consulting-flavoured selling. If I'm confident a thing will work, I should be willing to show you it working before you pay for it. So wherever it can be done, I'd rather set it up small, run it for a week or two in your actual environment, and let you see the result. Then you decide. A prove-it trial moves the risk off you and onto me, which is exactly where it belongs, because I'm the one claiming it'll work.

Compare that to the standard transactional sequence: get the signature, install the gear, and find out together afterwards whether it solved anything, by which point it's your problem, your contract, and your sunk cost. The signature should come after the proof, not instead of it. My blunt rule of thumb, and you can use it on anyone, not just me: if a provider won't let you see it working before you commit, they're either not sure it will or banking on it being too late by the time you find out. Either way, that's your answer.

Trials aren't always possible; some jobs are all-or-nothing, and some gear can't be run on appro. But the instinct carries everywhere: no lock-in you can't walk away from, no contract built to outlast its usefulness, no charging you for a year of something that didn't deliver in the first month. If it can be proven, prove it. If it can't, the next best thing is being able to leave cleanly when it disappoints.

Why I can afford to talk you out of the sale

The obvious objection is that this sounds like a great way to go broke. If you keep recommending the cheap fix and the no-purchase option, where's the money? The honest answer is that it's a different model, not charity. I'd rather make a fair margin on advice and on jobs that genuinely need doing than a fat one on flogging boxes, because box margin only works if you keep selling boxes, and that quietly turns every problem into a reason to sell another one. I've been in IT long enough to watch that game play out: the provider whose income depends on selling product finds, over time, that every customer needs more product. It's rarely even dishonesty. It's just what the incentive does to your judgement.

Take the margin off the box and put it on the outcome, and your judgement comes back. The free setting change becomes a perfectly good answer, because you're not paid to overlook it. The work I do across phones, networking, cameras and the rest only holds together because the advice is straight. The day I start steering people toward whatever's most profitable to sell, the trust the whole thing runs on is gone, and it doesn't come back.

It's the same instinct a good tradesman has

None of this is a clever new business theory. It's how any decent trade has always worked. A good sparky doesn't rewire the whole house when a circuit needs sorting. A good mechanic tells you the noise is nothing and sends you home. You trust them precisely because they don't reach for the biggest invoice every time, so you go back for years and send them your mates. IT got away from that somewhere along the line: it dressed the sales pitch up in enough jargon that customers couldn't tell advice from a transaction, and a lot of the industry quietly leaned into the confusion. I'd rather explain the why in plain English and let you make the call with your eyes open. That's the whole ethos behind everything I write here: built by a builder, run on principle, and honest about what you actually need.

What this looks like for you

If we work together, the first conversation is questions, not a quote. You'll hear what your real options are, including the cheap one and the do-nothing one, and you'll hear which I'd actually pick if it were my money and my business. Where it can be proven first, it will be. Where you already own something that does the job, we'll make it work before we replace it. And you won't be locked into anything you can't leave. That's not a sales technique I've bolted on to seem trustworthy; it's just what building to the need requires, and it's the only way I've ever wanted to do it.

Frequently asked questions

Got a problem you've been quoted a big box for, and a nagging feeling it's more than you need? That's the conversation I like having. Tell me what you're actually trying to do and what you've already got, and I'll tell you straight what I'd do in your shoes, including if the honest answer is "you don't need to buy anything." Tell me what you're trying to sort out and we'll start from the need, not a catalogue.