The Work

The proof. Specific numbers. Real systems.

Every project starts with a measurable target. Every case study below reports against that target. No "we improved efficiency" -- just the number we agreed, and whether we hit it.

CASE STUDY 01 · CUSTOMER SUPPORT · 6 WEEKS
−60%

60% reduction in support ticket volume -- in the first month after launch.

Industry
SaaS / Customer Support Platform
Company size
~120 staff, 3-person support team
Engagement
Discovery Sprint + Build & Integrate
Timeline
6 weeks build
Success metric agreed
Reduce tier-1 support volume by 40% within 60 days of launch
Outcome
60% reduction in tier-1 volume -- Month 1

The problem

The support team was handling approximately 800 tickets per week. Roughly 70% were tier-1 queries -- password resets, billing questions, feature how-tos -- that required no human judgement. The team was buried in work that didn't need them. Response times were blowing out. They'd tried a basic chatbot 18 months earlier. The team hated it because it gave wrong answers and created more escalations than it resolved.

What we built

An intelligent triage and resolution layer that sits between the customer and the support queue. The system classifies incoming tickets by type and intent in real time and resolves tier-1 queries directly using a knowledge base we built and maintain. Queries requiring human judgement are passed to the team with a suggested response and relevant context pulled from the customer's account history.

Key integrations: Zendesk · Stripe (billing data) · Product knowledge base · Account database

The result

  • Tier-1 ticket volume: down 60% in Month 1 (target was 40%)
  • Average response time on remaining human-handled tickets: down 34%
  • Support team NPS: improved -- staff reported higher job satisfaction

What we'd do differently

The knowledge base we built from scratch took longer than anticipated because the client's existing documentation was fragmented across four systems. We now scope a documentation consolidation phase before any knowledge-base-dependent build -- it's 3–5 days of work that saves 2–3 weeks later.

CASE STUDY 02 · E-COMMERCE · 7 WEEKS
+35%

+35% conversion rate from a personalised recommendations engine.

Industry
E-Commerce (fashion/lifestyle, ~$8M annual revenue)
Company size
35 staff
Engagement
Discovery Sprint + Build & Integrate
Timeline
7 weeks build
Success metric agreed
Increase conversion rate by 15% within 90 days
Outcome
+35% conversion rate -- measured at 90 days

The problem

The business was spending heavily on paid acquisition -- Google and Meta -- but conversion rate had plateaued at around 2.1% for 18 months. The site served the same product grid to every visitor regardless of their browse history, purchase patterns, or intent signals. Return customers -- the most valuable segment -- were getting no personalisation signal at all.

What we built

A personalised recommendations engine that surfaces product content based on individual customer behaviour, purchase history, and real-time session signals. The system runs three recommendation layers: homepage (based on return-visit behaviour), product page (complementary and frequently-bought-together), and post-purchase (replenishment and adjacent category suggestions served via email trigger).

Key integrations: Shopify · Klaviyo · Google Analytics 4 · Custom product taxonomy

The result

  • Conversion rate: from 2.1% to 2.84% -- +35% lift (target was 15%)
  • Revenue attributed to recommendations engine in first 90 days: $280K incremental
  • Email recommendation click-through rate: 4.1× higher than previous static emails
  • Return customer purchase rate: up 22%

What we'd do differently

We built the product taxonomy ourselves because the client's existing tagging was inconsistent. In retrospect, we should have run a 2-week taxonomy sprint with the client's merchandising team before building -- their product knowledge would have improved model accuracy in the first 30 days.

CASE STUDY 03 · SAAS / ANALYTICS · 5 WEEKS
10×

10× faster insights. The analyst role redirected from reporting to strategy.

Industry
B2B SaaS (marketing analytics platform)
Company size
60 staff, 2-person data/analytics team
Engagement
Discovery Sprint + Build & Integrate
Timeline
5 weeks build
Success metric agreed
Reduce time spent on weekly reporting by 70%
Outcome
Reporting time reduced by ~85% -- insights delivered 10× faster

The problem

The analytics team spent roughly 60% of their working week generating standard reports -- weekly performance dashboards for internal stakeholders and client-facing reports for 40+ clients. The reports were valuable. The manual process of pulling, formatting, and distributing them was not. The team had the capability to do genuine analytical work. The reporting workload left almost no time for it.

What we built

An automated intelligence layer that generates, formats, and distributes standard reports with no human involvement -- and surfaces anomalies and insights that previously required an analyst to spot. The system pulls from the client's data warehouse on a schedule, generates plain-English summaries of performance trends, flags statistically significant changes, and distributes formatted reports to the right stakeholder via email and Slack.

Key integrations: BigQuery · Looker Studio · Slack · Sendgrid · Client's proprietary data pipeline

The result

  • Time spent on standard reporting: down ~85% (target was 70%)
  • Time to insight delivery: from 3–4 days to same-day
  • Anomalies caught in first 90 days that were previously missed: 7 significant performance issues flagged before clients noticed
  • Analyst capacity redirected to strategic work: ~12 additional hours per analyst per week

What we'd do differently

The Slack integration took longer than scoped because the client's Slack workspace had a non-standard permissions structure. We now do a Slack/comms audit as standard in the discovery phase for any engagement involving notification or distribution systems.

More case studies added as engagements are completed.

We don't publish case studies until we've measured the outcome against the metric we agreed in Phase 1. That's why this page grows slowly -- and why every number on it is real.

Curious whether we've solved a problem like yours? Ask us directly
Next step

Ready to be the next case study?

Every engagement starts the same way: we agree the metric that defines success before we build anything. If we hit it, you get a result you can point to. If we don't, we stay until we do.

Book a call See our process