Work

Four engagements, told the way we would tell them on a call

Challenge, approach, technologies, outcome. The numbers are the ones we measured against a baseline captured before we changed anything, not adjectives dressed up as results.

E-commerce applicationFMCG32% fewer mid-campaign stockoutsreduction
Healthcare applicationHealthcare46% of routine enquiries handled without a callimprovement
Software / patient managementHealthcare4 sites consolidated onto one patient recorddelivered
Leads management softwareBanking & Fintech27% lift in qualified-lead conversionimprovement
Manufacturing platformManufacturing31% fewer unplanned line stoppagesreduction
Manufacturing simulationManufacturing4× faster to evaluate a proposed line changeimprovement
Lending applicationBanking & Fintech68% less time per affordability assessmentreduction
FMCG data platformFMCG3× more markets modelled in launch planningimprovement

E-commerce application

E-commerce application with demand-aware merchandising

Challenge: A fast-moving consumer goods business was running promotions on instinct. Best sellers went out of stock mid-campaign while slower lines were discounted into a loss, and nobody could say which decision had caused which result.
Approach: We built the storefront and order platform, then wired a demand model into the merchandising layer. Sales, stock position and campaign calendar feed a forecast that ranks what to surface and flags lines heading for a stockout before the promotion goes live.
Outcome: Merchandising decisions moved from a weekly meeting to a daily ranked list, and the stockouts that used to end campaigns early became a pre-campaign warning instead of a post-mortem.

32%

reduction

fewer mid-campaign stockouts

Next.js
Python
Databricks
PostgreSQL
AWS
Kubernetes

Healthcare application

Patient-facing healthcare application

Challenge: A care provider's patients were booking, rescheduling and asking routine questions by phone. The call queue was the bottleneck for everything, and clinical staff were absorbing administrative load that had nothing to do with care.
Approach: We designed and built the patient application covering appointments, records access, secure messaging and pre-visit questionnaires, with an NLP triage layer that routes incoming messages to the right team and answers the routine ones from approved content, escalating anything clinical to a human.
Outcome: Routine enquiries moved out of the call queue entirely, and the clinical team now sees a triaged inbox rather than an undifferentiated one.

46%

improvement

of routine enquiries handled without a call

Kotlin
Jetpack Compose
Python
Azure
Azure AI Language

Software / patient management

Patient management system for a multi-site provider

Challenge: Four sites, four ways of recording the same patient. Referrals were re-keyed between systems, duplicate records were routine, and no one could produce a reliable view of a patient's history across the group.
Approach: We consolidated the record onto a single scheduling, records and referral platform, and built a record-linkage model to resolve the duplicates that had accumulated over years of parallel data entry. Clinician-facing screens were designed with the staff who use them between appointments, not around them.
Outcome: One patient record across all four sites, with referrals moving between them without re-keying and a clean audit trail behind every merge the model proposed.

4 sites

delivered

consolidated onto one patient record

Python
PostgreSQL
Azure
Docker
Kubernetes
HL7 FHIR

Leads management software

Leads management software with predictive scoring

Challenge: A lending team was working its pipeline in submission order. High-intent applicants waited behind enquiries that were never going to convert, and the sales team's own sense of which was which had never been tested against the outcomes.
Approach: We built the leads platform covering capture, routing, activity tracking and reporting, then layered a scoring model trained on historic conversion data on top. The queue is now ordered by likelihood to convert, with the reasons for each score visible so the team can disagree with it and have that disagreement feed back into training.
Outcome: The pipeline reordered itself around intent rather than arrival time, and reps stopped spending their first hour deciding who to call.

27%

improvement

lift in qualified-lead conversion

Next.js
Python
scikit-learn
MLflow
AWS
Docker

Manufacturing platform

Predictive maintenance on production equipment

Challenge: A manufacturer was running maintenance to a fixed calendar. Machines that were healthy came off the line for servicing they did not need, and the ones that failed did so between scheduled visits, taking the line down with them. The sensor history that would have distinguished the two was being logged and then discarded.
Approach: We built the pipeline that retains and aligns the machine telemetry, then trained failure models per equipment class against the maintenance log so the target was a real recorded fault rather than a proxy. Predicted failures surface as ranked work orders in the maintenance system the engineers already open each morning, with the contributing signals shown next to each one.
Outcome: Maintenance planning moved from the calendar to the condition of the equipment, and the shift engineers get a ranked list each morning with the reasoning attached rather than an alert they have to take on trust.

31%

reduction

fewer unplanned line stoppages

Python
Databricks
MLflow
Azure IoT
Spark
PostgreSQL

Manufacturing simulation

Digital twin of the production line

Challenge: Every proposed change to the line, whether a new product mix, a reordered station or a shift pattern, had to be argued from experience, because the only way to test it was to try it on the real line and accept the cost of being wrong.
Approach: We built a simulation of the line calibrated against its own historical throughput, cycle times and failure rates, so its baseline behaviour matches what the plant actually did. Planners run a proposed change against it and get throughput, bottleneck and utilisation figures before anything is moved, with the model re-calibrated as new production data arrives.
Outcome: Line changes are now argued with a simulated result attached, and the debate has moved from whose experience to trust to which assumption in the model to examine.

4×

improvement

faster to evaluate a proposed line change

Python
SimPy
Databricks
Azure
Next.js
PostgreSQL

Lending application

Bank statement analyser for lenders

Challenge: Credit teams were reading PDF bank statements by hand to assess affordability. Every lender's statement format differs, the work is slow and inconsistent between assessors, and the decision has to be explainable to a regulator afterwards.
Approach: We built an analyser that parses statements from any layout, classifies each transaction into income, committed spend and discretionary categories, and surfaces the patterns lenders actually underwrite against: salary regularity, existing obligations, returned payments and month-end position. Every derived figure links back to the transactions it came from, so an assessor can audit the number rather than accept it.
Outcome: Affordability assessment became a review of a structured summary rather than a manual read of a PDF, and each decision carries the transaction-level trail an auditor asks for.

68%

reduction

less time per affordability assessment

Python
Transformers
FastAPI
PostgreSQL
AWS
Docker

FMCG data platform

Synthetic data generation for national product performance

Challenge: Product performance was well covered in the regions with established retail reporting and thin or absent everywhere else. Planning national launches from that data meant treating the reported regions as if they represented the country, which they did not.
Approach: We trained generative models on the regions with dense history, conditioned on the attributes that actually differ between markets: store format, seasonality, price tier and category mix. We used them to synthesise plausible performance for the gaps. The output carries confidence bands, and the model is validated by holding out a well-covered region and checking whether it reconstructs it.
Outcome: Planners can now model a national launch across every market rather than extrapolating from the reported ones, with the synthesised regions clearly marked as modelled and carrying their own uncertainty.

3×

improvement

more markets modelled in launch planning

Python
PyTorch
Databricks
MLflow
Spark
Azure ML

Your problem next

If one of these looks like your situation, say so

The fastest calls we have are the ones that open with 'we have the third problem on your work page'. Point at the closest match and we can start from what we already know.

Book a consultation hello@post-ql.com

We reply to every enquiry within one business day.