Fixing the Hidden Costs of Inefficient Workflows

First published as a white paper “How the Hidden Costs of Inefficient Workflows Drain SME Profits — and How to Fix Them” on the 2nd of November 2025 I’ll be serialising it here, on the Octane website.

Executive Summary

Britain’s small and medium-sized enterprises (SMEs) are the backbone of the economy, weighing in at 99.9% of all businesses. Yet they face persistent productivity challenges.

All too often SMEs are dependent on a patchwork of off-the-shelf tools (Microsoft 365, Google Workspace, CRMs, accounting software, et cetera), combined with written and printed collateral, to create fragile composite workflows, prone to becoming the cause of inefficiencies and wasted time. Workflows are essential and should not be the cause of uncertainties.

Small inefficiencies (“Task X” is discussed in the chapter: “The Obstacles”) are difficult to find and fix, add up to thousands of pounds per year in lost productivity, and risk data error, duplication, and loss. Drawing on evidence from UK government reports and SME studies, it shows that modest improvements to a workflow yield measurable productivity gains.

In this white paper we examine the often hidden inefficiencies, how and where they emerge, and provide actionable steps to mitigate against some of them. It also contrasts the limitations of generic, off-the-shelf tools with the benefits of a custom-built workflow designed to fit existing processes, that — in time — reduces costs while lowering risk.

The Landscape

First, a sobering fact:

SMBs lose 24 working days a year to financial admin:

“New Sage research shows SMBs lose 24 days a year to financial admin, the equivalent of working 13 months but getting paid for just 12. Time drains include invoicing, chasing payments and correcting errors.” — 13 months of work, 12 months of pay: the hidden admin burden on small businesses, via Sage.

24 days isn’t too far from the average annual leave (28 days).

But, there’s hope:

If 30% of SMEs reclaimed but one admin hour per week, it could add £6.6 billion to the UK economy:

“If these 30% of businesses could reclaim just one hour per week spent on admin, it could be worth £6.6bn to the UK economy annually.” — An extra hour of SMB productivity a week worth £7bn to UK economy, via Sage.

As owners of businesses, we’re still paying wages and tax on that time, be it lost or not.

Octane is a strong advocate of digital transformation:

Adopting digital tools like CRM, e-commerce, et cetera helps reduce the administrative burden:

“The SME Digital Adoption Taskforce report highlights that SMEs adopting basic productivity-enhancing digital technologies (CRM, cloud, etc.) can reduce administrative burdens and improve competitiveness.” — SME Digital Adoption Taskforce: final report, via Gov.uk

… but adding CRM here and a CMS there creates the additional burden of having to manage disparate services owned by different vendors each with their own policies regarding data that belongs to you.

What is a workflow?

A workflow is an agreed or established sequence of tasks designed to produce a specific result: a defined sequence of tasks that combine to produce a specific result. What we create, be it physical or digital, flows through a series of processes (containing one or several tasks). When these processes are optimal, the flow is linear, like time.

When these processes aren’t optimal, our creations become stuck, lost, broken, and sometimes go backwards. Understanding the reasons these processes are failing is a crucial step towards fixing them, but then there’s the question of time and talent, both of which are needed when attending to such things.

Often, the fix is to subscribe to a cloud service to mitigate against some portion of an errant process, accelerating those processes while also reducing overhead, but in doing so we forfeit a degree of control at the expense of convenience, incurring cost creep each time we do so.

In isolation, these cloud services are a boon to our businesses, but the challenge we face is combining them into something cohesive — almost like workflows within a workflow (the chapter: “Finding the Path” examines these challenges and how best to address them).

We must take enormous care with our data — where it flows, and who owns it once it settles in the cloud.

Cloud everything…

We’ve seen a dramatic shift in the software landscape, where we’ve gone from owning to licensing:

“In 2023, artificial intelligence (AI) was adopted by 9% of firms while cloud-based computing systems and applications were adopted by 69% of firms in the UK.” — Management practices and the adoption of technology and artificial intelligence in UK firms: 2023

