Your Software Holds the Data. But Does It Know How Your Business Works?

What if the biggest opportunity in your business isn't making people's jobs easier, but questioning why they're doing those jobs in the first place?

I had two conversations with businesses recently that went in remarkably similar directions.

Both businesses were looking for ways to improve. Both had experienced people, existing systems and perfectly reasonable ideas about what they needed.

And in both conversations, I asked a question that made people look at me as though I'd lost my mind. The questions were different, but they came from exactly the same place.

Why are we assuming a person needs to do this at all?

"Why have you even got a button?"

The first conversation was with the leadership team of an established service business.

They'd invested in technology, were exploring AI and had already made some useful improvements to the way their teams worked. In fact, they were quite happy with some of their software.

One improvement they were particularly pleased with involved their CRM.

When an existing customer wanted to extend their services, someone previously had to create another sales opportunity and enter much of the same information again.

They'd introduced a button that allowed staff to copy an existing opportunity instead.

It was a sensible improvement. Less typing, less duplication and less time spent on administration.

But I asked: "Why have you even got a button?"

There was a pause.

The customer had already agreed to buy more services. Those services would be scheduled, delivered and invoiced.

So why did somebody need to create another sales opportunity?

The answer was that the business wanted to track additional sales to existing customers, understand where revenue was coming from and measure performance. All perfectly legitimate requirements.

But surely that information could be established from the work the business was already doing?

Why did somebody have to record the same event again, simply so another system could report on it?

They'd worked out how to make the task quicker. I was questioning why the task existed.

One of the people in the room acknowledged that this was a paradigm shift. He needed a moment to process it. I could see why.

They hadn't done anything foolish. They'd identified an irritating task, invested in improving it and achieved a genuine time saving.

But they'd approached the problem assuming the task was necessary. And that's the assumption I wanted to challenge.

"What if this isn't the job of a person?"

A few days earlier, I'd visited a business that sells, restores and maintains forklifts.

I was talking to the person responsible for sourcing and organising parts for the workshop.

He has an extraordinary amount of knowledge.

He knows which components are needed for different machines, which suppliers can provide them and which parts from different manufacturers can be used interchangeably.

He also knows when to order them and that's an important distinction.

Order everything immediately and the business ties up cash in stock it doesn't yet need. Order too late and the mechanics are left waiting, delaying jobs and potentially upsetting customers.

He balances parts availability, supplier lead times, the workshop schedule and cash flow, trying to get the right components delivered as close as practical to when they're needed.

Then he coordinates those orders and deliveries with the mechanics to keep everything moving. It's a skilled job, requiring a remarkable amount of experience.

So I asked him what would happen if he wasn't there. Not necessarily permanently. What if he went on holiday, became ill or was unavailable for an extended period?

The answer was that parts wouldn't get ordered.

They'd already struggled to recruit somebody who could do the job properly, so finding a replacement wasn't straightforward either.

That's a substantial business risk.

Here was an operation dependent on the knowledge of one person. The business might have information about its machines, suppliers, purchases and inventory, but the understanding of how to use all that information to make decisions lived largely in his head.

So I asked: "What if this isn't the job of a person?"

He looked at me as though I was mad. And I understood why.

He'd just spent time explaining how complicated the job was. They'd struggled to find anybody else capable of doing it properly. Surely that demonstrated how much they needed someone with his particular expertise?

But I wasn't suggesting his knowledge wasn't valuable. Quite the opposite.

I was suggesting that his knowledge was far too valuable to exist only in his head.

What if he could teach the system instead?

Imagine approaching the parts operation differently.

Initially, the system wouldn't know enough to make many useful decisions. It might have records of previous orders, stock and suppliers, but that doesn't mean it understands why one component is preferable to another, or why a particular supplier was chosen.

That's where the experienced employee becomes critical. As he works, we could start capturing not just what he orders, but the knowledge behind those decisions.

Which parts are interchangeable? Which suppliers are reliable? What delivery times matter? Why is one option preferable to another? How does the workshop schedule affect when something should be purchased?

Some of those things could become straightforward business rules. Other decisions might require more sophisticated matching, recommendations or AI.

Initially, he'd continue making the decisions himself. Then the system could start making suggestions.

Perhaps it recommends a component and supplier for a particular restoration. He checks the recommendation. If it's right, he confirms it. If it's wrong, he explains why.

Maybe the alternative component fits but isn't sufficiently reliable. Maybe the cheaper supplier won't deliver in time. Maybe a purchase should be delayed because the mechanics won't need that part until the following week.

That feedback is valuable.

Over time, with more orders, more validated decisions and more evidence of the outcomes, the system could make increasingly reliable recommendations.

For unfamiliar situations, it might have very little confidence. For decisions it had handled successfully many times before, it could have a well-established basis for making the right recommendation.

And eventually, once the business trusted its performance in particular situations, why would someone need to approve every routine order?

The system could simply get on with it, within agreed limits.

It could continue bringing unusual requirements, uncertain substitutions or significant purchasing decisions back to a person.

Importantly, we'd measure whether its recommendations were correct, rather than blindly trusting an AI-generated confidence score.

