What does a digital transformation consultant do, and how to choose one

The phrase "digital transformation consultant" covers an enormous range. It describes a team that hands over a strategy deck after a few months, a systems integrator that replaces your ERP over a year or two, and a small group that sits with your operations team and moves work onto software one process at a time. They use the same title and charge very different fees for very different outcomes.

We do digital transformation consulting at Gezora, in the third style, so weigh what follows with that in mind.

What a digital transformation consultant does

A consultant maps how work runs today, finds where the manual effort sits, decides what to change and in what order, helps make the change, and leaves your team able to run what results.

Mapping means following real work through the organization: how an order is entered, who approves it, which systems it passes through, where it waits. Finding the manual effort means counting, because the hours spent copying data between systems or chasing approvals are rarely tracked, since everyone treats them as part of the job. Consultants differ most on the decision: a new platform, a changed process, or software agents on the manual steps. Help goes from writing a report to running the thing. Many programs fall apart at handover, when nobody has been named to run what was built.

Three kinds of digital transformation consulting services

Advisory firms

Digital transformation strategy consulting produces a diagnosis and a roadmap: where you stand against peers, which capabilities to build, in what order. It brings an outside view and material ready for the board, which can be exactly what a leadership team needs. The risk is that it ends in documents.

Platform replacement

Some programs exist to choose and implement a new ERP, CRM or finance platform. That is the right answer when a system has reached the end of its life.

Incremental programs that put agents on manual work

A third style leaves your systems of record where they are and moves manual steps onto AI agents, one process at a time, so there is no migration. Its limits are real: it cannot fix a process nobody agrees on, and it will not rescue a platform that is beyond saving.

Why so many programs disappoint

Programs usually disappoint for ordinary reasons, and technology is rarely one of them. We have left out failure rates on purpose: the ones you see quoted are hard to trace to a source.

The common story is a platform that goes in while the work stays the same. The manual steps move into the new system unchanged, the hours never come back, and nobody can show otherwise because nobody recorded how long things took before. Add a cutover weekend that stakes the whole operation on one date and you have a familiar recipe for failure. Much of the rest comes down to people. Who supervises what was built once the consultants leave? Too often no one has been trained to. Scope also tends to follow the loudest department, so the first phase automates what one senior person complained about while the costliest process waits.

What changes when agents lead the program

A program led by agents puts AI agents on the manual steps inside the systems you already run, under human supervision. The ERP, the CRM and the finance system stay where they are, which removes the migration and the cutover weekend. Each phase takes one process and builds an agent for it, with written limits on what the agent may decide alone. (Building the agents is a subject of its own, and our post on custom AI agent development goes through it.)

Then comes shadow mode. Say an agent matches delivery notes to purchase orders. In shadow mode it records the match it would make while your team keeps matching by hand, and somebody reads every disagreement before the agent is allowed to act. It starts acting only on the steps where the two agreed. Because the systems of record never moved, switching an agent off sends that step back to your team. Anything the agent already wrote stays in the record, so each agent's actions should be logged where your team can review them.

Agents add something new to supervise, so each one needs a named owner and a threshold above which it asks before acting. They also depend on the process underneath being sound.

A phase by phase example

An invented example shows the shape of a phased program: a distributor with about four hundred staff, an ERP, a CRM and a finance system, and a lot of manual copying between them. The figures are illustrative.

Phase zero is the map. Over a few weeks the team follows eight processes through the organization and counts the manual hours behind each, department by department. The three that cost the most hours (purchase order matching, customer order entry and returns handling) are scored on volume, how rule bound they are, and what a mistake costs. Purchase order matching wins: high volume, clear rules, cheap errors.

Phase one builds a matching agent with written limits and runs it in shadow mode for a few weeks. Each disagreement between the agent and the team is logged with the delivery note and the purchase order side by side. By the end, agreement on routine matches is high, and the disagreements turn out to be mostly missing data in the ERP, which the team fixes first. The agent then starts acting on the routine class, with exceptions going to a named buyer.

Phase two takes customer order entry from email. It's messier, so the agent starts with one customer's format and widens from there. Phase three picks up returns. After each phase the scoring is redone, because the phase before taught the team things the map couldn't, such as how bad the ERP's master data really was.

Not every phase works. Suppose the phase two agent can't reach acceptable accuracy on the messier email formats. The program then has the evidence to say so, narrow the scope or stop, and move the budget to the next process. Only that phase's budget is at risk.

At the end, the ERP, the CRM and the finance system are where they started. Three processes now run with a fraction of the manual handling, and the team reads exception reports where it used to retype orders; every agent has an owner and a written boundary.

Who decides what

Programs stall when nobody is sure who can say yes, so settle it early and in writing. A small, senior steering group meets monthly to approve the phase order and the budget for the next phase, and it's the only place scope changes. Each phase has a process owner from the business, who signs off the boundaries for that process and has the authority to say that a result is good enough. Each agent has a named owner who reads its exceptions and answers when it asks. And one person on the consultant's side is accountable for the plan, which a committee can't be.

