Making customer operations scale with the technology.

The product was scaling. The operating model was not.

When a technology company grows quickly, manual work can hide inside what looks like a successful rollout.

Deligo’s AI-powered self-checkout solution was expanding across European customer locations. The business was moving from roughly 200 to more than 450 locations and 900 devices during that growth period. Yet each deployment still needed detailed site preparation, manual product and recognition configuration, installation coordination and close monitoring after launch.

Support had a similar problem. Requests arrived through several channels, specialists were solving issues from experience, and escalation or ownership was not always explicit. As volumes grew, it became harder to tell which issue mattered most, where work was stuck and how much capacity future customers would require.

One major channel partner was becoming frustrated with how much preparation its teams had to do for each launch. That wasn't just an operations inconvenience. It threatened the pace of further commercial expansion.

A repeatable path from signed deal to live site

First, I mapped what happened before, during and after a deployment — including the unofficial steps that only experienced team members knew how to handle.

We introduced a structured sales-to-operations handover with minimum readiness requirements, a site-assessment process and clearer responsibilities for integrations, hardware, AI setup and customer training. A project had to be ready before it became an operations commitment.

For physical deployments, I developed a playbook that an external field-service partner could follow: what information to collect, what to check at the site, how to test the kiosk and payment flow, when to escalate, and what evidence to provide at handover. The goal was to make good execution less dependent on sending our most experienced person to every new site.

We also began measuring hypercare effort and issue categories so we could tell the product and ML teams precisely where manual effort accumulated, rather than asking vaguely for “better tooling”.

Build a support operation, not a collection of heroic fixes

The deployment process was only half the challenge. Customers also needed a reliable way to get help after launch, across different countries, systems and time zones.

I built out the customer support team and introduced a more structured service operation, including Jira Service Management as the shared ticketing system. We defined how incoming issues were captured, classified, prioritised, assigned and escalated — instead of leaving the history in individual chats or colleagues’ heads.

The playbook covered recurring technical and operational cases, responsibilities by support level, the path to product or engineering, shift handovers, customer communication, and what had to be documented before a ticket was closed. We also built the basis for a knowledge base and support reporting, so repeated issues could become documented solutions rather than repeated investigations.

This was a team and operating-model change as much as a software implementation. A new ticketing system alone doesn't create service quality. People need clear decision rights, a common vocabulary for priorities, and the confidence to escalate rather than hide an unresolved issue.

Use operational evidence to influence the roadmap

I didn't own the product roadmap, but I did own the consequences of the product’s manual workarounds. The more accurately we recorded effort and recurring issues, the stronger our case became for fixing the root causes.

On pilot sites we tracked time spent in hypercare, the types of problems we encountered and how quickly a location reached the required recognition quality. We then converted those patterns into a concrete proposal for a more automated setup flow, with specific requirements for product and machine-learning teams.

That was the longer-term track: standardise first so teams could keep shipping, then show exactly which repeated steps were worth automating rather than indefinitely adding operations headcount.

More predictability and more capacity

Our internal project review recorded sites reaching their target recognition performance about seven days sooner under the improved deployment and hypercare model. Average hypercare time per site was reduced from roughly two weeks to one, and the number of simultaneously supported sites per Customer Success Specialist increased from around two to four.

The larger operational change was a better separation between initial launch work, customer support and product fixes — with defined responsibility at each point.

The deployment framework was used for subsequent rollouts, while the support team had a service-management system, priorities and documentation that made growing volumes more manageable.