New business software is worth buying when the measurable improvement it creates is greater than the full cost and complexity of introducing it.

Not when the demo looks impressive.

Not because it has AI in the name.

Not because your competitor uses it.

Not because somebody at a networking event told you their CRM changed their life.

And definitely not because your current software annoys you occasionally.

The question is:

What gets measurably better if we introduce this?

Perhaps:

• Employees save meaningful time
• Fewer errors occur
• Information moves faster
• Customers receive a better service
• Capacity increases
• Management gets better information
• Revenue improves
• Margin improves
• Risk falls
• Several existing systems can disappear

Then ask:

What will it genuinely cost us to achieve that improvement?

Licence fees are only the beginning.

You also need to consider:

Implementation.

Migration.

Integrations.

Training.

Internal time.

Temporary productivity loss.

Customisation.

Support.

Maintenance.

Additional licences.

Data clean-up.

Running two systems during transition.

And eventually:

What happens if you want to leave?

A £400-a-month software product can easily become a considerably more expensive business decision.

That does not mean you shouldn't buy it.

It means you should evaluate software like an investment.

Not an app.

Start with the business problem

This is the single biggest rule.

Do not begin with:

“We need a new CRM.”

Why?

What is wrong?

Perhaps:

Salespeople do not record follow-ups.

Customer information sits in five places.

Nobody knows which opportunities are genuine.

Quotes take too long.

Management cannot forecast revenue.

Customer handovers are poor.

Good.

Now we have problems.

A CRM may solve some of them.

Or perhaps:

The existing CRM already does everything required and nobody uses it properly.

That happens too.

Buying different software does not automatically fix weak management.

The UK government's SME Digital Adoption Taskforce identified exactly this wider implementation challenge. Its 2025 final report said smaller firms frequently find technology adoption too difficult or costly, lack sufficient expertise and execution support, and perceive switching between technologies as risky. The government's June 2026 update continues to focus support on capability, cost and awareness rather than assuming software availability alone solves adoption.

Technology adoption is not primarily a shopping problem.

It is an organisational-change problem with software in the middle.

Do not ask what the software can do

Software demonstrations are dangerous.

Someone shares their screen.

Everything works perfectly.

Buttons glide.

Dashboards update.

Automations fire.

Apparently:

“This will completely transform how you work.”

Perhaps.

But a good salesperson can spend an hour showing you capabilities your company will never use.

Ask instead:

What problem are we specifically buying this to solve?

Then make the vendor demonstrate that.

If you want to reduce quotation turnaround from five days to one day, show me exactly how.

If you want managers to see project margin before jobs finish, show me.

If you want enquiries automatically allocated by region, demonstrate the workflow.

Do not spend an hour being impressed by features unrelated to the business case.

Define the current baseline

You cannot prove improvement if you do not know what happens today.

Suppose the problem is:

Sales administration takes too long.

How long?

Five hours a week?

Fifty?

Across how many people?

Or:

Our current system creates errors.

How many?

What do they cost?

Or:

Customers wait too long.

How long do they currently wait?

Before buying software, establish the baseline.

For example:

Salespeople collectively spend 22 hours a week entering and re-entering data.

Average quote turnaround is 3.8 days.

Twelve per cent of jobs start with missing customer information.

Finance spends 14 hours per month manually creating a management report.

Now implementation can be measured against something real.

Without a baseline, six months later everybody says:

“It definitely feels better.”

Maybe.

Maybe not.

Decide what success will look like before you sign

Write down the intended outcome.

For example:

Within three months of implementation, reduce manual sales administration from 22 hours per week to below 10 while maintaining data accuracy.

Or:

Reduce average quote turnaround from 3.8 days to below one working day.

Or:

Create one reliable customer record accessible to Sales, Operations and Finance and eliminate the three existing duplicated spreadsheets.

Now we know what the purchase is for.

This matters because software projects drift.

Originally:

Improve project visibility.

Six months later:

We have implemented the platform.

Those are not the same outcome.

Installing software is not success.

The business result is success.

Software can absolutely improve productivity

The potential is real.

