Using Comma5 CRM Service Desk

The primary objective of the Service Desk (but not its only objective) is to serve as a single point of contact between users (customers) and Services Management.

Comma5 CRM Service desk focuses on ensuring Call Resolution within SLA and Customer Satisfaction. Our service desk not only provides the tools to achieve this but also allows you to monitor both of these metrics live using SLA achievement and Customer Satisfaction metrics.

Apart from the ability to improve service delivery through the tracking and management of service requests, it allows for easy analysis of service desk data to guide management in making informed decisions based on live statistical information

Key Features

Easy to use

One of the biggest challenges with introducing any software application into an organisation is user uptake or adoption. This is mostly due to the complexity of systems. For this reason, we’ve designed an intuitive, easy-to-use interface.


Every organisation’s requirements are unique. Comma5 CRM Service Desk is highly configurable and customisable, allowing administrators to configure statuses, custom fields, templates, reports notifications and more. Through its flexible filters we are able to present data in whichever view our customers wish to see it.

Email and SMS for notifications

With built-in email and SMS integration, notifications and information can be broadcast to any and all members of the organisation using whichever medium is preferred. For example, when a request is assigned to a technician, the system may be configured to send an SMS notification to the assigned technician alerting him of the assigned request, the reference number, who, and what it is for.

Automated SLA management & escalations

Service Level Agreements (SLA) form the backbone of Comma5 CRM. Once service level priorities are set, the system tracks each request adherence to the SLA timeframe. It is possible to configure multiple SLA priorities (timeframes). When an SLA is breached, there is an automated escalation process, with notifications via email or SMS.

Powerful reporting and analytics

Whilst the service desk comes pre-configured with standard reports, it is possible to create any conceivable report using the powerful filters and report writer. Reports may be viewed in the system or configured to send to specific groups of people at specific intervals (daily, weekly, monthly). The content of the reports is totally customisable too, allowing different reports to be sent to different groups of people.

Customer Service Reviews / Surveys

Customer Service Reviews / Surveys can be sent via Comma5 following the closing of an incident. This provides for a powerful mechanism for assessing the perceptions of the organisation or customer with respect to service delivery. Again, this can be reported on and measured.

Typical Service Management needs we satisfy

Call logging via a Web Portal

Comma5 CRM includes a web portal interface that allows users to log calls through any web-based platform including intranet, SharePoint, website, etc. The interface makes use of “iframe” which allows the configured capture screen to be placed into any HTML environment.

Call allocation – Categories 

Users are able to select categories and subcategories to assist with the classification of calls. Multiple categories and subcategories are selectable. It is possible to hide or show any of the fields from the service desk platform in the web form (for e.g. Asset number or serial number)

Call allocation – resources/business units

Calls logged through the web portal remain with an “Unassigned” owner which allows the operator to assign calls as required. Internal Business units/skills are associated with call categories, for example, if a call is logged for a Fault 1, the list of available technicians with the “fault1” skill will only show. When assigning, it is possible to view currently open calls for the technician which enables the operator to balance work-load between technicians.

Call monitoring 

Calls can be viewed in a number of ways through customisable dashboard view. Open calls are also monitored using the SLA metric.

Customer and Owner notifications

Notifications are sent to Customers and owners when their calls are logged, updated, put on hold and closed. Notifications on Service Request updates can also be enabled if it is not necessary for the Customer or Owner to receive the changes. All correspondence is stored against the service request in the history.

Service Level Agreement Monitoring

SLA timeframes are customisable to accommodate resolution times.

SLA breach notifications

All Service Requests are flagged with a red mark when the SLA is breached

Report Generation

Daily, weekly, monthly automated reports can be created for various groups. Reports can show just about any information in tabular or graphical format in the reports.

Detailed process

Capturing of the Service Request

Service requests can be captured through the web interface (user portal) or via the service desk. All fields on the capture form are customisable and for the purposes of this proposal we are presenting the most commonly used configurations. The key fields used include:

    1. Company/Organisation/Department – Once selected, relevant users in that department will be displayed. This field may be excluded if requests exist for a single department or organisation. Tags are created for each department (if required) which show relevant information for that department at the time of capturing the request.
    2. Contact – this is the name of the end user/customer/person requesting the service. It is possible to add contacts on the fly, as well as providing the ability to view detailed information relating to the end user, like location, telephone number etc.
    3. Category and sub-category – these are pre-defined and allow both categorisation and reporting on specific fault categories. Categories are linked to technical resources, so when the operator selects a specific category (e.g. Network), then assignable technicians from the networking department are displayed. Categories and sub-categories are totally customisable through the system settings.
    4. Subject and description – fields which allow for the capturing of additional information. It is possible to utilise both fields or either one. In addition to these fields, there are a number of additional fields which can be activated.
    5. Status – statuses are configured to meet with the organisation workflow process. A typical status configuration would include: New, Assigned, In-Progress, On-hold, Escalated, Complete & Closed.
    6. Owner – is the assignee of the request. Owners are linked to request category, therefore allowing skills-based assignment of requests
    7. Severity – This is the time-frame set in accordance with the SLA objectives. A typical configuration would include at least two severities (e.g. Normal and Urgent) each with different SLA time-frames assigned to them.
    8. Other – the request capture form also shows recently captured requests for that user, it also allows for all file types to be attached to the service request.

Upon completion of the information capture, the operator clicks save and at this point a reference number is generated:

And a customisable notification is sent to the end user with email (or SMS) which will include your defined fields, layout and logo.

Assigning the Service Request

Assignment of the service request can happen at the time of capturing or post capturing of the request. If the request is captured and “unassigned” the request will remain in the unassigned list of requests, assigned to the operator who captured the request (unless otherwise configured) As previously mentioned, assignees of a request are linked to the category selected to allow for skills-based routing of a request. Upon selecting the owner for assignment, the system indicates the number of currently open requests for each of the technicians allowing the operator to assign the request based on work-load of the technicians.

Once assigned, the service desk sends out a notification to the technician/engineer which is customisable to include information relevant to your team (for example building and office number of user etc.)

Managing Service Requests

Easy management of service requests is made possible through a multitude of views and filter, allowing the request to be categorised as preferred by the operator or technician.

The interface allows for the operator or technician to update the service requests without opening the record, by using the quick update functionality. Escalations are automated on breach of the required SLA timeframe.

Requests put on hold force a notification to be sent to the end user, and stop the SLA clock from ticking.

A full history (audit trail) is kept for each service request in the system from time of capture to closing (and beyond for repeat calls).

Closing the Service Request

Closing a service requests is a quick and easy process.  It is mandatory to capture closing comments to provide a comment to the end user, but also contributes the solution of the request to the knowledge base. The closing includes date and time-stamping as well as capturing who closed the request.

Following the successful closure of a service request, a notification is sent out to the user informing them of the resolved request. The closure notification also provides a link to a survey in which the user can provide feedback.

Customer Satisfaction Survey

Clicking on the survey button allows the user to quickly rate the level of service they have received, and provide a comment. This feedback allows the service desk to ascertain customer perception within the organisation, and will guide management in corrective measures to continually improve service levels.

Reporting and Analytics

It is possible to create and report on any data captured in a number of formats. All reports (and filters) in the system are easily exported to excel. Filters (which are added to reports and dash-board views) are easily created using the intuitive filter creation component.

Technical Specifications and Architecture

Comma5 CRM has been developed using Java and is based on a MySQL Database. It uses JSON for data interchange and has built-in integration for email and bulk SMS service providers. The architecture is flexible, catering for cloud-type architectures with distributed data or separate application and database servers. The platform is constantly evolving to keep abreast with the latest web-based technologies.