Case Studies

Three jobs, and what was actually involved in each.

Building support from nothing at Fishtank

100%
of CSAT responses positive in the measured period
Zero
client churn over the same period
From scratch
help desk, SLAs, routing and the first support hires

Context

When I joined Fishtank there was no support function. Client requests got handled ad hoc by project managers and developers over email. Things slipped, response times were whatever someone's calendar allowed, and leadership had no way of knowing whether clients were happy.

What the business needed was a support department that could scale, deliver the same thing twice, and give clients a reason to stay.

What I did

I mapped the customer journey first, to find where clients were getting stuck and which questions kept coming up. The support model came out of that rather than out of a template.

  • Selected and implemented a help desk, mostly for visibility and accountability
  • Defined SLAs that differed by request type instead of one blanket number
  • Built routing so the right issues reached the right people without someone having to intervene

Then I hired and onboarded the first support staff and set up coaching rhythms and quality expectations. I wanted clear accountability with enough room for people to do the job their own way.

Outcomes

  • Every CSAT response in the period was positive
  • No client churn during the same period
  • Reporting that showed volume, trends and performance rather than anecdotes
  • Tooling and process that could take more people without being rebuilt

Support turned into something sales could point at. Tracking recurring issues and feeding them back into product and delivery stopped a lot of problems before clients saw them.

Key takeaway

The tickets were never really the point. What the business needed was something clients could rely on and something leadership could actually see.

Incident response at Shopify

Merchant-facing
downtime, payments and security incidents
Faster resolution
through standardised coordination and clearer decision rights
Playbooks
documented, so newer responders could take the lead sooner

Context

On the Incident Response team at Shopify I handled situations where something had broken badly enough that merchants noticed. Downtime, payments, security. The team coordinated the response across engineering, external partners and senior leadership.

Minutes mattered, and how well the communication went had a direct effect on whether merchants trusted us afterwards.

What I did

The role was part coordination, part strategy, part communication.

  • Ran incident war rooms and kept stakeholders aligned while the picture kept changing
  • Held several fast-moving streams of information at once and decided what mattered
  • Made calls on incomplete data and made sure merchants got clear updates on time

Between incidents I worked on the system itself. Refining triage models, documenting playbooks, mentoring newer responders, and working with teams outside Incident Response on prevention.

Outcomes

  • Faster resolution through standardised coordination and clearer decision rights
  • Communication to leadership and merchants that held up under complexity
  • Newer responders able to take the lead sooner, because the playbooks existed

Key takeaway

The hard part of incident response isn't the technical work. It's making decisions on incomplete information while a lot of people wait on you, and being straight with customers about what you don't know yet.

Scaling support and launching live chat at Hospitable

5 months
from assessment to live chat launched
Follow-the-sun
coverage across multiple time zones
2 BPO regions
Honduras and the Philippines, on one shared quality bar

Context

I joined Hospitable during a growth phase. Volume was climbing, and we had five months to launch live chat across multiple time zones while working with BPO teams in Honduras and the Philippines. Internal knowledge management was thin, so agents were often guessing.

The challenge wasn't adding a channel. It was building enough structure underneath it that the channel didn't collapse the first busy week.

What I did

I started with an assessment of the support model as it stood.

  • Mapped coverage by region and found the gaps in response times
  • Reviewed queues and trends to understand when demand actually arrived
  • Documented the existing processes, including the points where they broke

Then I designed a follow-the-sun model and worked with the BPO leads on expectations, process and quality bars. We rebuilt internal documentation so agents had the same information regardless of where they sat.

For live chat I led the rollout end to end. Coverage schedules without a dedicated WFM team, chat-specific SLAs, training on real-time communication, and reporting so leadership could compare channels.

Outcomes

  • Live chat launched inside the five-month window
  • Wider time zone coverage and shorter waits for customers outside North America
  • More consistent quality from BPO teams once process and documentation were shared
  • Visibility into SLAs, volume and performance across every channel

Key takeaway

Adding a channel is the easy part. Keeping it staffed, documented and measured is what decides whether it survives the first busy month.

If something here looks like your situation, get in touch.