A Logic-Gated Operational System Supporting a Physiotherapy Chain's Growth from 18 to 40+ Clinics

The chain was growing fast. Growth at this pace exposes every manual process. Rules get forgotten, ownership blurs, and no one can see the whole operation at once.

Every appointment lived in TM3, a rigid clinical system with no API.
It could export files by hand and send automated emails, and nothing more.

Important metrics that run a clinic chain did not exist anywhere.
Diary utilization, rebooking rates and weekly trends all had to be built from raw records. Bonuses were set from an earnings spreadsheet alone.

Any automated feed out of TM3 would be one-way. When an appointment changed or was cancelled at the source, the change would never reach the data downstream.

A team of admins handles reports for nearly every insurer on the UK market. Each insurer has its own rules, and some reports are due within 24 hours.

Before the system, the team produced only the reports that billing required. Practitioners and admins wrote them by hand, prompted by messages and notes in TM3. Nothing enforced duplicate checks, task assignment or deadlines, and all three were hard to administer.

Additional sessions went unclaimed from insurers. Approved sessions expired unused. Invoices that depended on reports came back rejected.

Our founder, Stepan, ran his own business for 11 years before selling it. He built his first operational system for that company. That experience shapes how we start every build.

In a physical business, problems are visible. You walk the floor and see where stock piles up or where a handoff stalls. Data rarely gives such signals. It leaks quietly between people and systems.

So we treat data like physical material. We trace where each record enters, where it waits and where it gets lost. The owners and department heads worked with us as co-developers, because they hold the real rules of the operation.

The system was built in iterations. It started as a data feed for one dashboard and grew into the operational backbone of the business.

We chose Airtable as the core database and started on its Team plan, which caps each base at 50,000 records. The operation produces about 17,000 records a month. We knew from the start that raw records could not stay in the base forever.

The data is tightly linked, and the business needs its history. Deleting old records would break the metrics built on them. So the design had to compress data without losing the data points that matter.

The system stamps data into static summaries as early as it can. Each month, a compression engine stamps weekly, monthly, practitioner and location totals, then removes the raw records. Large jobs run in self-triggering loops, one safe batch at a time.

TM3 remains the source of truth. Condition-based templates inside it fire technical emails when key events happen. A routing layer catches each email and passes it into the core database.

Everything lands in one consolidated base. It is split by logic into two domains: performance data and the report pipeline. A separate billing system connects to it through a sync.

The relational schema links appointments to practitioners, locations, services, clients, tasks, weeks and months. Around 1,500 attributes feed the numbers people see. Task status is its own table, so status options are filtered per insurer and report type.

A weekly script builds the numbers TM3 cannot produce. These include diary utilization, weekly trends and leaderboard scores. Each practitioner sees their own results in a portal, refreshed online.

The retention score combines several Bayesian scores. It weighs each practitioner against median activity, so the ranking stays fair. Two of the three leaderboards can be won by new practitioners, a deliberate design choice by the owners.

The loop then reaches the client. Sequences inside TM3 prompt clients to book their unused insurance sessions. When sessions run out, clients are told more will be requested on their behalf.

Held sessions lead to feedback. Clients rate their practitioner on a short NPS form, which feeds the third leaderboard. The form ends with buttons to leave a Google review for the right location.

Each new review is credited to a practitioner through the Attribution Gate below. NPS scores flow back into the leaderboards. Attributed reviews show executives who follows the review process and who does not.

Rules that live in people's heads break under growth. We moved the critical rules into the system itself.

• The Weekly Refinement Gate: Every Monday, the previous week's data is uploaded from TM3. A confirmed and logged run removes duplicates and corrects what the one-way feed missed.
• The Proof Gate: A report cannot move to Submitted or Invalid without proof attached, such as a screenshot. Every invalid status needs a reason.
• The Duplicate Gate: Any status change snaps back to New until the admin confirms no duplicate exists. The confirmation is on record.
• The Assignment Gate: New tasks go to admins on shift now, with at least one hour left. If no one qualifies, the pool widens to later today, then tomorrow, then the full team. The task goes to whoever carries the lightest workload.
• The End-of-Shift Gate: Reports still untouched at the end of a shift move to an admin who is on shift now. Work does not wait for the next shift.
• The Attribution Gate: Every click on a review button is captured. The system bundles the NPS response, the click and the Google review by location and time window, then credits the right practitioner.
• The Booking Attribution Gate: An appointment that arrives after a report goes into work counts as a booking. Admins answer for report quality, and the system tracks the outcome.
• The Release Gate: For one insurer, referral letters are generated and sent only during working hours, at least three hours after the client's request.

Every script opens with a plain-English summary of its logic. A full catalog records what each module does and why it exists. Key variables sit in a control panel, so executives can adjust how the system behaves without calling a developer.

The system became the operational foundation of the business.
It gave the owners control at a scale where manual work breaks down. It did not drive the growth alone, but it was the technical base that growth needed.

• Clinics: 18 at the start, 40+ today.
• Practitioners in the system: about 40 at the start, 85 today, with 50 active.
• Reviews: captured and attributed across 40 locations.
• In production: 15 months.

The admin team now handles more reports, faster, with fewer rejections. That means faster billing and more authorized sessions for clients. Admin overhead went down as the chain grew.

Bonuses and HR decisions previously relied on an earnings spreadsheet and gut feeling. Now rebooking rates, NPS, diary utilization and earnings sit side by side for every practitioner. Hiring, firing, promotion and bonus decisions now rest on that data, not just on gut feeling.

Every review is captured and tied back to a practitioner. Executives can see who follows the review process and who does not.

The owners can now oversee the whole operation, handle exceptions and absorb change from above, at scale. New rules go into the system logic and the SOPs as they arrive.

Most of the system now runs with little manual upkeep. We continue to support, monitor and extend it together with the owners.