Most business owners who've hired a technology consultant before have a story. The consultant came in, ran a few workshops, produced a very thick document, handed it over, and disappeared. Six months later, nothing had changed — except the invoice had been paid.
That experience has made a lot of senior leaders understandably sceptical about what a technology consultant actually does. And honestly? The scepticism is warranted. A lot of consulting is theatre. Frameworks dressed up as insight. Recommendations that protect the consultant rather than the client.
This post is for the people who've been burned before, or who are simply trying to work out whether bringing in a technology consultant is actually worth it. We're going to walk through what a real day of consulting work looks like — not the idealised version from a brochure, but the actual rhythm of the work, the decisions made, the friction encountered, and the value produced.
We'll use Daybrain Consult as the lens because it's what we know. But the principles here apply to any serious technology consulting engagement.
Before the Day Starts: What Good Preparation Actually Involves
The visible part of consulting — the meetings, the workshops, the presentations — is built on preparation that most clients never see. And the quality of that preparation is usually the clearest signal of whether a consulting team knows what they're doing.
Before a Daybrain Consult engagement begins in earnest, we spend time doing something that sounds simple but is surprisingly rare: reading the business properly. That means reviewing whatever documentation exists — org charts, process maps, contracts with existing software vendors, any previous audits or change programmes. It means speaking to stakeholders before the formal kick-off so we're not walking into a room cold.
It also means forming a preliminary hypothesis. Not a conclusion — that would be premature — but a working theory about where the friction in the business is likely to be, based on what we already know about the sector, the size of the company, and the symptoms described in the initial conversation.
The Preliminary Hypothesis
A good technology consultant arrives with a hypothesis, not a blank notebook. The hypothesis might be wrong — and a good consultant updates it readily when the evidence contradicts it — but arriving without one means the early stages of an engagement are wasted on orientation that should have happened before the clock started.
For a typical SME engagement, the preliminary hypothesis usually touches three areas: where time is being lost to manual or duplicated work, where decision-making is being slowed by poor data, and where existing software is being worked around rather than worked with. These aren't always the right areas. But they're the right starting point for most businesses under about 200 people.
Stakeholder Mapping
Before day one, we also map the stakeholders. Not just who's in the room, but who has influence over technology decisions, who will be affected by change, and who is likely to resist it. The last category is not a problem to be eliminated — it's information. Resistance usually tells you where the real operational complexity lives.
Understanding the politics of a business before you start is not cynical. It's necessary. Technology decisions in most organisations are never purely technical. They're wrapped up in departmental budgets, personal histories with previous systems, and interpersonal dynamics that no process map will ever show you.
Morning: The Diagnostic Conversation
The first formal session of a consulting day is usually a diagnostic conversation. Not a workshop — that word has become so overloaded with bad connotations that it's almost useless now. A conversation. With the people who actually do the work.
This is where a lot of consulting firms get it wrong. They speak to the senior leadership, get a picture of the business from the top, and design solutions for that picture. The problem is that the picture from the top is almost always incomplete. Senior leaders know the outcomes — the delays, the costs, the customer complaints. They often don't know the cause, because the cause is buried in the day-to-day operational reality that nobody has time to explain to the board.
So we talk to the people doing the work. The operations manager who's been maintaining a workaround spreadsheet for three years because the CRM doesn't handle their specific process. The estimator who spends four hours on a Monday morning pulling together data from three different systems to produce a report that should take twenty minutes. The accounts administrator who reconciles two software platforms manually every month because they don't integrate.
What We're Listening For
In these conversations, we're listening for three specific things:
Workarounds. Any time someone describes how they do a task, and it involves a spreadsheet that isn't connected to anything, a manual copy-paste step, or a process that depends entirely on one person's knowledge — that's a workaround. Workarounds are the most honest signal of where a system has failed the business.
Volume language. When someone says 'we do that all the time' or 'that happens constantly' or 'I probably spend half my week on that' — those phrases are data. Not precise data, but directionally accurate data. They tell you where effort is concentrated, and effort concentration is usually where the economic case for change is strongest.
Resignation. The most important signal of all is when someone says 'that's just how it is' or 'we've always done it that way.' That's not acceptance. That's exhaustion. It tells you that the problem has been raised before and nothing happened, which means there's likely a political or organisational dimension to the friction, not just a technical one.
A Worked Example: The Manufacturing Client
To make this concrete: in a recent engagement with a UK-based manufacturing business, the brief from the managing director was straightforward. They wanted to 'improve their data infrastructure.' Reasonable ask, reasonable budget.
In the morning diagnostic conversations — with the production manager, the logistics coordinator, and the finance team — a different picture emerged. The business had three software systems: an ERP for production, a separate logistics platform, and an accounting tool. None of them talked to each other. The person who sat in the middle, manually moving data between all three, was a single operations coordinator who had developed such specific institutional knowledge that the business would be in serious difficulty if she left.
The MD's framing of 'improve data infrastructure' was technically correct. But the actual problem was a fragile, human-dependent data pipeline built on top of three disconnected systems. The solution wasn't a data infrastructure project. It was a system integration and process redesign project — with a completely different scope, timeline, and budget implication.
That distinction only became visible in the morning conversations. It would never have surfaced from a top-down briefing alone.
Midday: Mapping the Actual State
After the diagnostic conversations, the work shifts to documentation. Not the kind of documentation that produces a beautiful diagram that nobody ever looks at again — the kind that captures what is actually happening, as opposed to what the process map says should be happening.
There's a version of this that consultants sometimes call 'as-is process mapping,' and it can become its own kind of theatre if you're not careful. The risk is that you end up documenting the idealised version of the current state — what people think they do — rather than the real version, which is messier and more honest.
The way to avoid that is to map in the room, with the people doing the work, in real time. Walk through a real example. Not a hypothetical. Take an actual job, an actual order, an actual customer enquiry — and follow it through the business step by step, noting every system it touches, every person who handles it, every point where it could stall or get lost.
The Five Questions for Every Step
For each step in a process, we ask five questions:
- What triggers this step? (An email? A system notification? A phone call? Someone walking over to someone else's desk?)
- What information is needed to complete it?
- Where does that information come from?
- Where does the output go?
- What happens when it goes wrong?
The fifth question is the most important. The failure mode of a process tells you more about its fragility than the normal-state description ever will. If the answer to 'what happens when it goes wrong' is 'it depends on who notices first' or 'usually Sarah sorts it out' — that's a process that exists on a knife-edge.
This kind of mapping is slower than drawing a flowchart from a briefing document. It takes longer. It requires the right people in the room. But it produces a picture of the business that is actually accurate, which means that any recommendations built on top of it are grounded in reality rather than assumption.
If you're evaluating whether to automate parts of your operation, this is also the stage where you start to quantify the cost of the current state. Our post on calculating automation ROI walks through how to do that rigorously — it's worth reading before you commission any automation work, because most business cases in this space are built on optimistic guesswork.
Afternoon: From Diagnosis to Direction
By the afternoon of a full consulting day, the shape of the problem is usually clear. Not always the solution — that takes longer — but the shape. Where the friction is. What's causing it. What would need to change to remove it.
This is where the consulting work becomes genuinely difficult, because there are almost always multiple possible directions, and they have very different implications for cost, risk, and timeline. The consultant's job at this point is not to present options neutrally and let the client choose. That's abdication dressed up as objectivity. The job is to form a view — a real view, based on the evidence — and be prepared to defend it.
The Build vs Buy Decision
One of the most common decision points in a technology consulting engagement is whether to build a custom solution or buy an existing product. This decision is rarely obvious, and it's one that gets made badly more often than almost any other technology decision.
The mistake most businesses make is framing it as a cost question: buying is cheaper than building, therefore buy. That framing ignores several things: the ongoing cost of a SaaS subscription for something that was never built for your specific use case, the time cost of adapting your processes to fit software rather than the other way around, and the accumulation of workarounds that happens when a system almost but doesn't quite fit.
We've written a detailed framework for this decision at Build vs Buy in 2026. The short version is that the right question isn't 'is building more expensive?' It's 'what is the total cost of each option over three years, including the cost of the compromises the bought solution will force you to make?'
In the afternoon session, we typically work through this decision with the senior stakeholders, using the morning's diagnostic findings as the input. The goal is to arrive at a direction — not a finalised plan, but a direction — that everyone in the room understands and can commit to exploring.
What Direction-Setting Actually Looks Like
Direction-setting in a consulting context is not the same as solution design. Solution design is precise: specific systems, specific integrations, specific timelines, specific costs. Direction-setting is one level above that: this is the class of solution we're pursuing, this is why, and these are the assumptions we're making that would need to be validated before we commit to the detail.
The output of a good direction-setting session is usually a short document — not a deck, a document — that captures the problem as diagnosed, the direction recommended, the rationale for it, the key assumptions, and the next steps needed to validate those assumptions and move to solution design.
That document should be readable by someone who wasn't in the room. It should not require context to understand. And it should be honest about uncertainty — if there are things we don't yet know that would materially affect the recommendation, those things should be named explicitly, not glossed over.
Late Afternoon: The Uncomfortable Conversations
Most consulting days include at least one uncomfortable conversation. A good consultant doesn't avoid these. They plan for them.
The uncomfortable conversations in technology consulting usually fall into a few categories:
The Software You're Paying For Isn't Working
Businesses accumulate software subscriptions the way offices accumulate furniture. Things get bought, people adapt to them or around them, and the original justification gets forgotten. By the time a consultant arrives, there are often systems being paid for that are either barely used or actively disliked by the people who are supposed to use them.
Telling a client that a system they spent significant money implementing isn't fit for purpose is uncomfortable. There's usually someone in the room who championed that system. But it's necessary. Continuing to invest in making a bad system work better is almost always worse than acknowledging the sunk cost and starting again with something more appropriate.
This is particularly common in businesses that have grown quickly. Software that was right for a 15-person company is often wrong for a 60-person company. The processes have changed, the volume has changed, the reporting requirements have changed — but the system hasn't, and neither has the habit of using it.
The Problem Is People, Not Technology
Sometimes the diagnostic work makes it clear that the problem isn't the technology — it's how the technology is being used, or who owns it, or how decisions about it get made. This is a harder conversation than 'you need better software,' because it involves organisational and management issues that feel more personal.
A technology consultant who tells you that the fix is always more technology is either naive or commercially motivated. Sometimes the right recommendation is: the technology you have is adequate, but you need clearer ownership, better training, or a different internal process for managing change. That recommendation is worth less to a consulting firm in terms of project revenue. It's worth more to the client.
The Timeline Is Wrong
Senior leaders often arrive at a consulting engagement with a timeline already formed. 'We want this done by Q3.' The timeline is usually based on a business milestone — an investor meeting, a contract renewal, a peak trading period — rather than on any realistic assessment of what the work involves.
Part of a consultant's job is to be honest when the timeline is unrealistic. Not to be obstructive, but because a project that's rushed to meet an arbitrary deadline usually fails, and a failed project sets back technology adoption in a business far more than a delayed one.
End of Day: What Gets Written Down and Why It Matters
The end of a consulting day is where a lot of value either gets captured or gets lost. Conversations that aren't documented become memories, and memories are selective and divergent. Two people in the same meeting will remember different things a week later. Three weeks later, the gap widens further.
Good consulting documentation is not about creating a paper trail. It's about making the thinking durable. It's about ensuring that the decisions made in the room survive the room — that they can be picked up by someone who wasn't there, interrogated, challenged, and built on.
The One-Page Summary
At the end of a consulting day, we produce a one-page summary. Not fifty pages. One page. It captures the key findings from the day, the direction agreed, the open questions that need resolution, and the next steps with owners and timescales.
One page is not a constraint that limits what can be expressed. It's a discipline that forces clarity. If you can't summarise the key findings of a day's work in a single page, you don't yet understand them well enough. The expanded version — the full diagnostic report — comes later, when the thinking has been tested and sharpened.
The Assumptions Register
One of the most underused tools in technology consulting is the assumptions register. Every recommendation rests on assumptions — about budget, about technical feasibility, about organisational appetite for change, about the accuracy of the information provided. If those assumptions turn out to be wrong, the recommendation may also be wrong.
Naming the assumptions explicitly, and tracking whether they're validated or invalidated as the engagement progresses, is the most honest way to manage the uncertainty that is inherent in all technology decisions. It also protects both the client and the consultant: if a key assumption changes, both parties can see immediately what the downstream implications are.
The Daybrain Consult Model: What Makes It Different
Daybrain Consult is built around a specific belief: that the gap between diagnosis and implementation is where most consulting value gets lost. Most consulting engagements end with a report. The report is handed over. The client then has to figure out how to implement the recommendations, usually without the people who made them.
We don't operate that way. The diagnostic work and the implementation work are connected, and the same people who identified the problem are involved in designing and delivering the solution. That continuity matters more than it might seem. When something unexpected surfaces during implementation — and something always does — the people who did the diagnostic work have the context to adapt quickly, rather than having to re-learn the business from scratch.
Where the solution involves custom software — which it often does for businesses with genuinely specific operational processes — Daybrain Digital can design and build it. That's not a sales pitch. It's a structural advantage: a consulting firm that can also build means the recommendation is never constrained by what already exists in the market. If the right answer is a bespoke tool, that option is on the table.
You can read more about how that plays out in practice in our post on what makes an AI product actually get used — the adoption question is as relevant to custom software as it is to off-the-shelf AI tools, and the principles are the same.
A Day in Numbers: What Actually Gets Done
To make this tangible, here's a rough breakdown of how time is spent across a full consulting day:
| Activity | Time | Output |
|---|---|---|
| Preparation and review | 1.5 hrs (before arrival) | Preliminary hypothesis, stakeholder map |
| Morning diagnostic conversations | 2.5 hrs | Workaround inventory, friction map |
| Process mapping session | 2 hrs | As-is process documentation for 2–4 key processes |
| Direction-setting workshop | 1.5 hrs | Agreed direction, key assumptions identified |
| Stakeholder debrief | 45 mins | Alignment on findings, next steps agreed |
| Documentation and synthesis | 1.5 hrs (after) | One-page summary, assumptions register, follow-up actions |
That's roughly ten hours of focused work, most of which is invisible to the client. What the client sees is about six hours of meetings and conversations. What produces the value is the preparation before and the synthesis after.
What Does This Cost, and Is It Worth It?
This is the question that most business owners want answered and most consultants avoid. So let's answer it directly.
A day of senior technology consulting in the UK — done properly, with real preparation and real follow-through — costs somewhere between £1,500 and £4,000 depending on the firm and the seniority of the people involved. That's not a small amount for a growing business. It requires justification.
The justification is almost always available, but it requires someone to do the arithmetic honestly. If the diagnostic work identifies a process that's costing a business twenty hours a week in manual effort — at a fully loaded cost of, say, £35 per hour — that's £700 per week, or roughly £35,000 per year. A day of consulting that identifies that problem and points toward a solution that halves that cost has already paid for itself many times over, before any solution has been built.
The calculation gets more interesting when you account for the cost of doing nothing — the compounding cost of a business running on inadequate systems as it grows, the increasing fragility of human-dependent processes as volume increases, the drag on every hire who joins a business with slow, frustrating tools.
For businesses with genuinely specific operational models — trades contractors, field service businesses, specialist manufacturers — the economics of the right technology investment are often surprisingly compelling. Our post on why trades businesses don't need expensive SaaS subscriptions explores one version of this argument in detail.
When It Is Not Worth It
There are situations where hiring a technology consultant is not the right move, and a consultant worth hiring will tell you so.
If the business doesn't yet have a clear enough view of its own processes to engage meaningfully in a diagnostic conversation, the consulting work will be premature. You'll spend money identifying that you need to do more internal work before you can make technology decisions — which is a valid finding, but an expensive way to arrive at it.
If the senior leadership isn't prepared to act on the findings — if the decision to hire a consultant is a way of deferring a decision rather than making one — then the engagement will produce a report that sits on a shelf. That's a waste of everyone's time and the client's money.
And if the problem is genuinely simple — you need a better accounting tool, you want to move your files to the cloud — you probably don't need a consultant. You need a recommendation, which you can get from a trusted peer or a decent technology broker.
The Direct Takeaway
A day of consulting with Daybrain Consult is not a day of presentations, frameworks, and jargon. It's a day of structured diagnostic work — conversations with the people who actually do the work, honest documentation of what's broken and why, and a clear direction toward what to do about it.
The value is not in the deliverable at the end. It's in the quality of the understanding built during the day, and the decisions that become possible because of it. A business that understands its own operational friction clearly — and has a credible direction for addressing it — is in a fundamentally different position than one that knows something is wrong but can't say precisely what or why.
If you're at the point where technology decisions are being made on instinct, or deferred because nobody has the full picture, or made and then quietly reversed six months later — that's the signal that a structured day of diagnostic work would be worth it.
The questions to ask any consultant you're considering are simple: What will you produce by the end of day one? Who will you need to speak to, and why? What happens after the report is delivered? If the answers are vague, keep looking.
If you want to know what the answers look like when they're specific, Daybrain Consult is a reasonable place to start.