Until recently, digitisation for a local service business often started and ended with an email inbox and a spreadsheet. Sometimes there was also a notebook containing customer phone numbers. The notebook had one clear advantage: it worked without a battery. It was less effective at searching customer history, sharing information and recovering data after an unfortunate coffee incident.
Today, local service businesses are increasingly recognising that digitisation can create measurable — and therefore monetisable — value. A well-designed system can shorten customer service times, reduce mistakes, help employees work more efficiently, increase the number of cases a team can handle and make better use of knowledge previously scattered across documents, messages and people’s heads.
This does not mean every company needs a large enterprise system, ten dashboards and a command centre with wall-sized screens. Often, a small and well-designed workflow creates far more value than a complex platform trying to solve every possible problem at once.
Digitisation matters when it improves the result
Moving a paper form into an application is not automatically process digitisation. It may simply move the same problem to a different location.
A better starting point is to ask: where does the business currently lose the most time or money?
It may be:
- answering the same questions repeatedly,
- manually copying data from documents,
- searching for customer agreements,
- dealing with inconsistent information,
- missing important process steps,
- preparing quotations too slowly,
- struggling to handle more requests,
- depending on one person who “knows how everything works”.
If a system reduces service time, helps the company accept more work, reduces mistakes or improves the customer experience, its value becomes easier to assess. Technology stops being an abstract investment in “modern tools” and becomes an investment in a specific business process.
Company knowledge is valuable, but often hard to access
Local service businesses usually have a great deal of practical knowledge. They know the questions customers ask most often, exceptions to standard procedures, pricing rules, ways to solve recurring problems and details that cannot be found in a public manual.
The problem is that this knowledge is often distributed across:
- PDF files,
- price lists,
- procedures,
- email messages,
- chat applications,
- spreadsheets,
- previous case history,
- employee notes,
- individual experience.
Finding the right information may require searching several places or asking the person who happens to be on holiday, in a meeting or — as often happens — “about to call back”.
A well-designed system can bring these sources into one controlled workflow. It does not need to replace all existing tools immediately. It can start with document search, answer preparation or employee support during customer service.
RAG connects a model to the right information
RAG stands for Retrieval-Augmented Generation. In practice, it is a way of connecting a language model with documents and data belonging to a specific organisation.
The model does not have to rely only on knowledge acquired during training. First, the system retrieves relevant parts of the company’s documents. The model then uses those parts as context for preparing an answer.
A question might be:
> Which documents are required to start this service, and what is the current delivery time?
The system can search procedures, price lists and internal case data, then prepare an answer based on those sources.
RAG can use:
- service procedures,
- price lists,
- product documentation,
- employee instructions,
- regulations,
- previous cases,
- service catalogues,
- availability information,
- response templates,
- internal decision rules.
RAG does not mean “upload every file to AI and see what happens”. Documents need to be prepared, split into meaningful sections, described and made available according to permissions.
If the system cannot find the right information, it should be able to say so. That is much better than giving a confident answer based on a guess.
AI does not have to mean the cloud
AI is often associated with sending every piece of data to an external cloud service. That is not the only option.
The architecture can be designed in several ways, depending on the type of data, confidentiality requirements, operating costs, infrastructure and the level of control required.
Possible approaches include:
- using an external model through a secure API,
- running a model locally on company infrastructure,
- using a private or isolated cloud environment,
- combining local and cloud models,
- storing documents locally while sending only selected, sanitised data to an external model.
There is no single solution that fits every business. One service provider may benefit from a simple external API integration. Another may need to keep data on its own infrastructure or within a strongly isolated environment.
Model routing: the right task, the right model
One useful architectural approach is model routing. Instead of sending every request to one large and expensive model, the system first identifies the type of task and chooses an appropriate path.
For example:
- a simple question about opening hours can be handled by a small local model or a standard rule,
- a price-list lookup can use RAG and a local model,
- a complex document analysis can be sent to a larger model,
- a request containing highly confidential information can stay in a local environment,
- a decision requiring judgement can be routed to an employee.
Routing may consider:
- data confidentiality,
- task type,
- question complexity,
- required response time,
- processing cost,
- model availability,
- required accuracy.
This means the architecture does not need to be an “everything local or everything cloud” decision. Several models and environments can work together, with the system routing each task to the most suitable place.
It is similar to a well-run reception desk. Not every question needs to go to the director. Sometimes a price list is enough, sometimes a specialist is needed, and sometimes the best answer is that a person will take care of the matter.
Local models and data confidentiality
If a business handles customer data, contracts, pricing, medical records, financial information or internal procedures, confidentiality may be a critical requirement.
In such cases, the organisation may consider running a local model:
- on its own server,
- on a device located at the company,
- within a private network,
- in an isolated cloud environment,
- on infrastructure managed by a trusted provider.
Local model deployment can increase control over where data is stored, who can access it and how long it is retained. It does not automatically guarantee complete security.
The system still needs:
- user permissions,
- tenant isolation,
- encryption,
- access logging,
- retention policies,
- data deletion,
- backups,
- monitoring,
- model and infrastructure updates.
A local model is one part of the architecture, not a magic security spell. The fact that it runs on a company computer does not solve badly configured access permissions.
Isolated cloud environments as a compromise
Not every organisation wants or is able to maintain its own hardware, models and runtime environment. Local models require infrastructure, updates, monitoring and technical expertise.
An isolated cloud environment can be an alternative. Data can be stored in a dedicated space, and access can be limited to a specific organisation and its users.
Additional controls may include:
- tenant separation,
- private networks,
- restricted API access,
- data encryption,
- pseudonymisation,
- filtering before data is sent to a model,
- separate testing and production environments,
- retention controls.
The decision between a local model and an isolated cloud should follow actual requirements. There is little value in maintaining private infrastructure purely because it sounds more technical if the business does not need that level of control. At the same time, sending all data to an external service without analysing the risks is not a reliable strategy.
Start with one process, then expand
Digitisation often goes wrong when it starts with an attempt to build “AI for the entire company”. The idea sounds ambitious, but the scope, cost and expected outcome quickly become difficult to define.
A better approach is to choose one process that:
- happens frequently,
- takes significant employee time,
- uses available data,
- has a clear beginning and end,
- allows its effect to be measured.
It could be:
- searching internal documents,
- preparing answers to common questions,
- classifying enquiries,
- creating conversation summaries,
- preparing a first version of a quotation,
- handling customer requests,
- searching customer history,
- routing cases to the right employee.
Once the first process works reliably, additional ones can be added. The system grows with the business instead of trying to represent every unusual event from the company’s entire history on day one.
How can digitisation create revenue?
The benefits of digitisation do not have to be limited to saved time. They can affect revenue or margin directly.
A system may help the business:
- serve more customers with the same team,
- respond to enquiries faster,
- shorten quotation preparation,
- reduce mistakes and complaints,
- provide support outside standard working hours,
- make better use of available appointments,
- identify valuable enquiries earlier,
- recommend additional services,
- reduce dependency on one employee.
It is useful to measure the baseline before starting. The metrics do not need to be complicated. Response time, number of handled cases, error rate or the number of enquiries that turn into sales may be enough to evaluate the result.
If nobody can explain which process is expected to improve, it becomes difficult to determine whether the project was successful.
People remain part of the process
Automation does not mean removing people from every workflow. In many cases, the best solution is hybrid.
The system can:
- find relevant information,
- prepare a suggested answer,
- indicate confidence,
- show sources,
- classify a request,
- route it to the right person.
An employee can then approve the result, correct it or decide that the case needs individual attention.
This matters whenever an answer has financial, legal, operational or customer-related consequences. AI can accelerate work, but it should not hide uncertainty or pretend to know the answer to every question.
A well-designed system grows with the business
RAG, local models and model routing make it possible to build systems around an organisation’s actual needs. A company does not have to choose between a basic chatbot and a massive AI platform.
It can start with one process, measure the result and gradually add more capabilities. Depending on the data and requirements, the architecture can use a local model, an isolated cloud environment or a combination of several approaches.
The most important decisions concern the whole system:
- where the data comes from,
- who can use it,
- how the model is selected,
- where processing takes place,
- how outputs are checked,
- what happens when the system fails,
- when a person joins the process.
Digitisation for local service businesses does not have to be a huge transformation programme. It can be a careful, incremental way to organise knowledge, improve service and increase the value of the business.
As for the notebook: it can stay. It is probably best used as a souvenir rather than the company’s primary information system.
Have a system that
simply has to work?
Tell us what should be built, who will use it and which parts are the most critical. We reply within one working day — usually straight away with the questions that pin down the biggest risks and the next step.