Engineering services
AI Solutions
Chatbots that answer in your customers' language, phone agents that book appointments, an assistant that answers questions from your own documents, document reading, automated reports, voice cloning and dubbing, and a healthcare booking assistant. All working today, not a roadmap.
Part of your product’s journey
Of the eight stages we run, this service covers Plan, Build, Deploy, Maintain. We also run the others.
What this makes possible
Every software company says it does AI now. Most mean they have read the documentation for an API, and what you would be buying is a first attempt at your expense. The ten systems on our AI page are already built and already running, which is a different proposition: you can be shown one working before you decide anything.
Our approach in more detail
The part that decides most purchases is not the model — it is where the data goes. A hospital, a bank, a defence department and increasingly an ordinary business cannot send their records to somebody else's service, whatever it can do. Every one of these can run inside your own infrastructure, on your own hardware, including on a network with no route to the internet at all.
The other honest thing to say is that AI is often not the answer. A rules engine, a better form, or somebody spending an afternoon on a spreadsheet solves a surprising number of the problems it gets proposed for — and costs a fraction to run. We will say so when it applies.
What you get
- Multilingual chatbots, over your own documents rather than the open internet
- AI phone agents that answer, call out, book and write the call up
- A knowledge assistant that cites the document behind every answer
- Document reading — printed and handwritten — into structured data
- Automated reports, on a schedule, in your own template
- Voice cloning and video dubbing with matched lip movement
- Deployed in your infrastructure, with access set by role and every read logged
How we get there.
- 01
Show you one working
Before scope, before price. If one of the ten is close to your problem, you see it running and form your own view. That is a half-hour call and it settles more than a proposal does.
- 02
Find the honest boundary
What it should decide, and what it must hand to a person. This is the most important conversation in any AI engagement and the one most often skipped. A system that answers confidently when it should have escalated does more damage than one that escalates too often.
- 03
Point it at your material
Your documents, your records, your systems. The quality of the answer follows from this and almost nothing else — which is why the first honest finding is often that the material needs sorting out before any of this is worth doing.
- 04
Decide where it runs
Our infrastructure, your cloud account, your own servers, or a disconnected network. Access is set by role and enforced where the data is read. Every read leaves a record you can audit.
- 05
Run it, and watch what it gets wrong
It goes live for a narrow group first. We look at what it answered badly, correct the material or the boundary, and widen it. An AI system that nobody reviews after launch quietly degrades as the underlying material ages.
A little more detail.
The process, the fit, and the questions worth asking before we begin.
Is this the right service for me?
- Not for you if the problem is a rules problem. If the answer is always determined by the input, a rules engine is cheaper, faster, testable and never invents anything. We will tell you when that is what you have.
- Not for you if the underlying material is a mess and nobody wants to fix it. An assistant over contradictory, out-of-date documents will answer confidently and wrongly, and you will trust it for exactly as long as it takes to get caught.
- Not for you if nobody will own the boundary. Somebody on your side has to decide what the system may answer alone and what it must escalate, and revisit it. Without that owner the safe answer is not to deploy.
- Not for you if you need it to be right every time. These are very good and they are not certain. Anything where a wrong answer is unrecoverable — a clinical decision, a legal filing, a payment — gets a person in the loop, and we will insist on it.
- Not for you if the appeal is that it is AI. That is a reason to build a demo, not a reason to buy a system, and it is the most expensive reason there is.
A worked example
Hypothetical scenario
Illustrative: a hospital with a phone problem
Say a clinic has four staff answering the phone all morning, and most calls are the same six questions — is the doctor in, can I move my appointment, what do I need to bring, where do I park. The instinct is a chatbot on the website. The people ringing are not on the website. What actually helps is the phone line itself answering in the caller’s own language, handling those six things and booking into the same calendar reception uses, and putting anything else through to a human with the conversation already summarised. The measurable part is not “AI” — it is that reception gets its mornings back. A build of this shape runs four to eight weeks, and most of that is the integration with the existing appointment system rather than the AI.
An illustration of our approach, not a delivered client project.
Can we see one working before we commit to anything?
Yes, and that is the intended first step rather than a concession. Tell us which of the ten is nearest your problem and we will show you it running on a call. Nothing about the ten depends on you signing anything first — they exist independently of any engagement with you.
Where does our data go?
Wherever you decide. Cloud, your own cloud account, your own servers, or a network with no internet connection, where the model runs on your hardware and nothing leaves the building. Access is set by role and enforced where the data is read rather than hidden in the interface, and every access is logged. For most defence, government, banking and healthcare buyers this is the question that decides the purchase, which is why it is answered on the AI page rather than kept for a call.
What happens when it gets something wrong?
It will, and the design question is what happens next rather than whether it happens. Answers come with the source document attached wherever the system is answering from your material, so anybody can check. Where the cost of a wrong answer is high, the system routes to a person instead of answering. And we review what it answered badly after launch, because the failures are the useful data.
Do we need our own AI people to run it?
No. It is handed over with documentation, and the parts you will want to change — the material it answers from, the boundary of what it handles alone — are made editable by your team rather than by us. If you would rather we operated it, that is a support arrangement.
How is this priced?
One of the ten taken largely as it is, with your material and your branding, is the cheapest and starts in the same bands as an application build. Customisation and integration with systems you already run moves it up. A fully custom system is quoted like any other build, from a written scope. Running costs are separate and worth asking about early — a private deployment on your own hardware has a very different monthly shape from an API-based one.
Bring the pieces together
Tell us what you need to achieve. We’ll help you scope the work and see how it fits your wider product.