The Strange Labs
Case studies

Real problems. Shipped solutions.

Three engagements, each framed by the problem we were handed, the constraint that shaped the build, and what actually changed.

Staff console showing WhatsApp conversation threads and report delivery statusimages/case-01-whatsapp.png
Diagnostics

Ending the “is my report ready?” phone call

Meridian Diagnostics · Pathology network, 40+ collection centres

Meridian runs collection centres across three states and processes several thousand samples a day. Every one of those samples generates a patient who wants to know when their report will be ready. Front desk staff were spending most of the working day on the phone answering that single question, and technicians were emailing PDFs by hand at the end of each shift.

The problem

The reports themselves were fine. The delivery around them was the problem. Patients called two or three times before a report landed, staff could not give a reliable answer because they had to check the lab system themselves, and reports frequently went out hours after they were actually signed off.

What we built

  • WhatsApp flows on the official Business API for report delivery, appointment booking, fasting and prep instructions, and collection reminders
  • A bridge service that watches the lab system and pushes a report the moment it is authorised, rather than waiting for someone to send it
  • A staff console showing every conversation, so front desk can step into any thread
  • Templates approved through Meta for the six message types that go out at volume
  • ~70%

    drop in report-status calls

  • Minutes

    from sign-off to patient, previously hours

  • 6 wks

    to first flow live in one region

Stack
  • WhatsApp Business API
  • Node.js
  • PostgreSQL
  • Redis
  • Docker
  • AWS
Timeline

6 weeks to first region, 11 weeks to full rollout

Dispatch planning board showing vehicles, legs and live status across three branchesimages/case-02-dispatch.png
Logistics

Replacing the nightly dispatch spreadsheet

Ashwin Roadlines · Regional freight operator, 3 branches, ~120 vehicles

Ashwin plans its next-day dispatch every evening. Until last year that planning happened in a spreadsheet at each of three branches, which was emailed around at about nine at night and reconciled by hand the following morning. Drivers phoned the branch when they loaded, when they left, and when they arrived.

The problem

The three branches could not see each other's plans, so the same vehicle was occasionally committed to two loads on the same day. Nobody could answer where a given truck was without making a phone call. The operations head described his job as “being a switchboard”.

What we built

  • A dispatch planner with a shared vehicle pool, so a truck committed at one branch is immediately unavailable at the others
  • A driver app for load acceptance, status updates and proof of delivery photographs
  • A live board for the operations desk showing every vehicle and its current leg
  • Role-based access so branch managers see their own operation and head office sees all of it
  • ~2 hrs

    saved on nightly dispatch planning

  • Zero

    double-bookings since the shared pool went live

  • 11 wks

    from kickoff to all three branches running on it

Stack
  • React
  • PWA + IndexedDB
  • Django REST
  • PostgreSQL
  • S3
Timeline

11 weeks, including a 3-week rebuild of the driver app

Helpdesk view with an assistant reply quoting a policy clause and linking to the source pageimages/case-03-assistant.png
Insurance

An assistant that has to cite the clause or say nothing

Fairmont Insurance Brokers · Commercial broker, 40+ products, 22-person support team

Fairmont's support team answers questions about policy wording all day. The wording lives across roughly nine hundred pages spanning more than forty products, and the answer to most questions is a single clause buried somewhere in it. New agents took months before they could answer confidently without escalating.

The problem

Fairmont wanted an assistant inside the helpdesk their agents already use. The hard constraint was that a wrong answer about policy wording is worse than no answer at all, because an agent may repeat it to a client in writing.

What we built

  • A retrieval assistant embedded in the existing helpdesk, so agents never change tools
  • Answers that quote the clause and link to the exact page, or decline
  • A refusal path that escalates to a senior underwriter rather than guessing
  • An evaluation set of 300 real historical tickets, run automatically on every change
  • ~40%

    faster first response on wording questions

  • Weeks

    not months for new agents to answer unaided

  • 0

    uncited answers reaching an agent

Stack
  • Python
  • FastAPI
  • PostgreSQL + pgvector
  • Open-weights model in their VPC
  • Helpdesk API
Timeline

8 weeks to pilot, 3 further weeks hardening evaluation before rollout

Your project could be next.

Tell us what you’re working on and we’ll show you how we’d approach it.

Font labtest only

Pick a typeface to preview it across the whole site. Your choice is remembered as you browse between pages.