Two very different industries — healthcare and fintech — are solving the same underlying problem: systems that waste capacity because they can't predict what's coming next.
We keep seeing the same pattern across industries that look nothing alike on the surface.
A hospital network loses £18 million per year to appointment no-shows. A payment platform ships twice a week because its test suite takes 4.5 hours. Different sectors, different metrics — but the same root cause: systems running on static rules when they should be running on predictions.
The prediction gap
Most operational systems were designed for averages. The scheduling system assumes a flat no-show rate and applies blanket overbooking. The CI pipeline assumes every test might fail and runs all 14,000 of them on every change.
Both approaches made sense when the alternative was guessing. But with 3-5 years of historical data sitting in EHRs and CI servers, the alternative is now a trained model that scores probability at the individual level — per patient, per test, per change.
What changes when you add prediction
In healthcare: AI scheduling models score each appointment for no-show risk 72 hours out. High-risk slots get proactive outreach. Medium-risk slots get automated reminders. Low-risk slots are left alone. The system dynamically overbbooks only where the data supports it.
Result: 25-40% fewer missed appointments. Recovered clinical capacity. Shorter waiting lists.
In fintech: ML-based test impact analysis scores each test for relevance to the current code change. Tests with no dependency on changed modules and low historical failure probability are skipped. Safety nets (nightly full runs, escaped-defect monitoring) catch the rare miss.
Result: 60-80% faster builds. Release cadence jumps from twice weekly to multiple times daily. Engineers stop waiting.
The implementation pattern is the same
Both solutions follow identical steps:
- Extract structured historical data (appointments or CI builds)
- Engineer features that capture context (patient behaviour patterns or code-change graphs)
- Train a classifier on labelled outcomes (no-show or test-failure)
- Score in real time and trigger tiered responses
- Close the feedback loop with outcome data flowing back nightly
The models are simple — gradient-boosted trees or logistic regression. The hard part isn't the ML. It's the integration: connecting the scoring pipeline to the scheduling system or CI runner without disrupting existing workflows.
Why most teams stall
We see three common failure modes:
- Over-engineering the model when the bottleneck is actually data quality or system integration
- Skipping the safety net — the nightly full run, the equity monitor, the escaped-defect alert — which erodes trust when the model inevitably makes a mistake
- Treating it as a data-science project instead of a product engineering one, resulting in a notebook that never reaches production
The teams that succeed treat prediction as a feature of their operational system, not a separate analytics workstream.
What we're building
Our engineering teams are currently delivering both patterns — patient scheduling optimisation for a healthcare network and test impact analysis for a payment platform. Same architectural playbook. Same integration-first approach. Different domains.
If your organisation is sitting on years of operational data and still running on static rules, the question isn't whether prediction would help. It's which process to target first.
We'd suggest picking the one where each unit of recovered capacity has a clear pound or dollar value attached. That makes the business case self-evident and the ROI measurable within a quarter.