Three levels, thirty-six automations, and a leadership team that wanted to know if the pods were on track.
A year into Planhat, the client had a three-level hierarchy, cross-level property propagation nobody had documented, and an automation estate that had grown by accretion. Leadership wanted pod-level visibility against quarterly targets. The instance could not produce it reliably, and nobody dared change it.
Client name withheld under our engagement terms. Details below are drawn from the executed statements of work.
An estate nobody had designed.
Construction-tech SaaS selling into large contractors. Customer success organised in pods, each carrying a book of target companies with a quarterly target on ARR, on a weekly active usage north-star metric, and on case studies.
Three levels in Planhat: Target Company at the top, Organisations beneath, Projects beneath those. Projects modelled as accounts, end users concatenated into a single record pattern, properties propagating across levels in directions nobody had written down.
Roughly thirty-six active, about twenty unique intents. Near-duplicates written by different people over the year, some updating the same property in different directions. Nobody could say what would break if one was switched off.
HubSpot for the CRM, Chargebee billing arriving via BigQuery with sync lag nobody had accounted for, Mixpanel for product usage.
No sandbox. Every change would be made in the production instance the pods were using that day.
Documented, maintainable architecture, and the data surfaced at pod and project level so each pod could answer "are we on track this quarter and where is the risk" in under a minute.
Three sequential statements of work, one fixed fee, a decision point between each.
Foundation first, visibility second, prioritisation third. Each SOW delivered something usable on its own, and the client called the next one only once the previous had landed.
Automation rationalisation
SOW 1 · 3 weeksEvery active automation catalogued by trigger, action, properties touched, hierarchy level and intent. A data dictionary for every property across the three levels, with ownership, source system and propagation direction. Consolidation opportunities identified and a high-impact consolidation rebuilt and tested in production as a worked example, with a written rollback plan communicated before deployment. The final catalogue handed over in the client's tools, with a change-control agreement the team kept using.
Pod performance visibility
SOW 2 · 2 weeksQuarterly pod targets imported from an external document into the platform. A pod cockpit template covering ARR, the usage north star and case study progress against target, with ahead or behind indicators, sliced by lifecycle phase from Establish through Partnership, and forecast versus actual for usage where forecasts existed. Piloted with one pod, iterated on feedback, rolled out to all.
Project prioritisation and action tracking
SOW 3 · 2 to 3 weeksA project-level usage target built on the north star established in SOW 2. A relationship strength property designed jointly with the team. An action log at project level owned by the AE, capturing what was done, why and what happened. A portfolio view per pod splitting active focus projects from next-cycle candidates, so prioritisation became data-informed rather than purely relationship-driven.
The parts that made the numbers hold.
The dashboards were the visible outcome. The reason they stayed trusted was the layer underneath.
Usage rolled from Projects to Organisations to Target Companies, with gap to target and week-over-week movement computed the same way at each level, so the number leadership saw was the number a pod could reproduce.
The biggest week-over-week movers chart was rebuilt to read the target company rollup movement rather than the raw usage delta, so it pointed at the accounts that actually moved the quarter.
Billing data arriving through BigQuery lagged the source. Movement metrics were designed so they measured the customer, not the pipeline, and the failure mode was documented for the team.
Every change carried a written rollback plan and was communicated before deployment. Nothing outside the agreed list was touched without written approval.
Automation catalogue, data dictionary and the estate map handed over in the client's tools and walked through on a call, then kept current under the retainer.
The engagement converted into an ongoing stewardship retainer.
On completion, the client moved to a monthly block of senior hours on a rolling quarterly commitment. The retainer covers stewardship of the rollups, cascades and calculated metrics, direction and QA on dashboards the client's own team assembles, new builds drawn from the block, and a weekly direction call with the CEO and the incoming RevOps lead.
The health scoring build was already queued for the retainer once the product team exposed the usage dataset, alongside numeric scoring to validate the CSM pulse columns and a seat layer once an internal sync project completed.
The pattern transfers.
The specifics were this client's. The method is what we bring to every instance.
Foundation before visibility
The cockpits were only trustworthy because the automation estate and the rollups were fixed first. We will not build dashboards on a data model we have not validated.
Sequenced, with exits
Three SOWs, each usable alone, each a decision point. The client never had to commit to more than the next piece of value.
The client's team kept the skill
Views assembled by the client's own team against our specifications, reviewed before shipping. The retainer directs and QAs rather than replacing the team.
If any of this sounds like your estate, the audit is the first step.
Thirty minutes on the hierarchy, the automation count and what leadership is asking for. You will leave with an order of operations.