The UK government's SME Digital Adoption Taskforce cites previous Enterprise Research Centre evidence suggesting firm-level productivity improvements of between 7 and 18 per cent for individual technologies, depending on what was adopted. That should not be treated as a promise that buying a CRM increases your productivity by a particular percentage, but it does reinforce the wider potential of well-chosen digital technology.

The OECD's April 2026 review of UK SME technology adoption similarly concluded that the UK performs relatively strongly in mature technologies such as cloud computing and data analytics, while adoption of management-support tools such as CRM and ERP remains more limited among smaller SMEs. It also stresses that skills, management capability and advisory support are important complements to technology adoption.

The important words are:

Well chosen.

And:

Well implemented.

Buying software and gaining value from software are two different events.

Calculate the value of time saved

This is usually the easiest benefit to quantify.

Suppose 12 employees each spend one hour a week on an administrative process the new system should remove.

That is:

12 hours per week.

Across 48 working weeks:

576 hours.

If the fully loaded cost of those employees averages £30 per hour, the theoretical labour value released is:

£17,280 per year.

Useful.

But be careful.

That does not mean £17,280 magically appears in the bank.

The employees are still employed.

You have created capacity.

Now ask:

What happens to those 576 hours?

Can employees:

Serve more customers?

Produce more output?

Avoid overtime?

Delay another hire?

Sell more?

Improve service?

Work more reasonable hours?

If the time simply gets absorbed by slightly more email, the financial return is much weaker.

Time saved only becomes commercially valuable when the business knows what the released capacity is for.

Separate cash savings from capacity savings

This distinction improves software business cases enormously.

Cashable savings

Costs genuinely disappear.

For example:

Software replaces another £8,000 annual subscription.

Temporary administration spend falls.

Overtime reduces.

External processing fees disappear.

A planned hire is no longer required.

Those savings can affect cash directly.

Capacity savings

Employees gain time.

Still valuable.

But the commercial value depends on what the capacity enables.

Perhaps five employees save four hours each week.

That could be transformative.

But only if leadership actually redirects the time.

Do not present every saved hour as immediate profit.

That is how ridiculous ROI calculations get created.

Revenue improvement can be valuable too

Software may create value by increasing revenue rather than reducing cost.

Perhaps a new CRM improves follow-up.

Quoting software reduces response time.

E-commerce enables customers to buy more easily.

Scheduling software increases the number of jobs completed.

Marketing automation improves conversion.

Fine.

Model it conservatively.

Suppose software is expected to generate:

Twenty additional qualified opportunities each month.

Historical conversion:

20 per cent.

Average gross profit per customer:

£2,000.

Theoretical additional monthly gross profit:

Eight thousand pounds.

Useful hypothesis.

Now test it.

Do not simply insert:

“Revenue increase: 20%”

into the software proposal because the vendor's brochure says customers grow faster.

Your business case should use your economics.

Error reduction has a value

Manual systems create mistakes.

Duplicate entry.

Incorrect addresses.

Missed follow-ups.

Incorrect orders.

Wrong prices.

Lost paperwork.

Payroll mistakes.

If software genuinely reduces recurring errors, estimate the value.

What does each error create?

Rework.

Credits.

Wasted labour.

Customer complaints.

Lost customers.

Management time.

Again, use a reasonable estimate.

Not fantasy.

If you currently spend £20,000 annually correcting a known category of error and a proven workflow can eliminate most of it, that belongs in the business case.

Better information has a value, but it is harder to calculate

This is where management software can create enormous value without obvious time savings.

Suppose the new system means managers can see:

Project margin.

Sales pipeline.

Capacity.

Debtors.

Stock.

Customer profitability.

in near real time.

Previously, decisions were made using information three weeks old.

What is better information worth?

Hard to calculate exactly.

But ask what decisions it improves.

Perhaps you identify margin leakage earlier.

Prevent over-recruitment.

Reduce stock.

Spot a cash problem.

Stop accepting unprofitable work.

Article #75 looked at exactly this issue through management accounts.

Information has value when it changes a decision.

A dashboard nobody uses has almost none.

Customer experience can improve too

Software may reduce:

Waiting.

Repeated questions.

Lost information.

Poor handovers.

Missed appointments.

