Home

Business processes, properly engineered

Ithonga Consulting is a business process engineering consultancy. We use real people - assisted with AI agents to establish how your organisation actually works, then design, build and operate the workflows that remove the friction - across the front office and the back office. And we remain accountable for them once they are live.

Requirements gathering

The problem we are usually called in to solve

Very few organisations run purely on their processes. They run on the judgement, memory and improvisation of the people who hold those processes together. That is a considerable asset and a considerable risk at the same time, and it tends to remain invisible until volume rises, a key person leaves, or an auditor asks a question that requires a straight answer.

Introducing AI into that picture without a method rarely helps. A capable assistant placed on top of an unexamined process produces impressive demonstrations and very little operational change. The constraint was never a shortage of intelligence in the system. It was the absence of engineering around it.

Our position is that an AI workflow is a production system and should be treated as one: specified before it is built, tested before it is trusted, handed over in writing, and monitored once it is live.


What we do

We use AI agents as instruments rather than as features. They read the evidence your organisation already holds — case histories, system logs, platform exports, document repositories — at a volume no consulting team could work through by hand, and establish where work stalls, repeats or waits. What you receive is evidence, not an impression.

Engineer the front office

The processes your clients experience directly: enquiry handling, qualification, quotation, onboarding, scheduling, case management and renewals. Consistent handling that does not depend on who happened to pick the work up.

Engineer the back office

The processes your clients never see but always fund: purchase to pay, reconciliation, supplier onboarding, regulatory reporting, document processing, and the movement of data between systems that were never designed to speak to one another.

Read the detail: the three service lines The three service lines and how engagements are structured.


How we Work

Six stages, in sequence, with a defined handover between each.

  • Discovery. Establish which processes are worth re-engineering, and which are not.
  • Design. Specify what each agent does, what remains with people, and where automated authority ends.
  • Build. Engineered rather than prototyped: version control, code review, defined failure behaviour at every step.
  • Test. Dry runs, then shadow mode alongside the existing process, then a staged rollout. No stage is skipped.
  • Deploy. A defined go-live window, a rollback plan, named owners on both sides, and written handover.
  • Service and operate. Monitoring, a service level agreement, monthly review and a published change log.

The method in full - what happens at each stage and what you receive from it.


Why firms appoint us

We remain accountable after go-live. Much of the industry treats launch as the conclusion of the work. A live AI workflow does not stand still: volumes shift, upstream systems change, an interface is revised and something begins failing quietly. We run live workflows under a defined service level agreement, because that is the difference between a capability that compounds and one that degrades.

We build for you to inherit. Clean interfaces, readable structure, and documented reasoning for the decisions we took. If your engineering team wishes to assume ownership, they can. Nothing in the system should depend on us being the only people who understand it.

We will tell you what not to automate. Some processes do not repay the engineering. Some are not yet tractable. Some require a commercial decision before a technical one. We would rather establish that at Discovery than invoice you to discover it at Build.

We are explicit about authority and accountability. Where automated authority stops is a design decision, taken with you, recorded in writing and enforced in the build. Our governance position is published rather than provided on request.


Where we work best

We are a strong fit for organisations with genuine operational volume, an appetite to change how work is done rather than to demonstrate that it could be, and a sponsor senior enough to make decisions about process ownership. We are a poor fit for a proof of concept intended primarily to reassure a board.

If you are unsure which of those describes your situation, that is a reasonable thing to establish in a first conversation, and it costs you an hour.


Begin with a conversation, not a proposal

A Discovery conversation is low-commitment on your side and gives both parties enough signal to judge whether the fit is right. If it is not, we will say so.