While there are obvious benefits (pay-as-you-go subscription models, a reduction in on-premise infrastructure, improved collaboration and so on), we’re still using the same services most often from inside a web browser.

Before proceeding, let’s sort out some of the nomenclature. Saas is an acronym of Software as a Service. Cloud is the infrastructure, and SaaS is the software that lives on that infrastructure.

Artificial Intelligence

In the two years since those statistics were released, artificial intelligence has become a disruptive force — vilified and venerated in equal measure.

Much has been written about how AI has the potential to replace hundreds of thousands of people while washing away entire business sectors. In contrast, there are those who argue AI has the potential to introduce opportunities, to create new business models, and invent entire markets that would otherwise be impossible without it.

AI isn’t without its flaws (“hallucinations” as they’ve become known, which result in factual inaccuracies, and sometimes complete fictions), so it’s up to us to take care in how, when, and also where we use it.

But this shift speaks nothing to the foundational problems faced by the average small to medium-sized enterprise — while large enterprises are already throwing hundreds of millions of pounds at AI implementations, the SME instead has to be nimble, selective, and innovative.

Data governance

When thinking about what artificial intelligence is, as a thing, we tend to forget (or perhaps not understand that) we are its data model, and what we share today becomes its training data tomorrow.

We’re now seeing AI used on smartphones at home and in the workplace, blurring the divisions between the two. A common practice is to share a spreadsheet with an AI and ask questions about it, but what if that data is confidential, or contains Personally Identifiable Information (PII)?

From the perspective of data protection, these actions could constitute:

  • A transfer of personal data to a third-party data processor.
  • A potential cross-border data transfer (most AI providers are US-based).
  • A possible breach of confidentiality obligations to clients or staff.
  • In regulated sectors, a potential regulatory breach on its own.

Cloud software (using AI or not) comes with its own set of issues when it comes to data governance, often opaque at best, which isn’t reassuring.

In general, only share with a cloud product what is needed to accomplish the task at hand, and nothing else, and extend that thinking to AI, also (I’ll be expanding on these challenges in the chapter: “Finding the Path”).


Industrial Revolution 2.0

The wheels of change are relentless, and — in the end — the successful are those behind the wheels driving them forward while everyone else is in front of them, adapting to their path.

As AI wipes jobs, Google CEO Sundar Pichai says it’s up to everyday people to adapt accordingly: ‘We will have to work through societal disruption’

I assume everyone is up to date with their understanding of what happened during the Industrial Revolution? I ask because that’s something we tend to celebrate, in spite of the enormous social and economic upheaval.

Without turning this into a historical excursion, the Industrial Revolution swept aside the cottage industries of cotton weavers, forcing most of them into cities to work on the machines that had replaced their labours. Then the disruption turned to agriculture.

You get the idea.

Is there a modern parallel? Yes, sort of, but it’s already happened, in that everything we’ve accomplished has been transformed into training data undergirding these artificial intelligences.


We’re the cotton weavers and the farmers in front of the colossal wheels of change, careful to avoid their vast shadows, awaiting their next turn.


How do we respond to this? No doubt, as predicted, some types of businesses won’t survive this cycle of change. Everyone else, much like those Octane has had as a client since 1999 stand a chance because — and this is the ironic part — while their uniqueness has given them a competitive advantage it was also the same thing that made it difficult to build a sustainable workflow.

Allow me to rephrase: It’s the human component of their businesses that could insulate them from the disruptive nature of this emerging AI revolution.

What I’ve learned from using AI here at Octane are these 3 simple rules:

  • precision prompts;
  • specificity of task(s);
  • constant supervision.

Yes, the human component is what makes AI do amazing things.

I accept this could change, because that’s the nature of a revolution, and it’s up to us to be among those harnessing these wheels of change, but to also be mindful of those in front of them, and to not run them down in pursuit of progress and success.

