From daily chaos to smooth service

The service team supported around 200–300 corporate customers and handled roughly 250 service requests in quieter months and up to around 600 when things were busy.

The problem wasn’t simply the number of requests.

It was the way they arrived.

A customer might phone, send an email or send a request through a messenger, speak to an account manager or contact an engineer directly. Somewhere along the way, somebody still had to collect all of that information, work out what the customer actually needed and get the job into the right hands.

A lot of the process depended on people knowing what was happening.

And every morning there was another puzzle to solve: who should go where?

It sounds simple until you look at the decisions behind it.

What kind of equipment is involved?

Which engineer knows it?

Who is available?

Where are they already working?

Where is the customer?

How urgent is the job?

What has been promised under the service agreement?

A coordinator was making those decisions manually every day.

Putting the schedule together could take 1–2 hours before the engineers had even started moving.

As the customer base and service workload grew, adding more coordination around the problem was never going to be a particularly good answer.

The service didn’t need more people moving information around.

It needed a clearer way for a request to move through the business.

• We started by following a service request from beginning to end. Not just the neat version on paper, but what actually happened when a customer needed help: how the request arrived, who picked it up, what information was missing, who made the next decision, how an engineer was chosen and what happened once the work was complete. That showed us where people were repeatedly filling the gaps themselves.

• The first change was to give existing customers one clear route into the service process. Telegram made sense because customers were already comfortable using it. There was no reason to build a new portal and then ask everyone to remember another login just because it looked more “professional”.

• A customer could send a service request through Telegram and the system could connect their Telegram account or phone number with the relevant company record in CRM/1C.

• From there, we looked at the decisions the coordinator had been making manually every morning. Things such as:

what kind of service request it was;

what equipment was involved;

which engineers had the right skills;

where the customer was;

who was available;

what other jobs were already assigned;

and what service commitments applied.

• The repeatable parts of those decisions became routing rules. Instead of starting each morning with a blank page and rebuilding the day from calls, messages and notes, the system could do much of the first pass.

• The coordinator still had control. Their job changed from manually constructing every allocation to checking the proposed plan, handling exceptions and making the decisions that genuinely needed judgement.

• We also connected the rest of the service journey rather than stopping at “engineer assigned”. Engineers could report what had been done, the job status could move with the work, and information about materials or additional work could continue through the process.

• But we deliberately didn’t automate every possible outcome. If an engineer discovered something outside the original request — additional work, parts or another issue that needed approval — the process stopped for review rather than automatically pushing it through to billing.

• Automation handled the predictable parts.
• People stayed involved where a decision still mattered.

The biggest difference was not that customers suddenly had a Telegram bot. It was that the service request stopped being something people had to keep rebuilding as it moved through the company.

Customers had one clear way to ask for help. The request could be connected with the right customer record from the beginning instead of somebody having to work out who had sent what.

Engineer allocation changed from a daily manual planning exercise into a much shorter review. What had taken around 1–2 hours could usually be dealt with in approximately 10 minutes.

The service operation was also able to move from two coordinators to one while continuing to handle a substantial volume of requests.

Engineers received clearer jobs. Coordinators spent less time moving information between people. Request status became easier to follow. And, most importantly, growth no longer automatically meant adding more administration around the service.

As the wider service operation developed, annual service revenue grew by approximately 200–250%.

The automation wasn’t the only reason for that growth, and it would be misleading to pretend it was. What it did do was remove one of the operational limits that would have made that growth much harder to handle.

The useful part of this project wasn’t really the Telegram bot. It was everything we stopped people having to do around a service request.

Customers didn’t need to learn a complicated new system.

Engineers didn’t need another layer of admin.

And coordinators no longer had to spend the first part of every day rebuilding the schedule from a collection of calls, messages and individual knowledge.

We automated the parts that were repetitive and predictable. And we deliberately stopped where judgement was still useful.

That distinction matters.

A good automation project isn’t about removing as many people from a process as possible. It’s about removing the work that was getting in their way.