This area is for existing clients. Please enter the password to continue.
Hover over a logo to see what we did
Virgin Atlantic Airways ('VAA')
VAA suspected it was burning fuel unnecessarily and was not leveraging its large volumes of available data to address this. Fuel represents 20%-35% of an airline's operating costs, and VAA has sustainability targets (15% net CO2 reduction by 2030, 10% SAF). Of thirteen fuel categories, "arrival delay" fuel was added manually based on human intuition, despite being influenced by weather, no-fly-zones and fuel tankering — data VAA could access.
An end-to-end proof of concept on VAA's Databricks-based Enterprise Data Platform (EDP) using a medallion (Bronze/Silver/Gold) architecture. We built a pipeline and model dataset combining flight fuel/leg tables, the planner "statistical arrival delay", and weather data (historic via Meteostat and Open-Meteo; forecast via the Weather Aviation Centre). Multiple ML model types were explored, including a hurdle model (classifier for "delayed or not" plus regression for delay size). Deliverables included reproducible code, a prediction API, a Power BI dashboard for scenario and decision support, and documentation, with the pipeline being prepared for productionisation on AWS and Azure Databricks.
The final model reliably flags no-delay flights and predicts small delays to within ~±5 minutes on average, outperforming both human estimates and the existing "statistical arrival delay". Used as decision support, integrating the model into planning is projected to save in excess of $0.6m per year based on historical comparisons, with associated CO2 reduction supporting VAA's sustainability targets.
Cazenove Capital, part of Schroders · January 2026 to April 2026 (3 months)
Cazenove Capital had access to three leading corporate databases on the UK; BoardEx (used to identify individuals on boards), Beauhurst (various data on private companies including financials) and Preqin (the leading private equity and venture capital investment database). While they enjoyed a wealth of information about potential leads, these market-leading businesses were not generating business value.
A prioritised call list visible within Salesforce to allow the team to easily identify the highest probability-value weighted targets. For business development purposes, these databases had no natural key and needed to be joined, which we achieved with algorithmic heuristics. We developed a model to distinguish which founders and executives were involved with companies most likely to achieve further fundraising, which might involve the sale of secondary equity, or be targets for M&A and therefore receive sale proceeds.
Conversion of potential new clients increased by c. 15% once prioritised lists, using our bespoke scoring system, was adopted. Business development activities now had a defensibly empirical basis, paving the way for further developments in approach.
Tourflow · September 2025 to December 2025 (14 weeks)
Tourflow makes boutique software for professional music tour managers. Tour management software traditionally requires tour managers to manually enter every date, venue, hotel, journey and a daily schedule into a series of forms. For a large tour this means hours of data entry every week. Tourflow aspirationally wanted to replace this process by allowing tour managers to copy-paste unstructured data they already have, in bulk: date-list emails, notes, booking confirmations and PDFs. It's very easy to create a working demo for this using "structured output" LLM calls, but making such a system reliable enough for production is much harder. Real-world inputs vary enormously in length and formatting, contain misspellings and irrelevant text, and include unusual cases such as festivals without conventional addresses. In touring, mistakes have an extremely high impact on margins, so there's a high bar for accuracy.
We built a multi-stage labelling pipeline that converts unstructured tour information into structured data (reducing data entry tasks previously taking as long as 1 hour down to 15 seconds), but most importantly we left the client with a robust eval framework that allows them to have high confidence about the performance of the pipeline on wide distributions of input data. It consisted of representative input/expected-output pairs representing the entire input data distribution, plus deliberately difficult cases designed to find the system's breaking points. The evals produce a trail of historical scores, and field-level diffs between expected and actual results, so any inaccuracy is surfaced clearly for future developers. Alongside this, we implemented pessimistic logging throughout the labelling pipeline, which retains complete prompts, LLM responses and HTTP metadata, exceptions and stage timings. This allowed operators to understand any errors extremely quickly, recreate failing LLM calls at the click of a button, and one-click dispatch a coding agent to add that as a future eval case.
Tourflow is now a technological leader in the space, and has won many new customers off the back of specifically this feature. The eval and observability infrastructure has turned reliability improvement into a systematic process: failures become identifiable test cases that are dispatched to the eval suite and prevented from recurring. After iterating against this framework, the pipeline is now reliable across the small-to-medium UK and European tours managed by Tourflow’s initial users.
NHS · October 2023 to February 2024 (19 weeks)
The NHS had a c. 40 person team which was dedicated to manually merging healthcare records where they pertained to the same patient i.e. dealing with duplicated records for the same person. The allocation of new NHS numbers took place within Spine II, the NHS' core data system, comprising c. 250k lines of code and with no testing environment which could be used to successfully test AWS connectivity for analytics/ETL purposes.
We made use of Home Office data in the allocation of NHS numbers for the first time, making use of various data points and heuristics to significantly improve the identification of patients who are presenting as new at the point of service. As a result, the creation of new NHS numbers was much better calibrated to genuine new patients -- shown and continually monitored through comprehensive analytical reporting (PowerBI dashboards over Redshift). New code included full-coverage unit and integration testing, then navigated review from Clinical Risk and Solutions Assurance teams, and successful release into production.
Duplicated NHS numbers reduced by c. 30%, with a corresponding saving of c. 12 FTEs. This work was undertaken after two other consultancies had tried and failed to successfully complete the project.
Omnipresent (since acquired by Deel) · October 2021 to January 2022 (14 weeks)
Omnipresent (now part of Deel) was a service that let companies hire remote workers from different countries as if they were domestic. Omnipresent acted as a domestic financial/legal proxy for those people, taking their salary payments and forwarding them, and handling all complexities of local employment law across 200+ countries. During COVID, they went into hypergrowth mode as the entire world flipped to remote-first. Their growth was bottlenecked at creating employment contracts for the remote workers they hired. This was a manual process when we were engaged, and we had to alleviate this bottleneck.
Partnering with a small team at the client, we created a fully automated system for autogenerating employment contracts. A major part of the project was a web app that presented the remote worker with an employment details form to collect all the details that needed to be in the contract. The form was entirely autogenerated, based on the employment rules of their country/jurisdiction - a bit like a custom instance of the startup Typeform. The details from this were matched to one of 200 employment contract templates, which were filled to create the real employment contracts, automatically sent to Docusign for signing.
The bottleneck was alleviated enough that the rate-limiting step of the company's expansion moved elsewhere in the stack. Initial implementation, which targeted the countries responsible for 60% of contracts, successfully fully automated this step, freeing up a team of 6 people to handle edge case countries. A clear roadmap and direction was left behind for the client for automating the remaining countries' contracts.