REDNAL Solutions Business Systems, Operations and Applied AI
Owner-operated businesses reach a point where the owner becomes the system. REDNAL establishes what is actually true, designs how the business should run, builds it into daily work, and hands it over.
The problem
It rarely arrives as a crisis. It arrives as accumulation. Systems were added one at a time, each for a good reason, and the gaps between them were filled by the person who could not let the work stop.
Two systems give two answers, so the real figure is rebuilt by hand before anyone will act on it. Reporting becomes a reconciliation exercise, and the meeting is spent arguing about which number is right instead of what to do about it.
The system holds part of the process. The rest lives in a spreadsheet, a notebook and a group chat, maintained by one person who has never been asked to explain it because it has always simply worked.
There is a written procedure, and there is what people actually do. They stopped matching a long time ago. The written version is the one shown to new staff, so they learn the job twice.
Quotes, exceptions, approvals and anything unusual queue behind the owner. Work pauses when that person is unavailable, because nobody else holds the context needed to move it, and nowhere records what the context was.
None of this presents as a single problem to solve. It presents as an owner holding the business together in their head, and a business that cannot grow past the size of that head.
Before and after
Not a programme with a name. A set of specific, unglamorous shifts in how the work moves, and in what stops landing on the owner.
Now
You are the only person who knows why that customer is handled differently.
After
The reason is recorded where the work happens, and the next person applies it without asking you first.
Now
Reporting means exporting, cleaning and reconciling before anyone will trust a number.
After
One agreed source produces the number, and the standing argument about which figure is correct ends.
Now
How a job gets done depends on who is rostered on that day.
After
The steps sit inside the tools people already use, so a quiet Tuesday and a bad Friday produce the same work.
Now
Improvements stall, because the change never survives contact with a busy week.
After
Changes are run against real volume and real exceptions before handover, or they are not handed over.
How we work
Five stages, run in order. Each one produces something the business can see, and the last one is the point of the exercise.
Work out what is actually true. We sit with the real work: the systems, the exports, the spreadsheets beside them and the people doing the job. What comes out is a plain description of how the business runs today, including the parts nobody has written down.
Decide how it should run. The operating model comes before the tooling: where the record of truth sits, who decides what, what happens at the exceptions, and what the business is going to stop doing. Decisions get made here, on paper, while they are still cheap.
Build it into daily work. The design is implemented in the systems your team already uses where that is sensible, and in purpose-built pieces where it is not. The test is whether the right way to do the job has become the easy way to do the job.
Run it in real conditions. Real volume, real exceptions, real people under time pressure. We watch where it bends, correct it, and check the numbers coming out against the numbers it was built to produce.
Leave it with your team. Documentation describes what was actually built rather than what was planned, the people who use it are trained on it, and ownership sits inside the business. The engagement is designed to finish.
The difference
Before anything is designed, we work out what is true: not the reported version, not the version the system believes, the actual one. Most of the disagreement in a business turns out to be a disagreement about facts.
A process map drawn from the documented procedure describes a business that does not exist. Ours are drawn from what people actually do, including the workaround they were slightly embarrassed to show us.
This does not end in a report for someone else to act on. It ends in something running in your business, used by your team, on a normal working day.
Automating a process that nobody owns only makes the confusion faster. Decision rights, escalation and accountability are settled first, then the work is built on top of them.
Nothing is treated as finished because it worked once in a demonstration. It is checked against real conditions and against the figures it is supposed to produce, and what fails is fixed before handover.
Your team should be able to run, explain and change what we built without us. If the business still depends on REDNAL to operate it, the work is not finished.
Where technology fits
Applied AI is part of what we do, and it earns its place in a small number of specific spots: reading unstructured information, drafting repetitive written work, checking large volumes of records against a rule that a person would find tedious and would eventually get wrong.
It is not the answer to a business that has not yet decided how it runs. Most of what is broken in an owner-operated business is a question of structure, ownership and sequence rather than tooling. If the problem is better solved by removing a step, changing who decides, or writing one thing down properly, that is what we will do.
Technology is an instrument here. It is not the product.
Next step
If any of this reads like your business, the useful first step is a conversation about how it actually runs. Bring the part that only holds together because you are holding it.
Email reaches Eddie directly.