Customers having to explain themselves twice.

That can create:

Retention.

Referrals.

Higher conversion.

Fewer complaints.

Do not assume every digital interaction automatically improves customer experience.

Some companies install software primarily to make life easier internally and accidentally make customers fight a chatbot for twenty minutes to speak to a human.

Measure customer impact from the customer's side too.

Now calculate the full cost

This is where the £499-a-month miracle starts becoming slightly more realistic.

Licence cost

Obvious.

But check the structure.

Per user?

Per location?

Per contact?

Per transaction?

Per feature?

Additional storage?

API access?

Premium support?

Security features?

AI credits?

Automation runs?

The attractive advertised price may cover the version nobody in a serious business actually needs.

The NCSC specifically warns organisations to check which licence tier includes the security features they require, because features such as mandatory multi-factor authentication or single sign-on may sit inside differently priced plans.

Compare the actual required licence.

Not the homepage price.

Implementation cost

Who sets it up?

Your employees?

The supplier?

A consultant?

How many hours?

Some systems are genuinely:

Create account.

Import contacts.

Go.

Others require months of work.

ERP.

Complex CRM.

Project-management systems.

Manufacturing software.

Finance systems.

Implementation can easily outweigh the first year's licence cost.

Include it.

Data migration

Where is the existing information?

Spreadsheets?

Old CRM?

Accounting platform?

Local drives?

Email?

Can it be exported?

Is it clean?

Who removes:

Duplicates?

Outdated records?

Incorrect fields?

Missing data?

One of the hidden costs of new software is discovering just how bloody awful the old data is.

Do not automatically migrate everything.

Moving ten years of rubbish into a beautiful new database merely produces beautifully organised rubbish.

Integration

What else does this system need to communicate with?

Accounting?

CRM?

Website?

Email?

Project management?

Payroll?

E-commerce?

Reporting?

Calendar?

The demo often shows:

“Yes, we integrate with X.”

What does that mean?

Native two-way integration?

One-way data transfer?

Requires middleware?

Premium plan?

Custom API work?

Only certain fields?

Integration is not binary.

Understand what actually moves.

The fourth-system problem

I see this constantly.

The company has:

CRM.

Project software.

Accounting software.

Spreadsheet.

Then buys another platform to:

“Bring everything together.”

It does not.

Now information exists in five places.

Every new system should answer:

What does this replace?

Not every new product needs to replace something.

Sometimes a genuinely new capability is required.

But if your software stack only ever expands, complexity eventually becomes its own operational problem.

One excellent test is:

Which existing tools disappear if we buy this?

If the answer is:

None,

I want to understand why.

Training cost

People need time to learn.

Who trains them?

How long?

Do managers understand the system deeply enough to support others?

What happens to productivity during the transition?

The OECD's 2026 review of technology adoption in UK SMEs emphasises the complementary importance of management and digital skills, while its wider 2026 SME work identifies time constraints, maintenance costs and skills gaps among the continuing barriers to effective technology implementation.

Training is not something you add at the end.

It is part of the investment.

Internal implementation time

This is frequently ignored because nobody sends you an invoice.

Your Operations Director spends:

40 hours designing workflows.

Finance spends:

20 hours validating data.

Sales spends:

15 hours testing.

Employees spend:

100 hours collectively in training.

That time has a cost.

More importantly, it displaces other work.

Include material internal time in the business case.

Otherwise internally implemented software always looks artificially cheap.

Temporary double-running

For a period, you may operate:

Old system.

New system.

Lovely.

Double entry.

Double licences.

Confusion.

Sometimes necessary while verifying migration and reducing operational risk.

Budget for it.

Do not assume the old platform switches off at midnight on Friday and everyone wakes Monday fully competent in the new one.

Customisation

Be careful here.

Software almost fits.

So:

Custom field.

Custom workflow.

Custom integration.

Custom report.

Custom development.

Six months later you have built a unique piece of software on top of somebody else's standard product.

Sometimes necessary.

But customisation creates:

Cost.

Maintenance.

Implementation risk.

Upgrade complications.

Supplier dependency.

Ask whether the business genuinely needs the custom process.

Or whether the process should change to fit a perfectly sensible standard workflow.