Octane builds precision workflows for small and medium-sized enterprises (SMEs), who are the
backbone of the economy, weighing in at 99.9% of all businesses.

Download our White Paper to learn more about the hidden costs of inefficient workflows and
how to fix them.


We are AI

Some have predicted that the amount of AI-generated data and information is due to outnumber human-generated by up to 90% some time in 2026.

What about the cost of creation? $0.10 versus $10

When thinking about what AI-generated is, as a thing, we tend to forget (or perhaps not understand that) we humans are the data model, so the onus is on us.

At the moment, most AI agents don’t have access to up-to-the-minute data, but that’s bound to change (think of that as a tomorrow problem).

While these agents are more than capable of articulating statistics (hallucinations aside) that include us and what we’ve accomplished as some sort of homogenised average, they know nothing of the specifics that make us who we are: what we think; and how we think.

So, in time, I imagine that 10% would be where the valuable uniqueness is to be found, because it’d be the exact same place our inimitable human qualities would be found.


How I built Viaje using artificial intelligence

As a business that creates software for a living, the recent surge in the abilities of AI agents has been an intriguing thing to witness and explore — but, computer scientists at the Model Evaluation & Threat Research (METR), a non-profit research group have claimed:

“… we find that allowing AI actually increases completion time by 19 percent — AI tooling slowed developers down.”

The study involved 16 experienced developers who work on large, open source projects, and this limited sample size does at least warrant some scepticism.

Having used AI as an assistant for the last 5-6 months, I decided to build my own version of Google Maps, as a technical exercise, to explore — to a limited extent — the potential of AI.

How I built Viaje

I use Microsoft Visual Studio Code, known as an IDE, an integrated development environment that combines several different tools and services to aid in the process of software development.

Visual Studio Code allows me to chat with an AI agent, and there are several of them (known as “models”) to choose from — in this example, I switched between GPT-4o from Open AI, and Claude Sonnet 4 from Anthropic.

Each time I correspond with an agent, it’s considered a prompt, and like a conversation with a human, words have consequences. It’s possible to create new conversations with an agent, and then switch between them. If the task is complex, I use long-running conversations for the same reason we create an email thread, to retain the essential context of the conversation.

First, I explained to the agent what I wanted to build, supplemented with a list of features, the “stack” (the technologies I wanted to use), and used that as the basis of the continuing conversation with the agent.

Once I was confident it understood what I had in mind, I asked it to create a “README.md” file of what it understood. Here, a “README.md” is a file that contains essential information regarding a project, a common convention in software development.

Second, I asked it to create a plan of action: one each for the backend (the “business logic” of the application that resides on the host) and the frontend (the “presentation logic” of the application that runs in the web browser), which necessitated a bit of a discussion regarding the specifics of the two plans (some of the groups of tasks it had created were in the wrong order, while some were superfluous).

Third, I created an instructions document for the agent(s), most of which serving to add technical guard rails, nomenclature, and define specific versions of technologies.

Between the README, the plans, and the instructions, the agent had an excellent “context” from which to build. Put simple, each time I chatted with an agent, it would refer to the aforementioned documents to populate the context through which our conversation would be focused, refined, filtered and so on.

Fourth, we executed the plans. In the space of 3 weeks (non-contiguous time, that would have been about 4-5 days), I had a working product where I’d written less than 100 lines of code.

In addition to the usual spread of features (step-by-step navigation, local amenities, weather and so on), the agent and I added logic to detect if a destination was coastal using Ordnance Survey Boundary-Line data, and then the Environment Agency Tide Gauge API to find the actual tide times, throwing in tide prediction within a 24 hour window to supplement the route planning that allowed for choosing a date in the future.

Conclusions