Write down what needs sign off after launch as well. A change to what an agent may decide alone is a change to risk. It should go through the process owner and be recorded, and it shouldn't slip in as a small tweak to a prompt. Skip this and months in, nobody can say who approved the current limits.

What stays your decision

However good the consultant is, some decisions should never be handed to them. How much risk the business accepts in an automated step belongs to the people who answer for the outcome. So does the shape of the team afterwards, including which roles change and how people are supported through it. Commitments to vendors, contracts that outlast the program, and what customer or employee data may leave your environment are yours to sign. And the order of the phases, even when the scoring suggests one, is a business decision that a spreadsheet only informs. If a consultant tries to take any of these off your plate, a polite objection is in order.

Bringing people along

The people whose work changes should hear about it from you before they hear it as a rumor. Say what is being automated and why, which decisions stay with people, and how their role changes. Be honest about uncertainty: if you don't know yet how the team will look in a year, say that, and say how you'll decide. Pretending the program has no effect on jobs persuades nobody, and the people with other options may leave first.

Involve them in the work. The people who retype and chase know where the process breaks, and their corrections make the agents better. Give them the exception queue and the authority to change the rules that cause it, and train them to supervise. A team that supervises agents learns to spot when one is wrong. A team that is simply told the agents exist learns to route around them. Share the measurements as they arrive, including the awkward ones, so people can see what the program is doing and push back early.

How to choose between digital transformation consulting firms

What a good proposal contains

A proposal shows how the consultant thinks. A good one has a scope you could hold them to: the processes in the first phase, what "done" means for each, and what is out of scope. It names a baseline and how it will be measured, so the result can be checked. Each phase is listed with what it delivers, a point at which you can stop, and what you will own at each stop. The people who will do the work are named as well as the firm. Its assumptions are stated plainly, such as access to systems, availability of process owners and the quality of the data, along with what happens to the schedule if they don't hold. The handover is described: what documentation, runbooks and training you receive, and who runs the agents afterwards. Pricing runs phase by phase, with running costs separate from the build.

Be wary of a long list of capabilities and client logos with no mention of what will be running at the end. The deliverables section tells you more than the credentials slide.

Red flags in the first month

The first month shows you what the engagement will be. Worrying signs include a consultant who spent two weeks with executives and still can't name the process owners or the people who do the work, and deliverables that are all slides with no requests for system access. Others are a scope that grows without a conversation about trade offs, a baseline that keeps getting postponed, and executives on your side who can't be reached when a decision is needed. Most of these can still be recovered if you raise them in the first month.

Talking to references

Ask for references from a company of similar size and complexity, and ask them what a pitch doesn't cover. What was running six months after the consultants left, and who was running it? How did the real cost compare with the proposal, and why? What would they do differently? Did the baseline get measured, and did the results hold? What happened the first time something went wrong? A reference who answers those easily has probably had a good experience. One who hesitates over "who was running it" is likely telling you the handover was weak.

What to prepare before the first call

You will get more from a consultant, and spend less on their time, if you arrive with a few things. Bring a list of the processes you suspect cost the most hours, even if the list is a guess, and the systems each one touches. Name who owns each process day to day. Add a rough count of manual hours per week where you have one, and say so where you do not. And list the constraints that cannot move: regulation, uptime requirements, anything written into a contract.

It also helps to ask each team lead where their people retype or chase things. Few teams count those hours, so the first useful number often comes from that conversation, well before any tool runs. Our post on how to automate business processes shows how to trace a few real cases and measure the gap between touch time and elapsed time.

What the consultant will need from you

The work goes faster when you supply a few things on time. Access to systems comes first, because nothing can be mapped or built without it, and sorting out accounts and approvals often takes longer than people expect. Process owners need a few hours a week for interviews and review, and one executive has to be reachable when a decision blocks the work. Agree all of this in the first week and write it down.

Counting the manual hours

The hour count is the number the rest of the program leans on, so it deserves a method. Ask each team to log, for one typical week, every stretch of retyping, chasing, reconciling and copying between systems, in five minute blocks and without judging whether it's necessary. Add the logs up per process. Then check the result against reality: if the sum for one department exceeds the hours its people work, the logs are inflated, and if it comes to almost nothing, people may have left out the small stuff.

Treat the total as an estimate with a range. Some of the hours can't be removed, since a person still has to check the exceptions, and some will shift to somebody else's desk. The point of the count is to rank the processes by where the hours go, and to give the baseline a number that people recognize as roughly right when they see it.

What drives the cost

Cost depends on how many processes move and how many systems each one touches, plus how much supervision has to be designed around the agents. Anyone who quotes a firm number before seeing your operation is guessing. Ask for the first phase to be scoped and priced on its own, with a clear point where you can stop and decide whether to go on. A single long program at a single price commits you before you know whether the first process worked.

How we work

Our digital transformation consulting is phased and led by agents. We map the work and count the manual hours first, score each process on volume, how rule bound it is and what it risks, build to a boundary, run in shadow mode, then hand over. If you want a ranked list of processes that you can hand to any builder, an AI readiness assessment gives you one, and our five question framework is a version you can run yourself. To talk about your own operation, get in touch.