Do not spend £40,000 preserving a stupid process because:

“That's how we've always done it.”

Ongoing administration

Someone needs to own the system.

User accounts.

Permissions.

Fields.

Reports.

Automations.

Updates.

New-starter training.

Departing users.

Data quality.

Support tickets.

Software does not manage itself indefinitely.

An hour a week is still:

Roughly 50 hours a year.

Include ongoing administration where material.

Support cost

What happens when something breaks?

Is support included?

Email only?

Two-day response?

Dedicated account manager?

Paid premium support?

Third-party consultant?

A mission-critical platform with dreadful support creates operational risk.

The cheapest software is not cheap if three employees stop working every time an integration fails.

Contract commitment

Monthly?

Annual?

Three-year contract?

Auto-renewal?

How much notice to cancel?

Price increases?

Minimum users?

Read it.

The financial commitment is not necessarily:

£500 per month.

It may be:

£18,000 that cannot be cancelled for three years.

Different decision.

Switching cost

This is now significant enough that the UK government's SME Digital Adoption Taskforce specifically identifies switching risk, lock-in, unclear costs and data portability as barriers preventing smaller companies adopting digital tools. It recommends clearer, more transparent approaches to moving business data between software providers.

Before entering, ask how you get out.

Can you export:

Customers?

Documents?

Transactions?

History?

Custom fields?

Attachments?

Audit logs?

In what format?

What disappears when the subscription ends?

How long do they retain the data?

How hard would migration be?

An exit plan is not pessimism.

It improves your negotiating position and reduces dependency.

Avoid software lock-in you do not understand

Some lock-in is inevitable.

Employees learn the system.

Processes develop around it.

Integrations connect.

That is normal.

The issue is unrecognised lock-in.

You discover five years later that:

Data cannot be exported cleanly.

Customisations only work through one supplier.

No other platform accepts the format.

Your entire operation depends on the vendor.

Now a 20 per cent price increase becomes difficult to challenge.

Understand the dependency you are creating.

Adoption decides whether the ROI exists

This is perhaps more important than the software itself.

The system can be brilliant.

If people avoid it:

Return to spreadsheets.

Keep their own notes.

Do not complete fields.

Ignore workflows.

Use workarounds.

your theoretical ROI never appears.

The government's SME Digital Adoption Taskforce says effective management and leadership that actively support technology uptake and experimentation are important factors in successful SME adoption, and its evidence review notes that clear internal policies and leadership communication are associated with higher engagement with new technologies.

Software adoption is a management responsibility.

Not an IT announcement.

Ask employees before you buy

Especially the people doing the process every day.

Management says:

“This will save you loads of time.”

Employee says:

“Except it doesn't let us do the one thing we spend half the day doing.”

Useful.

Ask them:

Where does the current process fail?

What must the system do?

What would make it worse?

What exceptions occur?

Which feature really matters?

Employees should not necessarily choose the platform.

But ignoring the people who will use it is an impressive way to spend money badly.

Do not let one employee choose the entire company's software because they like it

The opposite problem.

Someone joins.

Says:

“At my last company we used HubThing Pro Enterprise Ultimate. It was amazing.”

Perhaps.

Different company.

Different processes.

Different scale.

Different requirements.

Evaluate against your business.

Software preference is not strategy.

User experience matters more than feature count

Software A has:

127 features.

Software B:

1. 
   

Which is better?

The one your company can use effectively.

A product can be incredibly powerful and operationally useless because normal employees need fourteen clicks to complete a routine task.

Watch real users perform real work during testing.

Do not judge usability from a polished demo conducted by somebody who has used the software every day for six years.

Configure before customising

This saves enormous pain.

Most decent business software has:

Settings.

Workflows.

Templates.

Permissions.

Fields.

Automations.

Try to solve the process through standard configuration before paying for bespoke development.

Standard software is usually:

Easier to maintain.

Easier to upgrade.

Better supported.

Easier to replace.

The more bespoke your implementation becomes, the more you should understand why that complexity is commercially justified.

Buy for the business you are becoming, not a fantasy company

You do need some headroom.

Replacing the system again in twelve months is expensive.