Viaje was a success, but what did I learn?

  • AI is excellent at building plans. AI is excellent at executing specific tasks. AI is terrible if allowed to execute an entire plan of action (two, in this case) without human supervision.
  • There was a lot of overlap between the two plans, and the agent — in spite of understanding the connection — couldn’t implement something nuanced and structured alone, hence the constant guidance.
  • Each agent is different: I found that GPT-4o could do the bulk of the work until it encountered what were to it insurmountable problems, where I’d then have to switch to Claude Sonnet 4 to get things moving again.
  • A human-like absent mindedness would creep in from time to time where it would forget some technical specific, or that something that had already been done.
  • As the project grew the more precise its suggestions and recommendations become.
  • If allowed, the agent would keep adding and adding code!

How long would it have taken me to build Viaje without AI?

I chose some cutting edge technologies which would have incurred a steep learning curve, and with this in mind, I suspect 2-3 weeks of contiguous time, in stark contrast to the actual 4-5 days.

Would I recommend using AI?

I’ve enjoyed the most success with the AI agents when I followed these 3 simple rules:

  1. precision prompts;
  2. specificity of task(s);
  3. constant supervision.

In addition to software development, I’ve also used AI agents to do research, to brainstorm ideas and then attempt to validate their fitness. Here, point 2 is critical, in that it’s best to keep the tasks simple but additive, in that they’re chained: Task A contributes to Task B; Task B contributes to Task C and so on. Asking the agent to implement Tasks A through F is often when the problems begin.

AI sometimes gets things wrong, the same as we do, but the perception is that it shouldn’t. AI is not magic, and while that must seem obvious, a lot of the confusion I’ve seen has been in how people have attempted to use it, expecting magic things to happen.

AI is nascent, evolving, flawed, but also compelling and promising. Remember that we are the training data of AI.


When old is as good as new

Having the best technologies isn’t a guaranteed path to success. I’ve found that it’s the most appropriate technologies for the task at hand that make the biggest difference.

In 1961 Scotland, Professor Ian A. Richmond of Oxford University happened on a trove that no Briton was meant to discover. It had been hidden by, arguably, the most powerful and technologically innovative empire the world has ever seen. Forced into retreat by the Celts, a Roman legion had hidden this incalculably valuable technology. They’d gone to great lengths, picking it out of the remains of their destroyed fort, and burying it deep underground, where no one could ever find it. That is, until one archaeology professor, searching for knowledge, uncovered a weapon so powerful it might have changed the face of the Earth.

This invaluable trove was a bag of nails, but what set them apart was the fact that they were made from steel, which was — at the time — a near mythical alloy with almost magical qualities:

Scandinavian smiths discovered that the bones of the dead could grant them an edge.

Incorporating bones into the smithing process did in fact make Scandinavian swords stronger, but it wasn’t magic — it was technology. What ancient smiths could not have realized is that they were in fact mixing their bog iron with carbon to make a rudimentary form of steel.

Still, though, some do obsess on the newest thing — ChatGPT from OpenAI is one obvious example, but let’s not forget the metaverse, blockchain, Web3, and last but not least cryptocurrencies (cue the collective audible sigh of exasperation) — convinced that it’ll somehow give them an edge, like the steel swords of old. Problem is, when that new thing becomes that one big thing, from a distance, what I see is someone running around with a hammer hoping everything they find is going to be a nail.

What if those ancient Celts had found that bag of nails? Chances are, they wouldn’t have had a clue what they were made from or how to replicate them if they did.

I could replicate everything I do written in some variant of C or Python, which is having its moment at the moment, but that would involve an enormous amount of learning, and we could argue that it wouldn’t be the most effective use of such powerful programming languages.

Laboured analogies aside, the point I’m making here is that we, the software developers, database experts, and network specialists, DevOps engineers, and the countless technorati I’ve neglected to think of his Saturday morning, should focus instead on what is the best fit, not for the client (goodness no, not the client), but the task at hand.

I’m Wayne from Octane, and the most important thing I do is make people more effective at what they do. I build cloud applications for SMEs.