Designing an IT helpdesk platform
In this article, I would like to share some software design practices we use to improve user experience and simplify technical development.
At Linagora, we processed hundreds of support requests every month with over 400+ different software on 24/7 from our customers as part of our Open Source Software Assurance offer (OSSA). We have been using various internal and open source solutions for each of our customers such as GLPI, OTRS or Redmine. However it has been quite a challenge for our support engineers to work across those tools.
Investing in a helpdesk solution is important to deliver high quality and efficient customer services. This is why we decided to build our own unique customer portal to provide professional support on open source software from the ground up.
Managing support workflow and SLA times
Our customers range from public administrations to companies with differents business needs and contracting clauses. It was important to redefine a common support framework in our new platform where all existing customers would fit in.
At the heart of our IT support model, are Service-Level Agreement (SLA) time commitments. This means we commit ourselves to answer to our customers and provide a workaround or a correction after a certain time the issue has been submitted.
This means our helpdesk platform needs to feature contextualized time-based metrics. For example, a critical problem on Linux server infrastructure will have a different SLA than a simple administrative request.
Based on the above, we have chosen to conceptualize the request as a triple-component model : a demand type for the business context, a software type for the technical context and a priority type for the issue context. Those components would be selected from a global dictionary to ensure both internal consistency and customer contextualization.
Each request has its own set of SLA time : response, workaround and correction. For easier configuration, only the demand type will be required. The empty fields will be interpreted with a default behaviour. When an issue is submitted, software selection will be optional and issue priority box hidden. SLA time will be considered as infinite and not be recorded.
At the same time, the time counter may be interrupted be various events such as when a support engineer is waiting for an essential information or a bug fix from the customer.
For managing the SLA time during the lifecycle, we decided to implement a double counting mechanism. Depending on the issue status, the time will be paused or resumed accordingly. However, only when the support engineer has ticked the separated checkbox for workaround or solving, that time would be recorded formally for the issue. This allows to make information clearer for the users and prevent manipulation errors.
Providing access and permissions to users
Working with different internal or external parties, means dealing with different levels of access. We have identified 5 different actors.
In order to make user administration easier, we choose to follow an Attributed-based Access Control with only three user roles : support administrator, support engineer and customer beneficiary. Customer and support managers are filled directly as an attribute on each Contract.
We have also implemented Inherited properties for Contract and Issues, meaning a Support Manager of a contract has the right on all child Issues by default.
Finally, Users can only access a Contract if they belong to an Entity which has access to that Contract. This allows to provide custom rights within an Organization, which is a requirement for some of our largest customers.
