The operating system underneath
The practice works. It works because you are holding it together, and that is the part that does not scale.
Multiple offers, a team, corporate accounts or a community have made visibility and follow-through the actual constraint. This is the client record, the lifecycle, the workflows and the handoffs between them, built so the practice can grow without losing relationships, context or commitments.
You know things nobody else in the practice knows, and the practice runs on that. Which client is mid-conversation about renewing. What was promised in a call in March. Who is supposed to pick up the next step.
Nothing has gone badly wrong yet. Things get dropped occasionally and get caught, usually by you, usually late. The cost is not a disaster, it is that you cannot step away and you cannot hand anything over cleanly.
The work itself.
The operational and relationship architecture first, meaning the decision about how work actually moves through the practice, before any tool is chosen.
Then the CRM and the client lifecycle, so one record holds the relationship and its history. Multiple programs or client paths running alongside each other. Team roles with protected access, because not everyone should see everything. The follow-up and delivery workflows, and the handoffs between people, which is where most of the dropping happens.
Dashboards that support a decision rather than produce reporting theater. A knowledge and content foundation so answers are retrievable rather than remembered. Explicit handling for exceptions and the points where a human has to take over, since those are the moments that break an automated system quietly.
Then implementation, testing, team adoption and the operating documentation. A system nobody adopts is not a system.
AI carries the repeatable work: organizing, retrieving, preparing, and the operational tasks that recur. Judgment and client relationships stay with people.
Here the visibility is not a progress bar. It is the point.
On the other three paths this section describes how you watch the work. On this one it describes the work. The reason to build an operating system underneath a practice is that nobody can currently see the whole thing at once, and the person carrying the gaps in their head is you.
So: one client record holding the relationship and its history, in the place people actually look. Where each client is in their lifecycle. What was committed to and by whom. Which handoffs are open and who owns the next step, which is where most things get dropped. Dashboards built to support a decision someone is actually going to make, not to fill a monthly slide.
During the build you also get the ordinary version, a page showing what has shipped, what is in progress and what is next against the milestones, plus a written summary each month.
What the system does and what you do. It organizes, retrieves, prepares and carries the operational work that repeats. It keeps the record current because it is the thing doing the work, so the record is still true in month six when nobody has tidied it.
Judgment stays with people. So do the client relationships, and so does the decision about what to do when something does not fit the pattern. That last one is designed for explicitly rather than left to chance, because the point where a human has to take over is exactly where an automated system fails quietly.
What does not get built here.
Each of these is real work. It sits on another path rather than being quietly absorbed into this one, which is the only way a fixed scope stays fixed.
This level is a scoped proposal with milestones, because the right shape depends on what the practice already runs and what it is trying to stop doing.
If there is no team, one main offer and a manageable client list, this is premature and building it would create overhead rather than remove it. Saying so is part of the job.
The point is that the practice stops depending on one person's memory, not that it stops depending on people.
Three to six months, on milestones.
It runs in stages with something usable at the end of each, rather than a long silence followed by a launch. Team adoption is treated as part of the work, not as something that happens afterward.
Once it is running, ongoing care is a separate arrangement and it is offered only after FGN has built or properly taken ownership of the system. Taking responsibility for a fragile collection of third-party tools without a paid stabilization phase first is not something FGN does.
This might not be your first move.
Most practices that ask for this need something smaller first, and the ones that genuinely need it usually describe the symptoms rather than the system. The review sorts out which.