Where to Start With Digital Transformation in a Small Business

An enquiry arrives through the website. Someone copies it into a spreadsheet, asks a colleague for availability and prepares a quotation. The customer waits while the information moves between people. Buying a new customer relationship management system might help. It might also create another place where somebody has to enter the same details.

The useful starting point is the delay. Where does the enquiry stop moving? Is information missing? Is pricing difficult to establish? Does every quotation need a director's approval? Does anyone know when the customer expects a response?

These questions turn an expensive, open-ended ambition into something a business can investigate. They also leave room for several answers. The first improvement could be a clearer pricing policy, a better intake form, an integration or custom software. It could be a combination.

The OECD's 2025 study of SME digitalisation considers how firms adapt business processes as well as adopt technologies. That distinction matters when a small team has limited capacity to change its daily work.

A transformation programme becomes useful when it gives people a better way to deliver a business result. A larger collection of subscriptions, by itself, does not establish that anything has improved.

Most businesses can name more friction than they can afford to address. The task is to decide which problem merits the next investment.

Begin with a specific part of the business: preparing an order, onboarding a customer, reconciling payments or allocating work. Ask the people doing it to show recent examples. A complaint such as “our systems are outdated” needs to become an observable difficulty, such as “we cannot confirm stock without checking two systems and calling the store.”

Assess the difficulty against three practical questions:

• Does it affect an outcome the business values, such as completed orders, reliable service or the ability to collect payment?

• Does it happen often enough, or carry enough risk, to justify deliberate work?

• Can someone in the business take responsibility for changing it?

A rare exception can still deserve priority when its consequences are serious. Conversely, a frequently mentioned irritation may be cheap to tolerate. Frequency should inform the decision alongside consequence.

Avoid choosing the first project solely because its technology is fashionable or its supplier is persuasive. Equally, avoid seeking the largest possible problem. A bounded issue with an available owner often offers a better starting point than a project that depends on every department changing at once.

The first investment should make an important part of the business easier to run and produce evidence for the next decision.

The place where a problem becomes visible is not necessarily where it begins. A delayed invoice might originate in incomplete delivery records. An abandoned application might reflect an unclear eligibility rule. An unreliable dashboard might be faithfully reporting inconsistent source data.

Follow the work from its trigger to its outcome. Record who acts, what information they need, where that information comes from and what happens when something goes wrong. Include the emails, calls and private spreadsheets that keep the formal process moving.

The UK Government Service Manual's discovery guidance starts with understanding the problem, users and constraints before committing to a solution. For an SME, the equivalent investigation can be tightly scoped: observe a few real instances, speak with the people involved and examine the available records.

Suppose a distributor wants to shorten quotation turnaround. In an illustrative review, its order-entry system proves adequate. The delay comes from exceptions: sales staff cannot see which prices they are authorised to offer, so routine quotes accumulate in an approval queue.

Replacing the order system would leave that queue intact. A clearer pricing policy and a visible escalation route might resolve much of the delay. An integration could then bring the remaining information into one place.

The investigation should also identify what already works. Familiar tools, supplier connections and reliable routines have value. A useful project preserves that value where it can, while addressing the specific constraint.

Before speaking to suppliers, put the problem on one page. This is not a lengthy specification. It is a reference point that prevents an attractive demonstration from redefining the purchase.

Keep the outcome separate from the proposed feature. “Give every salesperson a dashboard” describes a solution. “Let sales staff establish whether a standard order can be fulfilled without calling operations” describes a need that different solutions can meet.

Record assumptions openly. Perhaps the business believes that quicker quotes will produce more sales. That is plausible, but it needs to be distinguished from the directly observable improvement of reducing quote preparation time. A project can deliver the latter without guaranteeing the former.

The brief should also state what the business will contribute. Access to staff, sample records, decisions and a process owner are project inputs. A supplier cannot discover an operating rule that nobody is available to explain or authorise.

A baseline gives the project something concrete to improve. Choose a small number of measures that describe the work, rather than tracking everything the software can report.

For quotations, useful measures might include elapsed time from complete enquiry to response, the number returned for missing information and the proportion needing exceptional approval. For onboarding, they could include successful completion, requests for help and repeated document submissions.

Define the measures carefully. A faster average can hide a small group of customers who still wait several days. An apparently improved completion rate can result from excluding difficult cases. Note the circumstances behind the numbers and keep the comparison consistent.

Some businesses have little reliable historical data. That does not require postponing the project indefinitely. Start with a short observation period and a modest record of actual work. Staff interviews can identify likely problems, but their estimates should not silently become precise financial claims.

Use the baseline to consider the value of different interventions. A shorter task may release staff capacity without reducing payroll. A more reliable process may lower exposure to missed orders without producing an immediately visible revenue increase. These are worthwhile outcomes, but the business case should describe them accurately.

The measure should help the owner make a decision. If nobody can explain what would change in response to it, it is probably not the right measure for the first project.

Once the problem is understood, compare the lightest credible interventions. Could a policy change remove the bottleneck? Could an existing tool be configured properly? Would an integration be sufficient? Is custom software development needed because the workflow creates a distinctive advantage or has requirements that standard products cannot meet?

Microsoft's automation planning guidance includes understanding and optimising the process before deciding whether it is worth automating. The same discipline is useful beyond automation: establish what should change before selecting how to implement it.

Scope a first release around a complete piece of work. A small, usable improvement is preferable to several partially connected components that nobody can operate together. Include the exceptions, responsibilities and training needed for that bounded scope.

Then review the evidence with the process owner. Did the intended users adopt the change? Did the targeted delay or error decrease? Has the work simply moved elsewhere? Are the ongoing costs and support demands acceptable?

In businesses serving several markets, the answer may differ by location. Language, connectivity, payment methods and local operating practices can affect whether the same approach works everywhere. Expand on the basis of evidence rather than assuming one successful trial validates every branch or customer group.

Digital transformation starts to acquire direction when each investment resolves a known constraint and makes the next choice clearer. The technology matters. Its purpose should already be understood when the purchase decision arrives.