But do not buy enterprise software designed for:

2,000 employees

because:

“We'll grow into it.”

You currently have 27.

By the time you grow into it, the technology will probably have changed anyway.

Buy for the next realistic stage.

Not the imaginary multinational on your vision board.

Equally, do not knowingly buy something already too small

Cheap software becomes expensive when you outgrow it immediately.

Ask:

How many users can it handle?

Transactions?

Customers?

Projects?

Locations?

Data?

Automations?

What features appear at higher scale?

Does cost increase sensibly?

Could this support the next two or three years under realistic growth?

That is enough horizon for many SME decisions.

Evaluate security according to what the system will hold

A booking app holding:

Names.

Email addresses.

Appointment times.

is different from software holding:

Payroll.

Medical information.

Sensitive HR data.

Financial records.

Commercially sensitive technical documents.

The NCSC advises organisations to assess cloud providers according to how the service will be used and the sensitivity of the information involved, using either its full Cloud Security Principles or a lighter assessment where appropriate.

Security should be proportionate.

Not ignored.

Not turned into a six-month procurement exercise for a basic diary app either.

Ask basic security questions

Depending on the system and risk:

Does it support multi-factor authentication?

Can access be limited by role?

Can departing employees be removed easily?

Are administrative actions logged?

What backup and recovery exists?

How does the vendor handle security incidents?

What independent security assurance exists?

Where is the service hosted?

What happens during outages?

The NCSC recommends building confidence in the provider's security claims and looking for evidence rather than relying solely on marketing assertions.

You do not need to become a cyber-security specialist.

You do need appropriate due diligence.

If it processes personal information, you still have responsibilities

Moving customer or employee data into somebody else's software does not transfer all responsibility to them.

The ICO says organisations acting as controllers must only use processors that provide sufficient guarantees that appropriate technical and organisational measures are in place. The controller is responsible for assessing the processor's competence relative to the nature and risk of the processing and putting an appropriate processor contract in place.

The ICO also explicitly includes decisions about software, applications and services within data protection by design and by default.

For ordinary SME purchases, this often means making sure:

The supplier's data-processing terms make sense.

Security is appropriate.

Personal information is not being used in ways you did not expect.

Access and retention are understood.

If the data or processing is particularly sensitive or high risk, obtain suitable data-protection advice.

Look at supplier viability

This is often overlooked with SaaS products.

You build the company around the system.

What happens if the supplier:

Closes?

Gets acquired?

Stops supporting the product?

Changes strategy?

Raises prices dramatically?

Is this a large, established platform?

Early-stage startup?

One-person software company?

None is automatically wrong.

But dependency should influence due diligence.

The more critical the software, the more I care about the supplier's resilience.

Integration can matter more than individual features

Software rarely lives alone.

Imagine Product A is 15 per cent better at project management.

Product B integrates perfectly with:

CRM.

Finance.

Timesheets.

Reporting.

Product A requires three manual transfers every day.

Which creates the better operating system?

Possibly B.

Evaluate technology as part of the workflow.

Not as an isolated product.

The UK's 2026 digital-adoption work is increasingly recognising this systems issue too. The government's June 2026 update notes active work around systems integration alongside wider SME digital-adoption support.

A brilliant isolated tool can make the overall business worse.

One source of truth is valuable

Suppose:

Sales has its customer address.

Operations has another.

Finance has another.

Which one is correct?

That is a data-design problem.

Good software architecture should reduce unnecessary duplication.

Ask:

Where should customer data live?

Project data?

Financial data?

Employee data?

Which system is authoritative?

Which systems merely use it?

Then integrate where appropriate.

Without this, every new platform can create another slightly different version of reality.

Beware duplicate functionality

Review your software stack.

You may discover you currently pay for:

CRM with email campaigns.

Email platform with CRM features.

Project system with CRM features.

Accounting package with quoting.

Separate quoting software.

Microsoft 365.

Another file-storage system.

Three task-management products.

Two meeting-recording tools.

An AI subscription for almost every employee who saw something on TikTok.

Software accumulates.

Rarely does anyone remove it.

New purchase decisions should consider overlap.

Can we use something we already pay for?

