[ Case study ]
Installations run twelve weeks through survey, design, permits, and crews — and customers called weekly for status because the only tracking lived in the ops team's project tool; the office estimated a third of its phone time was status calls.
CLIENT a regional residential solar installer — FOCUS Project the kanban, don't duplicate it
Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.
Selling and installing rooftop solar across a single metro region, the client runs its own crews from first survey to final inspection. A typical installation moves through survey, design, permitting, and crew scheduling over about twelve weeks, crossing the installer's teams, the municipal permitting office, and the utility along the way. The company had grown past the point where the owner could personally reassure every household, yet its tracking lived inside the operations team's kanban board — a tool built for crews, not for the family paying for the roof.
Installations run twelve weeks through survey, design, permits, and crews — and customers called weekly for status because the only tracking lived in the ops team's project tool; the office estimated a third of its phone time was status calls.
We proposed a customer status portal that projects the existing kanban board rather than duplicating it: the portal reads stage history from the project tool's API and renders it in customer language, so operations keeps one place to update and the portal can never disagree with the crew's reality. Households get per-person access tied to the project — spouses, adult children, whoever co-owns the decision — ending forwarded logins. For permit and utility stages, the portal says exactly what is true: waiting on the utility, with a plain-language explanation, instead of a fabricated percentage or a date nobody can keep.
Just as important is what we ruled out, and why:
The portal reads stage history from the project tool's API and presents it in customer language, so ops keeps one place to update and the portal never disagrees with it.
Any household contact can be granted their own access tied to the same project, ending forwarded logins forever.
Stages that depend on utilities or municipalities show their real nature — 'waiting on the utility' with a plain-language explanation — instead of a fake percentage.
Delivered by the systems pod — engineer + automation specialist over 9 weeks, with working increments reviewed with the client every week.
Obstacle
The first stage-to-customer mapping used the board's own vocabulary — what ops called a stage and what homeowners heard were different enough that preview households misread their status.
Handled: We wrote the glossary with the office staff who take the calls, rebuilt the mapping from their phrasing, and re-tested with the same preview households.
Obstacle
The kanban API exposes stage-change events only going forward — installs already in flight had no history, and those households were the angriest callers.
Handled: Ops walked the in-flight boards once with us; we seeded each active project's current stage manually and let the API take over from the next real transition.
Obstacle
Staff had been quoting permit dates the city never gave; the first honest waiting-on-the-permitting-office screens worried the owner, who feared they read as delay.
Handled: We paired each wait state with a one-line explanation of what the office is doing, and call logs showed those screens defused calls rather than inviting them.
The headline: households onboarded at contract signature, with stage changes visible within minutes of ops updating the board — Status calls → self-serve portal, read from Office call-log sampling. A second check: inbound status-call volume at −58%.
The where-is-my-install calls that still arrive are about decisions now — design changes, scheduling conflicts — not about the board. Staff answer fewer of them altogether; households check the portal at dinner instead of calling at lunch, and sharing access with a spouse ended the second-call problem. The honest wait states changed the office's posture: staff no longer invent dates to end conversations, because the portal told the truth. Ops kept their board untouched — the tool succeeded because it asked the crew to change nothing.
The result was read from Office call-log sampling against the pre-engagement baseline over the stated window, with a guardrail check on inbound status-call volume. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.
What we would do differently
We would write the customer-language glossary with the ops team first — the kanban stages and what customers call them differed enough that the first mapping needed a redo.
[ Related service ]
[ Related builds ]
0 pilot-ready productBooking MVP live with the first pilot cohort scheduled and samples reconciled through the ops console
Guarded calendar clinician-authored schedulingAll clinicians on published availability, with the office manager out of the booking path
[ Next step ]
Next case study
