On this page
Playbook
Dylan Karaitiana 15 Apr 2026 3 min read Most agencies sell deliverables lists. We sell pillars. The difference sounds semantic until you watch what happens in the first scoping call: agencies open a deliverables list, we open the operating system and ask which part is underperforming. The conversation changes shape immediately.
What an operating system actually means
Every business runs on a stack of moving parts. Some are software, some are processes, some are people doing manual handoffs that nobody documented. We don’t care which is which — they’re all part of the operating system. The website is a part. The CRM is a part. The invoice that gets typed twice because the systems don’t talk is a part. The handover from sales to delivery that happens in a Slack thread is a part.
When we say “operating system” we mean the full stack of moving parts that turn intent into outcome. Marketing into pipeline. Pipeline into close. Close into delivery. Delivery into renewal. Each handover is a part. Each part either flows or it doesn’t.
What we look at
The map we run projects against is our four-pillar framework — Map · Connect · Align · Amplify. Map reads the operating system end-to-end. Connect wires the data. Align lands the team & the go-live. Amplify holds the cadence after the metric moves.
The framework matters less than the discipline of having one. With the four pillars in place you can ask “which pillar is underperforming?” and an honest answer falls out. Without it the operator gets a list of agency capabilities and gets sold what’s in stock.
Why a pillar beats a list of deliverables
Deliverables have an end date. Pillars don’t. A pillar either holds the metric or it doesn’t. The frame difference matters in three places.
Scoping
Deliverables-list scope drifts because nobody can tell you when it’s done. Pillar scope is bounded — the pillar either holds the metric or it doesn’t. We set the starting number, we deliver the go-live, we measure after. If the metric moved, we close. If it didn’t, we either re-scope or refund.
Pricing
Deliverables price by hours estimated. Pillars price by the go-live. The operator is paying for the move, not the calendar. If we move it in week six instead of week ten, we don’t keep billing.
Continuity
Deliverables end when the work ships and the agency disappears. Pillars don’t end — they get handed back, but they’re still there, still operating. We document the pillar, instrument the metric, and stay reachable for post-go-live support. The next project either picks up the same pillar (if the metric drifts) or moves to the next pillar (if it holds).
What this looks like in practice
A typical project: an AU operator runs an ecom store, conversion rate is flat. Agency would scope a “checkout redesign”. We read the operating system and find the experience part is underperforming — specifically the payment-method picker and the shipping reveal. We set cart-to-purchase at 32% as the starting number, set the target at 38%, deliver the go-live, measure the result. Pillar held; the operator now knows the experience part is solid.
Six months later they call back. The conversion rate is still 38%, but lead volume from paid ads has dropped. We map again, find the demand part is underperforming — attribution drift is making the campaigns look worse than they are, the team is over-optimising. New project, new pillar.
The takeaway
Operating-system thinking is a frame, not a methodology. You can read every playbook on this site and run them yourself — the framework doesn’t depend on us. What changes when you adopt the frame is which conversations you have, which metrics you watch, and what counts as “done.” Deliverables are done when the work ships. Pillars are done when the metric holds. We prefer the second.