How does an Aldbry build work?

What happens at scoping?

Scoping is mapping, and it happens with the people who actually run the process, not with a description of it. We watch the work as it runs today and record every input, every approval rule, every tolerance, every handoff between people and every check before something is posted or sent. We note where information is typed twice, where someone waits on someone else, and where an experienced person is doing assembly work that a system could do.

Scoping also connects us to your systems, so the build reads from and writes to the places your team already works. By the end there is one clear picture of the process, its rules and where its hours go, agreed with your process owner, and the timing for the rest of the work is set.

What happens during the build?

The system is configured to your process: your approval routes, your tolerances, your documents and the language your team uses. It connects to the tools your people already open every day, so nobody has to learn a new platform.

Everything is tested on your own documents. Real invoices, real supplier statements, real records that have already passed through the business. Testing on real material surfaces the exceptions a demonstration never shows: the supplier who sends a different format, the document with a missing field, the step that only happens at period end. Each one is handled before the parallel run rather than discovered after go-live.

What happens in the parallel run?

The system runs alongside your current process, on live work, and the results are compared. Your team keeps doing the job the way it does today while the system does the same job beside it, so every difference can be seen, explained and fixed before anyone relies on it.

This is where your team builds confidence in the rules. They see which items the system would have cleared, which it would have held and why, and they can ask for a rule to change before anything is live.

What happens at go-live?

Go-live happens only after your team signs it off. From then on the system runs the routine and your people work the exceptions, each one arriving with the reason it was held. The old route is retired rather than left running beside the new one, because two ways of doing the same job is how a business drifts back to the slow one. Then, if you want, we add the next system.

What do we need from your business?

Three things, and they matter more than anything technical.

• Access to the people who run the process. Not only the manager who signs it off, but the people who do the work day to day. Their time is heaviest during scoping.
• Your documents and rules. Recent examples of the documents involved, your approval limits, tolerances and any checklists. The build is configured from these, so the closer they are to what is really used, the better.
• A named owner. One person in the business who owns the process, can make decisions about it during the build and the parallel run, and keeps owning it once it is live.

You do not need to be technical, and you do not need your information tidied into one system first. We read from wherever it lives today.

Who reviews what the system does?

People do. AI reads documents and turns them into data; every decision is a fixed rule you agree, and anything outside those rules goes to a named person in your business. The reviewer sees the item, the rule it failed and the evidence, which makes the check faster and more reliable than working through a pile by hand. Our guide to reviewing AI output on client work covers what a good review looks like.

How is confidentiality handled?

We work under whatever confidentiality agreement you use with any other supplier, and nothing you share is used for anyone else. The system is hosted in the UK, encrypted, with daily backups, and your data is not used to train AI models. If your business has its own rules on how information may be handled, the build follows them, and for a view of the wider issues see data protection and AI on client work.

What happens after go-live?

Support continues under the subscription, which covers hosting, support, monitoring, a monthly performance report and a quarterly review. Real use always turns up small things: a supplier format nobody mentioned, an approval route that needs to change, a tolerance that should be tighter. Rule changes are handled as part of support.

If you then want a second process built, it is scoped on its own, with its own fixed fee agreed in writing before it starts. Changes outside the agreed scope are quoted in days before any work starts.

How do we find out which process to start with?

Book a scoping call through the contact page: one conversation to find where admin is costing you most. If you want a view of the hours first, the audit gives an estimate in about three minutes, and preparing for your call explains what to bring.