Home / Client outcomes
Client outcomes

Operating results, not product deliveries

A platform deployed is not an outcome. What follows is what actually changed in the running of these businesses — how work got delegated, what it cost, where the human stayed, and what the organisation can now do on its own. Client names are withheld under confidentiality agreement; the substance is not.

0Mega projects delivered across the group — large-scale, multi-workstream, multi-market programmes
0Consultants, architects, designers and engineers across Asia
0Enterprise learning and capability-building heritage
0Countries and territories where our clients operate

What we count as a mega project. Not revenue and not headcount. A mega project is an engagement that changes how a business operates: multiple workstreams, a named executive sponsor, delivery into production, and a measured result the client reports on its own operating review. Fifty-plus of those have completed across the group — across banking, manufacturing, telecoms, healthcare, energy and the public sector.

Where to start, and what to start with

The top-right quadrant is where engagements convert fastest and where we usually start. The bottom-left is where we tell clients to slow down and fix the policy first.

How much does the evidence already exist?↑

Start with content

The obligation is documented but the record does not exist. This is a content and configuration problem — a library course or a short build may be enough.

The usual first engagement

The obligation is documented and the record is partial. Configuration, assessment design and reporting get the programme to a defensible state — the strongest candidate for a first platform deployment.

Fix the operation first

The record exists but nobody runs it. This is an operations problem: administration, assignment rules and renewal cycles before any new content.

Not a platform question

The obligation itself is unclear or contested. This is a policy and process design exercise before it is a technology one.

How much is the obligation written down?→
Selected engagements

What changed in the running of the business

Six representative engagements, described by the operating change rather than the feature list. Figures are described qualitatively here; we walk clients through the underlying methodology in a reference conversation.

Global banking group

Underwriters stopped retrieving and started judging

The bank's credit analysts spent most of each memo assembling policy, bureau data and precedent rather than exercising judgement. We modelled the credit decision as an enterprise ontology, built a digital employee to assemble the memo against it, and left approval with the underwriter — with a complete record of what the agent used and why it flagged what it flagged.

→

Operating result

Preparation time dropped substantially and the turnaround SLA was met consistently. Judgement time per memo rose, because that is what the analysts were being paid for.

→

Governance result

Every decision became reproducible on demand — rule version, precedent, inputs — which the bank previously could not produce at all.

→

Capability left behind

Internal team owns the ontology and extends it to the next credit product without us.

Agentic businessOntology90-day pilot
Southeast Asian manufacturing group

Twelve sites finally shared one model of their own equipment

Each site had its own workarounds and a great deal of knowledge held by a few people. We built a shared ontology of assets, failure modes and work procedures, grounded a diagnostic digital employee in it, and deployed to the technician tablet. The agent was the visible part; the durable asset was the shared model.

→

Operating result

Unplanned downtime and mean time to repair both came down, and the improvement held as it rolled to further sites.

→

Organisational result

Site engineers began working from one equipment model instead of twelve local ones, which changed how they trained each other.

→

Where it went next

The same model became the basis for operator onboarding on new equipment lines.

Ontology & contextAgent designMulti-site rollout
Regional insurance group

Compliance CPD moved from spreadsheet chasing to evidence on demand

Regulatory training was administered by three people chasing spreadsheets across business units, and every audit began with a scramble. We mapped the obligation register to roles and jurisdictions, automated assignment and credit tracking in wizBank, and replaced passive completion with scenario assessment on the higher-risk material.

→

Operating result

Administrative effort fell sharply and an audit pack that previously took days now assembles in minutes.

→

Quality result

Assessment evidence became defensible — a regulator can see demonstrated competence, not attendance.

→

Boundary held

The learning system stayed the system of record. The AI layer reads from it; it does not duplicate it.

Next-generation learningCompliance & CPDwizBank
Telecom operator, APAC

Tier-1 deflection that customer satisfaction improved despite

The operator had attempted a support bot twice and abandoned both because forced deflection damaged satisfaction scores. We grounded the new agent in the service ontology and policy, and designed the handoff as part of the model: any case the agent was not confident about reached a human immediately with full context. The confidence threshold was the design, not a safeguard added later.

→

Operating result

A material share of tier-1 contacts resolved without a handoff, average handling time fell, and satisfaction improved after launch — the reverse of the previous two attempts.

→

Design result

Escalation rate is now a monitored operating metric, reviewed like any other, rather than a complaint category.

→

Workforce result

Tier-1 staff moved to complex and coaching work, with reskilling sequenced ahead of the operating change rather than after it.

Agentic businessService operationsSkills & training
Private hospital provider

Ward-level competence visible on one screen, per person

Clinical governance wanted assurance that staff were competent for the work they were doing, not trained against a checklist. We built a capability taxonomy mapped to ward roles, assessed through scenario and simulation, and published a live competence picture per ward — visible to managers and executives, and in a controlled form to inspectors.

→

Operating result

Clinical incident rate fell, and reliance on agency cover for competency gaps dropped as gaps became visible and addressable.

→

Governance result

