Case studies answer what happened when a problem got solved. This page answers a different question: what actually gets created while solving it. Operating models, strategy and executive communication, service and implementation design, growth and adoption programs, analyses, and prototypes.
Organized by business problem across several organizations. Visuals are redrawn from the structure of the original work. How this was prepared · Read the case studies →
Most operational work dies in translation. This is the part of the job that decides whether a room full of busy people leaves with the same understanding and one clear next step. The craft here is not presentation design. It is deciding what deserves the reader's attention and what does not.
Size of the underlying work. 3 published here.
One review structure applied across a portfolio of enterprise accounts at three cadences: post-launch, monthly, and quarterly.
A repeatable way to explain a live product problem to enterprise customers: what is broken, what is being fixed now, what is being fixed properly, and who tells whom.
A structured competitive analysis examining the market through product, customer experience, pricing, support, positioning, strengths, weaknesses, and strategic opportunity.
The structures underneath the case studies: how work is routed, who owns it, what gets measured, and what happens when something goes wrong. These are blueprints. Some ran in production, some were designed and partially adopted, and each one says which.
Size of the underlying work. 10 published here.
A complete communication architecture spanning purchase through long-term customer success, designed as an operating system rather than a set of messages.
A customer experience operating model spanning onboarding, lifecycle design, service standards, self-service, measurement, and long-term customer engagement.
A framework for reading customer signals, separating recoverable customers from finalized losses, and matching an intervention to the reason rather than the symptom.
An operating model for orders: one rule that settles ownership, a split-intake work design, and a decision tree an associate can run in the moment.
A three-layer model separating the operating model from the directory from the executable steps, with one rule preventing version drift.
Nine lifecycle stages drawn alongside the specific failure that occurs at each one, with the current state and the intended state stated side by side.
A single response baseline for every task, the exceptions that earn a tighter clock, and the rule that a task may stay open but not stay untouched.
An intake specification for automation and partner communication requests, built so that a request has to describe its own trigger, source of truth, and proof of success before it can be ranked.
A move modeled as two dependent orders rather than one job, with the link between them treated as the thing most likely to fail.
A working partnership with the Professional Services function that grew from case-by-case coordination into a standing channel for solution scoping, quoting, and long-term account growth.
Real work not yet prepared for publication. These are not published projects.
Severity definitions, routing paths, response clocks, and the decision rules that keep a serious issue from being handled as a routine one.
What gets reported, to whom, how often, and what each number is supposed to trigger.
Where assisted decisioning belongs in an operation, what it should never own, and how to keep a person accountable for the outcome.
A system only works if the people expected to run it understand it. This category is about the unglamorous half of every launch: training the staff, writing the guide, testing the build before customers see it, and making sure the person at the front desk has an answer.
Size of the underlying work. 6 published here.
Step-by-step onboarding and account setup guides written for front line staff during large multi-location rollouts, including migrations between billing systems.
A structured walkthrough of a product's full feature set, organized the way a user encounters it rather than the way it was built.
Instructions and expectation-setting that let non-technical client stakeholders test a pre-release build without breaking anything or misreading what they found.
A four-phase competency model and the three-week ramp that carries it, built so an associate earns queue ownership rather than being handed it.
A pre-installation qualification standard and the review loop behind it, turning a physical site constraint into a data gate before a crew is ever dispatched.
Reading lost disputes as an operational defect log rather than a finance problem, and mapping each reason code back to the moment in the order path where the customer lost confidence.
Some work solves today's problem. Some work changes how tomorrow's conversations happen. This is the work of turning customer behavior into something an organization can act on: what people actually do, whether they come back, and what to change when they do not.
Size of the underlying work. 4 published here.
A standard way to read adoption, active usage, cohort retention, and growth loops across a portfolio of accounts, and to turn each read into a specific recommendation.
Turning public reviews, ratings, and open-text feedback into coded reasons, counted themes, and assigned owners.
A charter for high-touch outreach: who qualifies, what is offered, who owns each stage, what could go wrong, and how success is measured before anything is sent.
A single log that turns scattered field and partner feedback into rows with a topic, an owner, a priority, and a state, reviewed on a fixed cadence.
Concepts that came out of operational and customer problems rather than a roadmap exercise. Every item here informed a strategic discussion. None of them are claimed as launched, and the ones that were never built are still worth showing, because the reasoning is the artifact.
Size of the underlying work. 1 published here.
Real work not yet prepared for publication. These are not published projects.
Using engagement and satisfaction signals to identify likely promoters, and rewarding the behaviors that build a habit rather than only the purchase. Proposed as an extension of the customer health work.
A short in-product survey shaping a first session: a product walkthrough, an equipment walkthrough, and a starting plan matched to what the customer said they wanted. Proposed.
Help positioned where the problem happens rather than in a separate destination, with topic usage deciding what gets rewritten or retired. Partially explored, not fully built.
An assistant handling the repeatable layer, with inactivity nudges, scheduled check-ins, and order-status communication reaching customers before they have a reason to write in. Proposed.
Removing the password from the entry path, and using a tap-to-connect interaction to skip pairing steps that generate a predictable share of support volume. Explored as concepts.
Letting a customer check whether the product fits their space before they buy, rather than discovering the answer on installation day.
Design thinking in service of a decision. These are not marketing artifacts. They are the drawings used to get a room to agree on what a screen, a report, or a workflow should do before anyone spent money building it.
Size of the underlying work. 1 published here.
Real work not yet prepared for publication. These are not published projects.
The reusable document architecture behind recurring reviews: fixed sections, defined slide purposes, and a rule about what is allowed to be added.
Drawing a process as it actually runs, including the informal steps, so the room can argue about the real workflow rather than the documented one.
Each entry carries its own implementation status. How materials were prepared for publication is described in the portfolio disclosure.