Case Studies

Systems your team keeps using.

Growth rarely needs new software. The problems everyone has learned to live with are the ones that quietly break a venture.

Where this shows up in life sciences

The default response to a broken workflow is to buy something: a new platform, a new tool, a new system to learn. Yet the organisation usually already has the data, the infrastructure and the people who know how the work really happens. When systems fail, the cause is rarely digital. It is that the pieces sit in different hands, with nobody connecting them to what the business now needs.

How to intervene, before or after it breaks

The work starts with what is already there. Add a layer of purpose rather than force a replacement, and move sequentially and with empathy alongside IT, systems engineers, scientists, and the commercial and operations teams, so the people who will use it recognise it as theirs. A system creates value only if it survives the person who built it. In a scale-up, an unowned process erodes one departure at a time. Some processes hold on their own. Others need an owner who stays.

Case 01 · CRM & data

Which Oxford, and which Toledo

There are more than twenty places called Oxford in the United States, so a CRM with no geographic context has no way of telling them apart. The ambiguity is routine rather than an edge case.

It stopped being a curiosity the day an instrument bought by a Spanish customer shipped to Toledo, Ohio, instead of Toledo, Spain. A wrong destination, a delayed delivery, and a customer waiting for equipment that was crossing the wrong ocean.

Logistics owned the shipping addresses, sales owned the customer records, and IT owned the CRM, so each team saw a fragment of the problem and none of them saw it whole. Working with all three, we added a geolocation layer onto the CRM the sales team already used every day. A small map now sits on every customer profile, and the right Oxford is visible before anyone confirms an address.

Same tool, same habits. The address is now unambiguous before anyone confirms it.

Case 02 · Quote-to-order

From a week to a day

The company's core product was built to order. Requesting a quote meant completing a three-page Word document and emailing it back, full of technical fields that many customers could answer only with help. Establishing what the customer actually wanted took a week before production could start pricing it.

Sales wanted fewer emails, production wanted complete specifications, and IT wanted no new platform to support. Working with the three of them, we built an online request system on the corporate workspace the company already had. The form calls directly into the product repository, so what a customer enters arrives structured and complete for the production team.

A week of back-and-forth became a same-day quote, answered in a couple of clicks.

Six years on, the system still runs with no maintenance team behind it. It was built simply enough, on infrastructure people already trusted, to survive without an owner.

Case 03 · R&D to commercial

Closed tickets, lost know-how

An external consultancy had designed a continuous-improvement workflow on a DevOps platform built for software bugs and IT tickets. Over time it spread to the wet-lab scientists, who began running their own research projects through it.

The platform was designed to close tickets, so every research project ended marked closed, with no link between the money invested and what could be done commercially with the knowledge it produced. Turning that know-how into something sales could use sat with everyone and therefore with no one.

R&D owned the projects and marketing owned the collateral, and the two rarely met inside the same system. Working with both, we added a layer of actions inside the tool scientists already used daily. Closing a project now requires naming its outcome: an application note, a case study, or another piece of collateral the commercial team can use directly.

It ran for seven months and produced nine pieces of collateral. Then publishing tailed off. The design held; the ownership did not. That is the difference between a process that survives and one that needs someone to stay.

Case 04 · Document and quality management

Ownership, written down

Documentation, SOPs, working instructions and controlled documents were spread across the organisation, with ownership held informally rather than recorded anywhere.

Rather than buy a specialised DMS or QMS platform, we worked with the infrastructure already in place and built a document-tracking index as a low-code database inside the system every employee used daily. A new tab now carries clear ownership of every SOP, working instruction and controlled document on file.

The result is a working layer of quality control and document traceability, with more than 2,000 documents indexed and an owner named against each one. No new platform to buy, and no system anyone had to learn.

Comfort is expensive

Each of these started as something people had learned to live with. Not urgent enough to fix, just annoying enough to complain about. That comfort compounds until it costs far more than the fix would have.

Some of these systems needed nothing after launch. Others needed someone to stay. If you are unsure which is yours, let's have a chat.

Let's have a chat →