When a customer signs, somebody has to turn that signature into a working account. At Kitomba that job had grown up over years inside a small onboarding team, and most of what made it work sat in the heads of the people doing it. It had become extremely manual, lots of copying and pasting between systems, and lots of "I'm not even sure why we do that, it's just how I've always done it." That's an ordinary shape for a software company to end up in, and it holds together right up until the moment somebody leaves.

Background

Kitomba builds business management software for salon, spa and clinic owners. It's a Wellington-based B2B software company, part of the Jonas group, with customers across New Zealand and Australia.

Customer onboarding is the seam between a closed deal and a customer actually running on the product. It's admin-heavy, detail-heavy work - contracts, account setup, data migration, billing, education - and none of it is optional. Get it wrong and the customer's first experience of the company is a mess.

I came in on a four-month retained engagement to redesign that function with AI. The starting brief from Kitomba's General Manager was clear about one thing from the beginning: whatever we built had to remain human first. This was never a headcount exercise. The goal was to take the grind out of the role and give the team back the parts of the job that actually need a person.

The challenge

Three things were pulling in the same direction.

The first was concentration. A large amount of the process existed as institutional knowledge rather than as anything written down, and a key person was on their way out. That's a knowledge problem before it's an AI problem.

The second was fragmentation. Onboarding was spread across more than one system, which meant nobody had a single view of where a customer actually was, and the process had accumulated steps that existed because they'd always existed.

The third was ramp-up time. Historically, a new onboarding coordinator took around six months to get to the point of running contract processing end to end. In a team that small, six months is a very long time to carry.

The approach

We started by moving the spine of the process into HubSpot, so a customer's journey from closed deal through to live account lives in one place rather than being reconstructed from several.

Then we built what the team calls the onboarding coordinator - an AI system running on Claude that walks a person through contract processing step by step. It reads the deal, prepares the work, tells the coordinator what's needed next, and writes back what's been done.

The written process is kept in plain English, not buried in code. When the system hits a situation the process doesn't cover, it stops and asks rather than guessing - and because the process is plain text, the person who hits the gap can fix it themselves. The whole process is documented end to end in Kitomba's own Confluence instance, and Claude wrote that documentation from the same project the coordinator runs in - so the written process and the working system came from one source, rather than the documentation being reconstructed after the fact by somebody who wasn't there. That is the handover: the documentation stopped being something I maintain and became something Kitomba owns.

Verification is the job, not a safety net. AI is confidently wrong often enough that the coordinator's standing discipline is to check the output, particularly on handwritten paperwork. We designed the role around that deliberately - the human is there for judgement and checking, not for typing.

Where the process touches genuinely sensitive customer information, we designed the model out of the picture entirely rather than instructing it to look away. We use a deterministic workflow to retrieve a temporary URL which holds the customer's direct debit info form, hydrate the bytes, and push the attachment to the finance platform. Claude never sees it, and never needs to.

We also had to solve version control for people who are not developers, because a system several people improve needs a way to stop them overwriting each other. That ended up as two habits to learn - running the /start-work skill when you start, and /save-progress when you're done, just like saving a document. Those skills wrap the version control git commands, and the end user never needs to see or understand it. It's all traceable and reversible, if something goes wrong.

The outcome

The clearest result came from something we didn't plan. A brand-new onboarding coordinator joined partway through the engagement and was processing customer contracts end to end within her first two days, against that historical ramp of roughly six months. That comparison isn't mine - it came from inside Kitomba.

The second result matters more to me. The team leader who owns the migration side of onboarding has taken the system over and is now building on it himself, fixing things I never touched and shaping it to the way he works. I'm already outside that loop, and that was the design.

The engagement was scoped from the outset to end. When it has ended, one measure of its success is that Kitomba doesn't need me afterwards.

Reflection

The fear about this kind of work that gets the headlines, is that it's a way of removing the requirement for some of your people. That isn't what happened here, and those aren't the kinds of engagements I take.

What actually changed is that a role which used to take half a year to learn now takes a day to start, and the parts of it that were pure grind are carried by the system. The people are still there. They're doing the parts that need a person - engage more and earlier with the new customer - checking, deciding, and improving the tool itself.

The work only counts if it survives my leaving. A system the client can read, change and extend without the consultant is worth more than a cleverer one they'd have to keep paying me to touch.