To create our cloud solutions, we develop our own trade applications. This software expertise increases our independence and provides our employees with the most efficient tools. Recently, a team was given complete freedom to enhance the Infomaniak support tools. We will tell you all about this project through the eyes of our developers.

We appreciate our support team at least as much as you do

Our support operatives are the link between everything we do and our users. They are the ones who hand on your suggestions, communicate your problems and ensure that our products evolve in line with your priorities. Without their support, Infomaniak would not be Infomaniak.

Listen. Identify. Prioritise. Code Adjust.

To improve our tools, our developers worked in a small group with their colleagues from the support service without any intermediaries. It all began with a meeting between the support team, the developers and the system engineers. The team identified numerous points for improvement in order to optimise:

  • customer satisfaction
  • the internal management of the service
  • the efficiency of the processes
  • the working comfort and satisfaction of the operatives

It was essential to find a balance between what was feasible and the ideal vision determined together. Each function development was presented to the end users to get their impressions and feedback in order to make the final adjustments.

Providing a response to the specific problems of the support service

We asked the developers to tell us about the new functions they created for the support service:

1 – Fluidity of the queues

To reduce waiting times if certain queues are unavailable, a “fallback” system redirects the customer calls to the first operator available in their language. The schedules of each queue are managed individually for each day of the week according to the specialists or languages available. To inform the customers as early as possible, our operatives can generate dynamic audio messages to be played according to the conditions: queue, technical problem per product, language.

2 – Analysis and improvement of the productivity

We have implemented statistics and new indicators (KPIs) to produce an overview of the state of the support service for specific periods. The support operatives can:

  • identify problems more quickly
  • understand customer expectations as accurately as possible
  • help each other in very busy periods to answer customers more quickly

3 – Dynamic management of the support centre

Managers can add/remove operatives to/from queues, designate and change their role, view their status and define an internal number (no possible in the past). They can also define the on-hold music, change the different alert thresholds and define waiting times:

  • before passing on to another operator
  • between each call
  • Before triggering the “rush time” and “fallback”

Calls can now be redirected automatically to mobile phones to handle requests, even if an operative is not present on-site (on-duty periods).

At the heart of development

When we talk about support, each and every detail contributes to the customers’ end experience. We have therefore done everything possible in-house in according with our technological constraints and our future objectives.

This project is an excellent example of the daily reality of our developers. It confronts and challenges technological choices with regard to the tangible improvements we want to offer users while providing a high level of freedom in the different stages of realisation. Julien Viard, VP of Engineering at Infomaniak

The frontend

The administration interface and live support interfaces (real time control screens of the support centre) were developed using the AngularJS framework. This is the historical technology of the application, which the developers adhered to.

Several components were tailor made in order to facilitate use, such as:

  • user selection to assign them to queues
  • switching customer account in the interface
  • automatic scrolling on the live support interfaces

For the live support, a choice had to be made: either to implement sockets (IPS) or to use pooling by applying a backend call every 3/4 seconds. The latter solution was adopted for reasons of eco-design and ease of implementation. Instead of maintaining a constantly open channel between the frontend and the backend to update data, we manage the calculations on the server side. The frontend interface obtains the information from the available cache in 3-second intervals (instead of 1 second) to limit the number of server calls and redundant calculations. To provide a fluid visual which is comfortable for the support operatives, we simulate a refresh in real time with visual increments every second.

The statistics (KPI) required several graphics and tables to be implemented which can be displayed on different time scales. For a day, the statistics are displayed per hour, while for a month, they are displayed per day.

The backend

The historic technology of the support centre is Asterisk (SIP protocol) and AngularJS for the pre-existing tools. It was necessary to connect to the Asterisk database to recover certain information on the fly, handle the support operatives and create all the accompanying functions. Within the framework of these tools, we only use the API (REST) routes accessed via the interface.

Generally speaking, this project ensured considerable scope for creativity. With Asterisk and a real time DB, it was possible to do more or less whatever we wanted. One interesting function is that an operative can click on a queue to which they are not initially assigned (for example another department or language) to take a single call in this queue. The operative simply needs to be added to the queue dynamically then removed again by intercepting the next call received (using the events management system).

We have implemented an events management system: the telephone server places API calls with certain settings and performs the associated actions on the backend side. This type of event makes is possible to display the associated customer account (according to the caller number) in the interface when the call is taken. This system recovers the data stored in the request then dispatches jobs so that the API response is very quick and does not delay the call itself being taken.

For dynamic message management, the text is transcribed into vocal format then deployed directly to a Git repository: the service centre is grafted onto the latter and can access the messages in real time. It is a function which was very pleasant to develop, as it is possible to create a small voice message repository quickly and to access it via a dedicated interface in order to list to / edit them.

Some API routes are consumed directly via the scripts of our system administrators. The settings differ a little from those used by our interface, as the functions are not 100% identical. In one command line, the status of a redirection can be viewed and modified simply by indicating the internal and external number to be used. This makes it possible to manage redirections linked to on-call service automatically.

Internal development: a challenge and a lever

It’s rare to have so much freedom in a project. Being as close as possible to the end users has made it possible to create a productivity emulsion to perform quickly, well and pertinently. Florian Grenier, Frontend developer

The aim and key benefit of this project are its lightweight nature, which ensures maximum autonomy and efficiency. The end users are our own colleagues, which makes it possible to reset the cursors. The deliberately minimalist team worked in a closed circle for two months. We adopted a continuous integration (CI) process with a staging 1 server for 1 production server and automated deployment on a test server is driven by an internal script.

Create high-performance new elements with an old framework

While an API integrated into the Asterisk server exists, we chose not to use it. It did not meet our needs and we could not change its behaviour. We therefore developed our own APIs.

The technical aim of this project was to juggle between the functions available, the existing elements and the specific developments while proposing relatively short production launch deadlines and a high level of quality.

Necessary adjustments

It was difficult to run tests in real production conditions: far more calls at the same time / calls which last longer / longer waiting times. All this placed the development team in conditions that had never previously encountered and required small corrective measures, for example with regard to real time displays.

One of the main problems did not arise immediately. The large number of logs generated by the centre only became apparent after several weeks. This tended to slow down the generation of statistics and the different actions. An automatic flush system was introduced, accompanied by a cache system, in order to avoid recalculating data that does not need to be refreshed with the same frequency.

The project developers

Florian Grenier, Frontend Developer: I joined Infomaniak two years ago as a frontend developer. I have wide-ranging experience: PHP then C# developer, a short period on the Ionic mobile app, junior project leader then Java developer. In 2016, I graduated with a 5-year diploma from the French Y-NOV school where I completed numerous development projects and competitions, including outside the school. With regard to resources, I often visit this site to get some really good ideas. I also enjoy following Grafikart tutorials on YouTube.

It can be a little frustrating to have to deal with older technologies (technical debt). The reality of a developer is to deal with what already exists, which isn’t necessarily particularly attractive, to deliver a final high-quality solution which has a real impact on the speed of the company.

Noé Fleury, Backend Developer: I have been a backend developer at Infomaniak for about one year now. I initially taught myself several languages (PHP, C, Python, SQL, etc.) and validated the knowledge I acquired with a Bachelor’s degree in IT from an engineering school (HES) two years ago.

This project proves that we can develop highly efficient tools without needing less versatile external solutions. As the interface is intended for internal use only, it has been possible to add small, unplanned functions which are actually very useful on a day-to-day basis.