Industries

Four sectors we arrive already understanding

Sector experience is not a marketing claim. It is the difference between spending the first month learning your constraints and spending it solving the problem. These are the four where we have shipped production work.

Healthcare

Healthcare work carries constraints most sectors do not: the data is sensitive, the audit trail is not optional, and a system that is merely usually right is not good enough. We build for those constraints from the first design conversation rather than retrofitting them before go-live.

What we are called in for

1
Fragmented patient records
Multiple sites recording the same patient in different systems, with duplicates that accumulate faster than anyone can reconcile them by hand.
2
Clinical documents nobody can query
Notes, referrals and correspondence that hold the answer but sit as unstructured text outside any reportable field.
3
Administrative load on clinical staff
Scheduling, triage and routine enquiries absorbing time from people who were hired to deliver care.

Services most often engaged here

Work delivered in Healthcare

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.

46%

improvement

of routine enquiries handled without a call

Kotlin
Jetpack Compose
Python
Azure
Azure AI Language

Outcome

Routine enquiries moved out of the call queue entirely, and the clinical team now sees a triaged inbox rather than an undifferentiated one.

Sector: Healthcare

Read the case study

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.

4 sites

delivered

consolidated onto one patient record

Python
PostgreSQL
Azure
Docker
Kubernetes
HL7 FHIR

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.

Sector: Healthcare

Read the case study

Manufacturing

Manufacturing floors generate enormous quantities of signal and use very little of it. The gap is rarely the sensors. It is that the data lands somewhere nobody looks until a line has already stopped. We build the pipelines and models that move that signal forward in time, and the shop-floor applications that put it in front of the person who can act on it.

What we are called in for

1
Unplanned downtime
Maintenance driven by failure and calendar rather than by the condition data the equipment is already producing.
2
Quality inspection at human speed
Defect detection that cannot keep pace with the line, so sampling stands in for inspection and problems are found in batches.
3
Data that never leaves the machine
Line-level telemetry stranded in systems that were never designed to be read by anything other than the machine that wrote it.

Services most often engaged here

Work delivered in Manufacturing

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.

31%

reduction

fewer unplanned line stoppages

Python
Databricks
MLflow
Azure IoT
Spark
PostgreSQL

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.

Sector: Manufacturing

Read the case study

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.

4×

improvement

faster to evaluate a proposed line change

Python
SimPy
Databricks
Azure
Next.js
PostgreSQL

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.

Sector: Manufacturing

Read the case study

Banking & Fintech

In financial services a model that cannot explain itself is a model that cannot ship. We build scoring, risk and detection systems with the explainability and audit trail treated as delivery requirements rather than documentation written afterwards. We also build the operational software around them, so a decision has somewhere to go.

What we are called in for

1
Pipelines worked in arrival order
Applications and enquiries handled first-in-first-out, with high-intent customers waiting behind ones that will never convert.
2
Decisions that cannot be explained
Scoring that performs well on a benchmark but cannot produce the reason codes a customer or a regulator will ask for.
3
Onboarding friction
Document checks and identity verification handled manually, adding days to a process customers expect to take minutes.

Services most often engaged here

Work delivered in Banking & Fintech

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.

27%

improvement

lift in qualified-lead conversion

Next.js
Python
scikit-learn
MLflow
AWS
Docker

Outcome

The pipeline reordered itself around intent rather than arrival time, and reps stopped spending their first hour deciding who to call.

Sector: Banking & Fintech

Read the case study

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.

68%

reduction

less time per affordability assessment

Python
Transformers
FastAPI
PostgreSQL
AWS
Docker

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.

Sector: Banking & Fintech

Read the case study

FMCG

Fast-moving consumer goods is a forecasting problem wearing several disguises: promotion planning, replenishment, assortment, pricing. The data usually exists; what is missing is a forecast the commercial team trusts enough to act on before the week has already happened. We build both halves: the model, and the software that puts its output where the decision gets made.

What we are called in for

1
Promotions planned on instinct
Campaigns launched without a reliable view of which lines will sell through and which will end the week discounted into a loss.
2
Stockouts found after the fact
Replenishment reacting to yesterday's sales, so the best-selling line is the one that runs out mid-campaign.
3
Channel data that never reconciles
Retail, distributor and direct channels each reporting differently, leaving no single view of what actually sold.

Services most often engaged here

Work delivered in FMCG

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.

32%

reduction

fewer mid-campaign stockouts

Next.js
Python
Databricks
PostgreSQL
AWS
Kubernetes

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.

Sector: FMCG

Read the case study

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.

3×

improvement

more markets modelled in launch planning

Python
PyTorch
Databricks
MLflow
Spark
Azure ML

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.

Sector: FMCG

Read the case study

Working in another sector

The constraints usually rhyme

We have not shipped in every industry, and we will say so. But forecasting, extraction, scoring and workflow automation transfer further than the sector label suggests. Tell us the problem and we will be straight with you about the fit.

Book a consultation hello@post-ql.com

We reply to every enquiry within one business day.

Manufacturing

Banking & Fintech

FMCG

The constraints usually rhyme

We reply to every enquiry within one business day.

Four sectors we arrive already understanding

Healthcare

What we are called in for

Fragmented patient records

Clinical documents nobody can query

Administrative load on clinical staff

Services most often engaged here

Work delivered in Healthcare

Patient-facing healthcare application

Patient management system for a multi-site provider

Manufacturing

What we are called in for

Unplanned downtime

Quality inspection at human speed

Data that never leaves the machine

Services most often engaged here

Work delivered in Manufacturing

Predictive maintenance on production equipment

Digital twin of the production line

Banking & Fintech

What we are called in for

Pipelines worked in arrival order

Decisions that cannot be explained

Onboarding friction

Services most often engaged here

Work delivered in Banking & Fintech

Leads management software with predictive scoring

Bank statement analyser for lenders

FMCG

What we are called in for

Promotions planned on instinct

Stockouts found after the fact

Channel data that never reconciles

Services most often engaged here

Work delivered in FMCG

E-commerce application with demand-aware merchandising

Synthetic data generation for national product performance

The constraints usually rhyme

Four sectors we arrive already understanding

Healthcare

What we are called in for

Fragmented patient records

Clinical documents nobody can query

Administrative load on clinical staff

Services most often engaged here

Work delivered in Healthcare

Patient-facing healthcare application

Patient management system for a multi-site provider

Manufacturing

What we are called in for

Unplanned downtime

Quality inspection at human speed

Data that never leaves the machine

Services most often engaged here

Work delivered in Manufacturing

Predictive maintenance on production equipment

Digital twin of the production line

Banking & Fintech

What we are called in for

Pipelines worked in arrival order

Decisions that cannot be explained

Onboarding friction

Services most often engaged here

Work delivered in Banking & Fintech

Leads management software with predictive scoring

Bank statement analyser for lenders

FMCG

What we are called in for

Promotions planned on instinct

Stockouts found after the fact

Channel data that never reconciles

Services most often engaged here

Work delivered in FMCG

E-commerce application with demand-aware merchandising

Synthetic data generation for national product performance

The constraints usually rhyme