Incident Management and SLA Policy
The purpose of the Quixxi Customer Support process is to restore normal service to customer as quickly as possible and minimize the adverse impact on business operations, ensuring that agreed levels of service quality are maintained.
Support Channels:
Channels | Service Desk | Role |
Emails | Freshdesk | Agent |
Chats | Freshchat | Agent |
Tickets | Quixxi Help Portal | Agent |
Ticket Categories:
S.no. | Categories | Explanations |
1 | Question | Simple questions are general questions that don’t ask anything specific but is a sign of a user reaching out to see if support exists or to test the system. Examples could be when the user just says “hi” or “what is Process Street?" App questions are any questions involving a user’s curiosity about specific features in the platform and how they work. Examples include anytime the user asks a question about how a feature of our platform works, such as "What's a guest?" "What exactly is a widget" or "What can I use the API for?" Sales Questions While relatively straight-forward in nature, Sales Questions are any type of inquiry where the user is asking about pricing details or shows a desire to sign up for a business plan. Marketing/PR Questions When a user expresses interest to collaborate with us in a content sense (writing guest articles), asks about affiliate programs or when a user asks for founder interviews. Billing/Payment Questions Users will encounter billing Incident from time to time. If we need to manually apply a discount, discover why a user’s card did not add or why our stripe webhook isn't loading, then this is a billing Incident. |
2 | Technical Incident | A technical Incident is any Incident that relates to core functionality of our product. Examples could include "Why won't my documents upload?" or "Why won’t my changes appear?" |
3 | Suggestion/Feature Request | Anytime a user proposes a change to our platform that is either in the works, or not thought of yet, this is a feature request. |
Guidelines to Decide Urgency Level:
Urgency Level | Business and Financial Exposure | Description / Work Outage |
1 (High) | The Incident creates a serious business and financial exposure | (i) the external customer experiences a complete or substantial loss of service, or |
(ii) a mission critical business process is not working, or | ||
(iii) where no delay for Resolution is acceptable (impact on customer services or is causing revenue leakage), or | ||
(iv) users are unable to work or perform some significant portion, if not all, of their job, and | ||
the Incident affects over 20% of users and/or customers | ||
|
The Incident creates a fair business and financial exposure. | (i) the customer experiences no loss of service and the Incident has no significant effect on the usability of the Application, or |
(ii) the users are unable to perform some small portion of their job, but they are still able to complete most other tasks, or | ||
(iii) a user has asked a question or requested information, or | ||
(iv) the Incident affects between 5% and 10% of users and/or customers | ||
3 (Low) | The Incident creates minimal business and financial exposure. | All other Incidents not covered within the above (low impact on business and no urgency on fixing the defect). |
4 (NA) | The Incident creates NIL business exposure - General and non-technical queries | All general inquiries that are covered in our existing instructions and FAQs. |
Ticketing Workflow and Status:
Steps | Description | Owner | Status |
1 | Quixxi user e‐mails, chats report an incident to the service desk. | End user | Open |
2 | Gather Quixxi user information and interaction description. Verify that end user and service recipient information is available. If not, add relevant content. | Support Agent | Open |
3 | Determine whether the interaction is a service request. If it is, initiate request fulfillment. | Support Agent | Resolve and Close |
4 | Determine whether the incident is a known error and whether a workaround is available. Verify the instructions helped for a resolution with the end user. | Support Agent | Pending |
5 | Apply and verify a resolution. If the resolution was not successful, determine whether the incident should be reassigned. If not, continue to diagnose the incident. | Support Agent | Assign to developer |
6 | Evaluate the incident by validating the assessment. If the incident should be abandoned, update and close the ticket. | Support Agent | In progress |
7 | Verify the resolution with the end user. | Support Agent | Pending |
8 | If the resolution was successful. | Support Agent | Close |
Service Level Agreement
Service Level targets are defined below and are valid only for Enterprise customers; specific Service Level targets may be defined for individual customers and these will be made available to Support Team separately.
Changing Priority (Impact and Urgency)
- It is understood that over time the impact and/or urgency of an incident may change, which would in turn change its priority
- The practice of downgrading an incident for monitoring an Incident after service has been restored is prohibited by policy. Once service is restored, whether via temporary or permanent solution, the incident must be closed