A workflow screenshot doesn’t tell you much. What matters is why the system was behaving the way it was, what was changed, and how anyone knew the change worked. That’s what these case studies try to show.
How we write them
Every case study follows the same structure, usually told in the order things happened:
We only report outcomes we could measure or observe directly. If a result depended on other factors, such as a pricing change or a new sales hire, we say so rather than claiming it. Client names and details are published only with permission, and some case studies are anonymized for that reason.
Case studies
The first case studies are being written up with client approval.
Each one will be published only once the client has signed off on the details. Until then, the best way to see how we work is a short call, where we can walk through anonymized examples of audits and lifecycle maps.
Looking for something specific?
We title case studies by the problem rather than the platform, because the same failure tends to appear across tools. An unreliable lifecycle stage looks much the same in HubSpot as in Zoho. If you’re after platform detail, the HubSpot and Klaviyo pages describe the typical issues we see there, and our resources go into the mechanics.