And none of this would need to happen overnight. The system would gradually take on more responsibility as it proved itself capable.

The employee's expertise would be essential throughout. He'd help capture the knowledge, validate the recommendations and identify the exceptions that genuinely need human judgement.

Rather than spending his day making every routine decision, he could concentrate on the difficult ones, improving supplier relationships and making the operation work better.

The business would become less dependent on his constant involvement, without losing the value of his experience.

And it wouldn't need to find another person with exactly the same knowledge simply to handle more work.

We've built systems that record work. But people still drive it.

These were two very different businesses, yet their challenges had something fundamental in common.

In the first, people were performing administrative work because the systems expected them to.

In the second, someone was making important operational decisions because the systems didn't know how.

Both businesses had software. Both had information. But in both cases, people were responsible for driving the process forward.

And I think that describes an enormous amount of what happens in businesses every day.

Someone records a sale in a CRM. Someone else arranges the work. Another person checks that it's been completed. Somebody tells accounts to raise an invoice. Management receives a report and decides what action is needed.

Each department might have perfectly good software. The systems might even be integrated.

But the business still depends on people knowing which tasks need doing, when they need doing and who needs telling.

We've become very good at building systems that store information about work.

We haven't always built systems that understand enough about the work to move it forward.

Before computers, people needed to pass information between departments. We had forms, filing cabinets, job sheets and reports.

Then we digitised them. The forms became screens. The filing cabinets became databases. The job sheets became digital records.

We made them easier to use, but often preserved the processes that made them necessary. And over time, those processes became so familiar that we stopped questioning them.

This isn't really about AI

AI is opening up some extraordinary possibilities, particularly when it comes to understanding information, recognising patterns and making recommendations. But it's not the starting point.

If a completed job has already been approved, automatically triggering the next step might require nothing more complicated than a well-designed workflow. If a supplier has agreed prices and lead times, deciding when to order something may largely be a matter of applying business rules.

AI might be useful for identifying equivalent components, interpreting unfamiliar information or assisting with decisions where the rules aren't so straightforward. But using AI to make an unnecessary task quicker is still automating an unnecessary task.

The real question is what needs to happen in the business, and why we're asking people to make it happen manually.

Sometimes the answer will involve AI. Sometimes it'll involve bespoke software, integration or improving something that already exists.

And sometimes the answer is simply to stop doing something.

The opportunity is bigger than saving a few minutes

When businesses talk about improving efficiency, the conversation often centres on time savings. How long does this take? How much quicker could we make it?

Those are useful questions, but they don't necessarily reveal the biggest opportunity.

In the service business, we discussed how much more work they might be able to take on if a substantial proportion of their administration disappeared.

The leadership team recognised that they could potentially grow considerably without increasing their headcount at anything like the same rate.

In the forklift business, the benefits were different but just as commercially significant.

Less dependence on one indispensable employee. Better coordination between parts ordering and workshop schedules. Less cash unnecessarily tied up in stock. Fewer delays waiting for purchasing decisions.

And the potential to grow without having to recruit another person with years of specialist knowledge.

These aren't outcomes that can be promised simply by introducing new software. They require a proper understanding of the operation, careful implementation and evidence that the changes are working.

But they illustrate something important.

The biggest opportunity may not be making an existing job more efficient. It may be changing how much of that job a person needs to do at all.

Two questions worth asking in your business

The next time someone suggests automating a task, improving a system or hiring another person, I'd encourage you to ask two questions.

Does this work actually need doing?

And if it does: Does it need a person to do it?

Sometimes the answer to both will be yes. People are extraordinarily good at solving problems, building relationships, exercising judgement and handling situations that don't fit neatly into predefined rules. That's where we want their attention.

But people shouldn't have to spend their days repeatedly telling systems things those systems already know. Nor should an entire operation depend on one employee remembering every detail of how it works.

Your existing software might already be excellent. You might have invested heavily in automation. You might even have AI working across parts of your business.

But it's still worth asking whether your systems are supporting the way you've always worked, or helping you discover a better way to work altogether.

Your software might hold all the data about your business. But does it know how your business works?

At Initforthe, we help businesses rethink how work happens, then build and connect the software needed to make it happen more effectively.

Sometimes that starts with software that's getting in the way. Sometimes it starts with ambitions to grow, concerns about recruitment or an operation that's become too dependent on particular people.

We don't assume the answer is another application, more AI or replacing systems that already work.

We start by understanding what the business is trying to achieve, what its people are doing to make that happen, and which parts of that work should really require them.

Because the biggest improvement isn't always making the work easier. Sometimes it's making sure the work happens without anybody having to do it.

Your Software Holds the Data. But Does It Know How Your Business Works?.

"Why have you even got a button?"

"What if this isn't the job of a person?"

What if he could teach the system instead?

We've built systems that record work. But people still drive it.

This isn't really about AI

The opportunity is bigger than saving a few minutes

Two questions worth asking in your business

How much capacity is your business leaving behind?

More posts.

AI can write the code. Your business still needs an engineer

Four interruptions, two lost hours and the process your people shouldn’t be driving

The approval takes five minutes. The waiting costs far more.