Competence assurance became something a manager or an inspector can read directly, rather than reconstruct.

→

Where we stopped

No autonomous agent was deployed into clinical decision-making. Administrative delegation only.

Next-generation learningCompetence assuranceSimulation
Consumer goods group, APAC

One standard, delivered identically, including to partners

The business had five regional training programmes, five quality standards and no reliable view of who was actually ready. We consolidated onto one curriculum architecture delivered in local languages on mobile, and — the part that mattered most — brought outsourced and channel staff into the same capability system as employees, assessed the same way.

→

Operating result

One programme architecture replaced five, time to proficiency shortened across territories, and audit pass rates improved.

→

Ecosystem result

External partners stopped being a quality blind spot, because they were inside the system rather than alongside it.

→

Management shift

Supervisors got live readiness data, so they could intervene early rather than certify late.

Next-generation learningPartner enablementMobile delivery

On confidentiality and numbers. Client names are withheld under confidentiality agreement. We describe results qualitatively on this page deliberately: baselines, measurement windows and market conditions differ so much between engagements that side-by-side percentages would imply a comparability that does not exist. In a client reference conversation we will give you the actual figures, the methodology behind them, and the caveats — including engagements where the result was less than we hoped.

What we commit to, and how you can check

Every one of these is falsifiable. If we cannot evidence it, we have not done it.

Baselines are captured before go-live. Comparisons against a baseline chosen after the result are not comparisons.
What we commit toHow it is measuredWhen you see it
An obligation mapEvery obligation, the population it binds, the evidence an examiner expects, and the gap in eachWeek 2
A configured system of recordEnrolment, assessment, certification and reporting describing the same person, with no manual reconciliationWeek 8
An assessment that proves competenceAssessment sets written against your own historical cases, reviewed by your subject experts, re-run on changeWeek 8
Operators trainedAdministrators and supervisors trained before go-live, with the training recorded in the system as evidenceWeek 8
Evidence accepted by your risk functionThe record and the reporting pack reviewed and signed off by the people who will be asked for themWeek 9
A measured baselineYour metric, captured before go-live rather than after the resultDay 90

The evidence pack your risk and audit functions will receive

Designed in during the build, not assembled afterwards. This pack is the difference between a training programme and a folder of attendance sheets.

  • The obligation map — who must take what, by when, because of which rule
  • The population definition, including partners and contractors outside the HR system
  • Assignment and reminder rules as configured, with the version they were run under
  • Completion and assessment records, per person, per content version, per date
  • Credit and certification validity, with renewal windows and escalation
  • The reporting schedule, and the export that produces each pack
  • The incident and exception log for the period, with the path actually used
  • The handover documentation, in your repository and your formats
Reading the results

The pattern behind all six

Different sectors, different starting points, and the same underlying sequence. This is the sequence we run, and it is why the results hold past the pilot.

01

The model was corrected before anything was built

In every case the expensive part was deciding what work could be delegated and under what authority. Software was the cheap part.

02

Shared semantics made the second use case cheap

Where the ontology was built properly, reuse followed. Where it was skipped, every subsequent use case was paid for twice.

03

The human position was designed, not improvised

Escalation thresholds, review frequency and named ownership were part of the operating model from week one.

04

Capability was built in parallel, not afterwards

People were trained to work with the digital employee as it went live, not once the programme was declared finished.

05

We left, and the client kept it

Internal teams own the semantics, the agents and the governance. Dependency was the failure mode we designed against.

The difference our clients actually buy

Delivered by everyone
  • A platform installed and licensed
  • Usage and satisfaction measured
  • Training as a separate line item
  • Value argued from a vendor benchmark
  • Evidence assembled when someone asks
Delivered by us
  • A record that describes the same person everywhere
  • Your metric, against a baseline captured before go-live
  • Assessment design and operator training inside the build
  • Value argued from your own historical cases
  • An evidence pack your risk function accepts in week nine

How an engagement actually runs

Every client gets the same shape. The content changes by industry; the discipline does not.

01

Diagnose

We find the workflows that are already written down as policy — because those are the only ones that can be delegated safely.

Weeks 1–2
02

Design

We design the operating model: who decides, who supervises, what the agent may not do, and what gets logged.

Weeks 3–4
03

Build

One workflow goes into production. Not a pilot that never ships — a real one, with a trace and a named human approver.

Weeks 5–7
04

Train

The people who will operate it are trained before go-live, and the training is recorded in the LMS as evidence.

Weeks 6–8
05

Measure

Ninety days later we measure against a baseline you did not choose, and scope the next workflow from what we learned.

Day 90

Start with the proposition, not the platform

Every claim on this page is a number we can evidence: 50+ delivered programmes, 300+ consultants and engineers across Asia, US$20M from Morningside and a US$30M Series B from a family office and private equity. If a number here is not useful to your decision, tell us which one and we will show you the underlying detail.

Next step

Ask for the client references

We will introduce you to a client in a comparable sector who will take your call and tell you honestly how the work went — including what was difficult and what they would do differently.