A customer submits an enquiry through your website. Someone copies it into a spreadsheet, forwards it to a colleague and creates a record in another system. Two days later, the customer calls for an update. The information exists, but nobody can immediately say who owns the next step.
The business already uses digital tools. The work is still fragmented.
Digital transformation means changing how a business operates and delivers value through technology, supported by changes to its processes and responsibilities. For a growing business, the most useful starting point is often a specific workflow: the sequence of tasks, decisions and handovers needed to get something done.
Before choosing a new platform, understand that sequence. It will help you decide what to simplify, what to connect and where new software will make a meaningful difference. The worked example and numbers in this article are illustrative, not client results.
Choose a business outcome first
“We need to modernise our systems” is difficult to measure. “We need to send accurate quotes sooner” gives the project a purpose.
Choose an outcome that matters to customers or the people running the business. It might be fewer missed enquiries, faster onboarding, less rekeying, shorter approval times or more reliable information for decisions.
Define the boundary clearly. If you want faster quotes, does the clock start when an enquiry arrives or when all required information is available? Does it stop when a draft is created or when an approved quote reaches the customer?
Those definitions affect what you measure and what you improve. A team could produce drafts faster while customers continue waiting for approval.
Write a simple project statement:
We want to reduce the time from a complete customer enquiry to an approved quote, while maintaining pricing accuracy and making ownership visible.
That is specific enough to guide discovery without deciding the technology in advance.
Map how the work happens today
Bring together the people who perform the work, receive it and handle problems when it goes wrong. Walk through recent examples, including an awkward one.
For each step, record:
- What triggers it and what information is needed.
- Who performs it and who can make decisions.
- Which tools, documents or messages are involved.
- How much active work it takes and how long it waits.
- What happens when information is missing or something fails.
Include email, phone calls, spreadsheets and informal conversations. They are part of the service even if they never appear in a system diagram.
The GOV.UK Service Standard on joining up channels offers a useful principle here: the experience needs to work across the different ways people interact with a service. A polished online form does little for customers if the next stage disappears into an unmanaged inbox.
The output should be a shared picture of the current process, including its exceptions. It does not need to be an elaborate document.
Find the cause of the delay
Different problems need different interventions. Before proposing automation, classify what you find.
| What you observe | What to investigate | Possible improvement |
|---|---|---|
| Staff enter the same details repeatedly | Systems lack a reliable connection | Transfer agreed fields automatically. |
| Requests sit untouched | Nobody owns the next action | Assign an owner and make waiting work visible. |
| Work repeatedly comes back incomplete | Required information is unclear | Improve intake questions and validation. |
| Managers approve routine cases | Approval rules are broader than necessary | Review which cases actually need approval. |
| Staff keep private spreadsheets | The official tool misses a real need | Understand the workaround before replacing it. |
| Teams argue over conflicting figures | Definitions or sources differ | Agree the authoritative record and calculation. |
Some improvements require no new software. Removing an unnecessary handover or clarifying a decision rule can be a sensible first step.
Other bottlenecks may come from capacity, supplier delays or commercial policy. Document them honestly rather than expecting a new application to resolve every constraint.
Work through one example: enquiry to quote
Consider an illustrative maintenance business. Website enquiries arrive by email, an administrator creates a customer record, an estimator prepares the quote and a manager approves it. Staff then record the outcome in a spreadsheet.
The business wants customers to receive accurate quotes sooner. Its initial investigation identifies duplicated entry, missing site details and approval requests that are easy to overlook.
| Stage | Current friction | Proposed first change |
|---|---|---|
| Enquiry | Site details are often missing | Ask for the information needed to assess the job. |
| Assignment | Staff forward emails without clear ownership | Assign each enquiry to a named person with a visible status. |
| Preparation | Customer details are copied between tools | Reuse the agreed customer and site records. |
| Approval | Managers search email for the latest version | Present the current quote and required decision together. |
| Follow-up | Outcomes are logged separately | Record acceptance or rejection against the quote. |
The first release could connect existing systems and introduce a small approval interface. It does not automatically require a complete replacement of the CRM, quoting tool and accounting platform.
Test the exception paths too. What happens when the customer changes the scope, the manager rejects a quote or the same enquiry arrives twice? A useful workflow needs a way to recover as well as a way to progress.
Decide whether to configure, buy, integrate or build
Make the technology decision after agreeing the future process. Compare options against the actual requirements, including ongoing operation.
| Approach | When to consider it | Questions to answer |
|---|---|---|
| Configure existing software | Your current tools support the necessary behaviour | Can permissions, forms or rules solve the problem? |
| Buy a product | The workflow is well served by an established product | How well does it fit, and can you export your data? |
| Integrate existing systems | Individual tools work well but handovers are manual | Which system owns each record, and how are failures handled? |
| Build custom software | Important requirements cannot be met economically by existing options | Who will maintain, support and evolve it? |
| Combine approaches | A standard product covers most needs | Where should custom work start and stop? |
Compare the full cost: implementation, subscriptions, migration, staff training, support and future changes. A low licence price can be offset by persistent manual work. A custom build can become expensive if its operational responsibilities are unclear.
Addbox’s software development services cover integrations, internal tools and applications. The appropriate scope depends on the workflow you need to improve.
Agree what information each system owns
An integration can move conflicting data faster if nobody has agreed which record is authoritative.
For each important type of information, identify its owner. The CRM might own customer contact details, the quoting application might own quote versions and the accounting platform might own invoice balances.
Then define what happens when information changes. Does an address update affect an existing quote? Can someone edit the same field in both systems? How will duplicate customers be resolved?
Include practical operational requirements: appropriate access, change history, error visibility and a way to replay failed transfers without creating duplicate records. These details determine whether people can trust the new workflow.
Test migration with a representative sample before moving everything. Reconcile the results against the source, and agree how the business will recover if the cutover cannot be completed safely.
Introduce AI where the task suits it
Some workflow steps are governed by clear rules. Routing an enquiry by postcode or flagging an overdue approval may only need straightforward automation.
AI can be useful where inputs vary: summarising a customer’s message, extracting draft job details or preparing a response for review. Evaluate it against real examples, including ambiguous and incomplete requests.
For the quoting example, an AI assistant could prepare a scope summary from an enquiry. An estimator could check it before pricing the work. The workflow should make missing information visible and provide a way to correct the draft.
Compare the time saved with the time spent reviewing and correcting outputs. Decide which actions require approval, particularly where errors could change prices or commitments to customers.
If you are choosing where to begin, Addbox’s AI strategy service can help assess opportunities in business processes and product development.
Plan a pilot people can actually use
Choose one team, one workflow or one category of work for the initial rollout. Keep the scope complete enough to deliver an outcome, and small enough to observe closely.
Use this roadmap as a sequence of decisions rather than a fixed delivery promise:
| Stage | Deliverable | Decision before moving on |
|---|---|---|
| Understand | Current workflow, baseline and pain points | Is the problem clear and worth solving? |
| Design | Future process, ownership and options | Does the proposed approach address the cause? |
| Test | Prototype or technical experiment | Have the critical assumptions been tested? |
| Deliver | Working pilot, training and support process | Can the team use it and recover from errors? |
| Measure | Results, feedback and outstanding issues | Should you expand, revise or stop? |
Nominate a business owner who can resolve process decisions and a technical owner who can address system problems. Give staff realistic practice cases and explain where to get help.
If old and new processes run together temporarily, specify where the authoritative record lives, who reconciles differences and when the parallel period ends. Otherwise, the pilot may create more duplicate work than it removes.
For help limiting a first release, see our guide to defining and prioritising an MVP.
Measure the improvement and its cost
Track the business outcome alongside adoption and reliability. For the enquiry-to-quote example, useful measures include elapsed time to an approved quote, staff handling time, correction rates and the proportion of work completed through the new process.
An illustrative calculation shows how to start assessing capacity:
200 quotes per month × 15 minutes saved per quote ÷ 60 = 50 hours released per month.
At an assumed loaded staff cost of £30 per hour, that represents £1,500 of staff capacity. It is not automatically a £1,500 cash saving. The value depends on whether the time reduces overtime, supports more work or is used elsewhere productively.
Deduct ongoing costs and account for implementation effort when assessing the business case. Compare similar types of work before and after the change, and record external factors such as staffing or seasonal demand.
Review the result with the people using the workflow. If they continue working around it, find out why before expanding it.
Start with the work that needs to improve
A useful digital transformation project has a clear problem, an accountable owner and an observable result. The technology follows from those decisions.
Choose one workflow that is slowing your business down. Map it, measure it and agree what a better version should achieve. That gives you a practical basis for deciding whether to configure, connect or build.
Charities can use the same approach with a smaller team and a clearer mission constraint. See digital transformation for charities.