Can this new system allow another tool to disappear?

Feature utilisation is a useful warning sign

Suppose your existing CRM can:

Automate follow-up.

Create reports.

Integrate with email.

Score opportunities.

Generate reminders.

Nobody uses any of it.

Management now wants a new CRM because:

“The current system doesn't do enough.”

Doesn't it?

Or hasn't the company implemented what it already bought?

Before replacing software, understand:

Which limitations are genuine?

Which are configuration?

Which are training?

Which are process?

Buying another product may simply restart the same cycle with a prettier interface.

Sometimes the software is not the problem

This is worth repeating.

The process is unclear.

Nobody owns it.

Standards differ.

Managers do not enforce it.

Employees have never been trained.

Data is poor.

Then leadership buys technology.

Six months later:

Same problem.

Different login screen.

This is why Article #70 began with:

Automate the process only once you understand the process.

Software should enable management.

It cannot replace management.

Run a pilot where possible

The 2025 Digital Adoption Taskforce recommended a test and learn approach to technology adoption support, and the government's 2026 update continues to use pilots and evidence-led evaluation in its SME digital programmes.

Businesses can use the same logic.

Do not necessarily roll the product across the entire company immediately.

Try:

One team.

One workflow.

One site.

One customer type.

One project.

Define success first.

Then test.

Does it actually:

Save time?

Reduce errors?

Improve visibility?

Work with real data?

Handle exceptions?

Integrate properly?

Do employees use it?

A two-week trial containing no real implementation tells you very little.

A structured pilot can tell you a lot.

Test the horrible scenarios, not only the happy path

Software demos always show:

Normal customer.

Normal order.

Normal invoice.

What about:

Customer changes address halfway through.

Duplicate account.

Refund.

Cancelled project.

Employee leaves.

Two locations share customer.

Incorrect data imported.

System unavailable.

Integration fails.

Unusual pricing.

Part payment.

Your business contains exceptions.

Test some.

A system that handles the perfect workflow beautifully and the real business badly is not a good system.

Measure actual adoption after launch

Do not stop at:

Go-live complete.

Thirty days later:

How many employees actually use it?

Are required fields completed?

Have spreadsheets returned?

Has data quality improved?

Has the promised time saving appeared?

Three months later:

Has the business outcome moved?

Implementation is not complete when the software turns on.

It is complete when the new operating behaviour becomes normal.

Calculate ROI again after implementation

You built an original business case.

Good.

Now compare it with reality.

Expected:

Save 20 hours a week.

Actual:

Seven.

Expected:

Reduce software stack by £12,000 annually.

Actual:

Old systems still running because nobody migrated properly.

Expected:

Increase capacity 15 per cent.

Actual:

No measurable change.

That does not automatically mean kill the system immediately.

Maybe adoption needs improving.

But update the business case.

Software should not become immune from scrutiny because management already spent money on it.

Do not fall for sunk cost

You spent:

£25,000 implementing.

Six months later it clearly does not work.

Someone says:

“We can't move away now. We've already spent £25,000.”

That money has already gone.

The relevant question is:

From today onwards, which option creates the better outcome?

Continue investing?

Fix implementation?

Replace it?

Return to previous system temporarily?

Past expenditure should inform learning.

Not imprison future decisions.

Do not keep rubbish software because changing feels painful

The Digital Adoption Taskforce specifically identifies high switching costs and perceived switching risk as barriers for SMEs.

That is understandable.

Changing software is disruptive.

Which is why businesses tolerate unsuitable systems for years.

But there is a cost to not changing too.

Every year:

Manual work.

Errors.

Poor information.

Workarounds.

Frustration.

Lost capacity.

Put a value on staying still as well.

The decision is not:

Change = cost. Stay = free.

Both options have costs.

Build a three-year view where the investment is significant

Suppose:

Implementation costs £12,000.

Annual licence £9,000.

Training and internal time £5,000 in year one.

The system replaces £4,000 of existing annual software.

It also creates an estimated £18,000 annual combination of cash savings and realistically usable additional capacity.

Year one:

Costs are heavier.

Years two and three:

Implementation drops away.

The picture changes.

