Almost every office we speak to now wants the same thing. Less admin. Faster reporting. Fewer hours lost to reconciliation and chasing statements sounds like a dream. The appetite is there, and the tools are cheap enough that nobody needs to build a business case to try.
We’ve spent a lot of this year taking offices through transformation processes, and a few things keep coming up. The one we see most often is that AI use is ad hoc and unstructured. There’s real enthusiasm, there’s genuine usefulness in places, but there’s almost no structure around the processes and flows it’s being applied to.
Here’s what that looks like. Someone takes the quarterly reporting process and wires it into a chat window. They describe what they want, it works, they save it and share it with two colleagues, and by the end of the week that is how reporting gets done.
Nobody drew it or mapped it. Nothing was written down or discussed even. No diagram, no specification, no list of steps in order. Ten years ago this wasn’t possible. Automating anything meant a project manager, an integration lead, a requirements document and a long argument about scope. The tooling was unpleasant enough that it made you think before you built. It used to be a heavy lift. That friction is gone now, with that a lot of planning seems to have gone out the window too.
AI For Family Offices
Interested in learning more about AI transformation for family offices?
We have a framework and work with different stages and journeys.
The friction was doing something
We tend to treat skipping a planning or design phase as laziness. It isn’t. It’s a rational response to something that could be painful, and as the tools tend to skip this process, people do too.
Starting with an exploration process can actually be fun, and there’s a lot of it to do. From a solid foundational plan, it’s so much easier to move to a design phase, producing a concept and prototype, before building an actual proof of concept. Without the explore and design phases, what you end up with is an office running six automations that could be very similar, not shared and that nobody has ever seen written down, each one carrying the assumptions of whoever happened to build it.
The exploration and design phase needs time, but with a solid afternoon, a lot can be done. Ask three people to describe the quarterly reporting process, map each step out and see where the steps touch other processes, data or tools. This foundation is a first step to documenting institutional knowledge.
Start with triggers
A workflow description has a handful of parts, and the one people leave out quite often is the first one.
The trigger. What starts this, and how? Usually one of four things: a date, an event like a statement landing or a valuation posting, a person asking, or another workflow finishing. Write it down precisely, because the trigger is what separates a tool from an agent. A process a human starts fails safe. If nobody starts it, nothing happens. A triggered process needs to include all the conditions needed to ensure it still makes sense.
Triggers also have a second half: when it should not run. The suppression condition, the exceptions to the rule. This could include any list of conditions that would ensure it doesn’t run.
The exceptions. In most family offices, the exceptions are the work the team needs to focus on most. Without this, an agent handles the standard flow beautifully and takes the exception straight through the middle of it without pausing, because nothing told it the exception exists.
The handoffs. Every point where work passes from one person, system or agent to another. This is where things often got lost, long before any of it was automated.
The end state. How anyone knows it’s finished, and who confirms that. Surprisingly often the honest answer is that somebody looks at it and feels satisfied, which is not a specification.
Five columns and six gates
Then go step by step. For each one, five things.
You don’t need process modelling software for this. A table will do, even a sheet of paper and Post-its. What matters is that the description lives in a file you own, so you can make it available to whichever tool needs to run it.
Once that is defined, the following checks need to be passed before a workflow can run on its own.
The workflow is mapped out.
It has a named owner who is a person rather than a tool.
Its output can be checked by someone who did not produce it.
There is a written fallback in case the tool disappears.
A measured baseline is established to determine improvements.
The process is reversible; it can be done by hand for a month if necessary.
One exercise, and it answers five questions at once. It’s your succession document, because it puts key person risk on a page. It’s the data inventory that decides what can leave the building. It’s most of the documentation a deployer obligation asks for. It’s the basis for knowing what each workflow costs to run. And it tells you which tools to choose before you attach any intelligence to them.
You wouldn’t renovate a building without a plan. The plan is not the interesting part, but needed to get to the result.
About the author
Francois Botha helps design and incubate the family offices of the future through Simple, which pairs high-touch advisory with technology-led solutions to help private wealth owners build offices that last. From formation and strategy through to AI-powered operations, Simple’s team and network of independent advisors provide the knowledge, agentic tools, and governance to move forward with confidence, while keeping the human judgment that matters most at the centre.
He wrote a weekly column on family office strategy for Forbes and speaks regularly at private wealth, family office and technology events.
The reason offices can't describe the workflow is that it lives in one person's head and has for fifteen years, and writing it down is uncomfortably close to admitting how dependent the office is on them. Automation projects die at that step far more often than at the tooling step.