Support

When something affects your customers' conversations, you need to reach people who know your deployment and can act.

Telonic support works in Arabic and English. Critical incidents are covered 24/7, and other requests are handled during UAE business hours. Every request is given a severity, and the response targets for each severity are set out in your agreement. This page explains how the severities work, how to raise a request, and what happens when an issue needs to go higher.

Severity levels

Severity reflects the effect on your customers and your business, not how difficult the fix is. You set the severity when you raise a request, and we agree it with you if the picture changes.

Response targets for each severity are set out in your agreement, together with how response is measured. See Service levels.

How to raise a request

Your agreement names the support channels for your organisation. Typically these are a support portal for all requests, an email address, and a phone line for critical incidents, so that a critical issue reaches a person at any hour rather than waiting in a queue.

When you raise a request, include:

• What is happening, and what you expected to happen.
• The channel, department and queue affected.
• One or more conversation references from the console, where the issue concerns specific conversations.
• When it started, and how many customers seem to be affected.

Each request receives a reference, and updates come to the person who raised it and to your named contacts.

When we find the problem first

Your deployment is monitored continuously, with alerts to our engineers, so we can often see a problem before your team does. When that happens, we raise it with your named contacts at the right severity and keep them updated until it is resolved.

In your own cloud account or on your own premises, monitoring uses operational health signals that contain no customer data, and you can switch these off. If you do, your team's reports become the main way we learn of an issue.

Escalation

If a request is not progressing as it should, or its severity needs to change, you can escalate it. The escalation path is set out in your agreement, and follows the same shape for every customer:

1. Your support contact, who owns the request day to day.
2. The support lead, who can bring in engineering and reassign priority.
3. A named senior contact at Telonic, for issues that need a decision at a senior level.

For critical incidents, escalation happens automatically: a critical incident is brought to the attention of senior engineering from the start, and you receive regular updates until it is resolved.

Named contacts on both sides

Your agreement records named contacts on both sides. On your side, name the people who can raise critical incidents, the people who should receive updates, and your contacts for security incidents and personal data breaches, including how to reach them out of hours. On our side, you have a named contact who knows your deployment. Keeping both lists current means the right people hear about an issue first.

Security incidents and personal data breaches

A suspected personal data breach is always treated as critical. Other security incidents are given a severity as described in Incident response. All follow our incident response process: personal data breaches are notified to your named contacts without undue delay, and within 24 hours of becoming aware of a breach affecting your data, with ongoing updates. See Incident response.

Changes go through the change process

Changing what the agent does, such as a new escalation rule, a new template or a change to a limit, goes through the controls your team holds and the change process, where it is tested before it goes live. A support request is the right way to ask for help with a change, and the change itself follows that process. See The controls your team holds.

In practice

A property developer's WhatsApp channel stops receiving replies late on a Friday evening.

1. The duty supervisor, Sara, sees in the console that no WhatsApp conversations have started for twenty minutes, during what is usually a busy hour.
2. She calls the critical incident line and raises the issue in English, giving the channel, the time it started and two conversation references.
3. Telonic's on-call engineer confirms the issue, which lies with the connection to the messaging platform, and sends updates to the developer's named contacts.
4. Voice continues as normal. When WhatsApp service returns, Sara's team uses the console to find customers who tried to reach them during the outage, and follows up.
5. On Monday, the developer receives a written summary of what happened, the cause and the steps taken.

Related

• Service levelsCommercial
• Incident responseSecurity and data protection
• ImplementationCommercial
• The consoleQuality and analytics
• Operations questionsFAQ

Product names and logos are trademarks of their owners. Their mention shows systems Telonic connects to and does not imply partnership or endorsement.