A software investment with mediocre first-year ROI may be extremely sensible over three years.

Equally, a cheap first year can become expensive when promotional pricing ends.

Look beyond month one.

But do not force a financial ROI onto every system

Some software is infrastructure.

Cyber security.

Backup.

Compliance.

Accounting.

You may buy it because the alternative risk is unacceptable rather than because it produces £37,000 measurable annual profit.

That is fine.

Define the purpose accurately.

Perhaps the return is:

Risk reduction.

Control.

Compliance.

Business continuity.

Do not create fictional productivity savings merely because somebody insists every purchase needs a positive spreadsheet ROI.

The software business case

For any meaningful purchase, I would answer these questions.

What problem are we solving?

One sentence.

What happens today?

Current process and measurable baseline.

What specifically should improve?

Time?

Quality?

Capacity?

Revenue?

Information?

Risk?

How will we measure success?

A number wherever practical.

What is the full first-year cost?

Licence plus implementation, migration, integrations, training and internal time.

What is the ongoing annual cost?

Everything that remains after implementation.

What existing cost disappears?

Other software?

Overtime?

Admin?

External support?

What capacity is released?

And what are we going to do with it?

What new risk appears?

Cyber?

Data?

Supplier dependency?

Operational outage?

What needs integrating?

Be specific.

How will data move in?

And back out later?

Who owns implementation?

One person.

Who owns the system afterwards?

Also one person.

What happens if the pilot fails?

Know before you become emotionally attached.

If those questions produce good answers, the purchase is becoming defensible.

Green flags

I become more comfortable when:

The business problem is specific.

The existing process is understood.

A baseline exists.

Success measures are agreed.

Users have been involved.

The system replaces genuine manual work or other tools.

Implementation requirements are understood.

Integration has been tested properly.

Data migration is achievable.

Training is planned.

Security fits the risk.

The supplier is credible.

Exit and data portability are understood.

A pilot has produced useful evidence.

Someone owns the system.

The three-year economics make sense.

Most importantly:

The software makes the business simpler.

Red flags

I slow down when:

The purchase began with a demo rather than a business problem.

Nobody can explain what success means.

The ROI relies entirely on vague “efficiency”.

Employees already hate the proposed system.

The vendor says implementation is easy but has not seen your data.

Nobody knows which existing systems it replaces.

The platform duplicates software you already own.

Integrations are described as “possible” rather than demonstrated.

Massive customisation is required.

The contract is difficult to exit.

Data export is unclear.

Security answers are vague.

Every feature sits in a higher subscription tier.

The internal implementation owner has no time.

The company has a history of buying software and not using it.

Those do not automatically mean:

Do not buy it.

They mean:

Do not sign yet.

Software should remove complexity, not digitise it

This is where I would ultimately land.

Imagine your existing process contains:

Eight unnecessary steps.

Three handovers.

Two duplicated spreadsheets.

One pointless approval.

You buy software.

Now you have:

Eight digital steps.

Three automated handovers.

Two integrated spreadsheets.

One electronic pointless approval.

Congratulations.

You digitised the nonsense.

Technology should give you the opportunity to rethink the work.

What can disappear?

What can become standard?

What information only needs entering once?

What can happen automatically?

What decisions belong elsewhere?

That is where the real value appears.

The most expensive software is often the one nobody uses properly

Not the one with the highest licence fee.

The one where:

You pay.

Employees avoid it.

Management mistrusts the data.

Spreadsheets continue.

Work is duplicated.

Nobody switches it off because implementing it was painful.

That is expensive.

So judge software by business behaviour, not procurement.

What changes after implementation?

If nothing does, the technology has not transformed the company.

It has joined the subscription list.

Technology should create leverage

A good system lets:

The same team handle more work.

Managers make better decisions.

Customers get answers faster.

Employees stop duplicating administration.

Information move once.

Processes become more reliable.

The owner become less involved in routine activity.

That is leverage.

The objective is not:

More software.

It is:

A better operating system.

Sometimes that means buying something new.

Sometimes configuring what you already have.

Sometimes integrating two systems.

Sometimes deleting three.

And occasionally the best software investment you can make is deciding you do not need another bloody platform at all.