Requesting support from Panintelligence Service Desk

Before You Do…

We have a few helpful hints and tips to ensure you are providing us with the levels of information we need to help you in the most efficient and effective manner, these being:

  • What version of the dashboard is the issue occurring on?

  • When did the issue start occurring - has it worked previously?

  • What actions were being undertaken at the time the issue occurred?

  • What steps are required to recreate the issue?

  • When was the dashboard last upgraded?

  • Has there been any recent changes to the dashboard configuration/ architecture?

  • How many users are being impacted by this?

  • What do the log files show - are there any errors? - Provide screenshots/gif’s/videos of the issue

  • Where is the dashboard installed – i.e. Cloud instances?

  • What environment is the dashboard installed on – Windows/Linux etc?

It’s always helpful to understand the lines of investigation that you have already worked through as part of your own 1st and 2nd Line support responsibilities prior to raising a ticket with the Panintelligence Service Desk. This level of information proves to be essential in painting a broad picture to us, which helps reduce the time taken to provide a response, as we can then target more specific lines of enquiry and rule things in and out more efficiently.

Should this level of information not be provided when the request is initially raised, this is highly likely to result in longer resolution times, and we may reject the request until a suitable level of information has been provided dependant on the issue.

Getting In Touch

When raising a ticket via e Mail, please ensure that the Subject line of your email follows the format below; Subject Line: Partner Name | (Your Customers Name) – Product and Version – Brief but informative title for the issue.

Whilst we offer an online ZenDesk portal to log tickets 24x7, it is strongly recommended that any email or Web-initiated support requests for Urgent issues are followed up with a phone call to ensure the shortest possible response time.

Request Types

Incident/Request

We assess tickets that are passed through to the Panintelligence Service Desk from our partners, and qualify these to be either an Incident, whereby something has stopped working or perhaps a Request whereby you just need a hand with digging into how something should be set up. On occasion, some of those Incidents could identify a problem with the software, and for those occasions we will adapt the ticket and switch it to be classified as a Defect (if its relating to the latest release) or a Bug if its something that’s been in the product for more than one version.

Defect / Bugs

Defects or Bugs are problems that exist within a product that prevent the product from performing a function that the product documentation claims it can perform. A software change is generally necessary to resolve a defect or a bug. If the issue is confirmed by our Development team, new code is usually delivered as a hotfix (applied against the latest version of software only) if the partner/customer is experiencing an emergency.

In some cases, Panintelligence may decide to address a defect/bug in a future release of the product, particularly if the creation of a hotfix is not possible.

Defect / Bug (SLAs)

An SLA is a contract between parties that defines the services provided, the indicators associated with these services, acceptable and unacceptable service levels, and actions to be taken in specific circumstances. Our SLA uses Greenwich Mean Time (GMT/BST) as standard.

Times expressed as a number of ‘Business Days’ include the hours from 09:00 to 17:30 UK local time, Monday through Friday, excluding designated public and national holidays. Unless specifically mentioned otherwise, all durations specified are in Business days.

The basic objectives of an SLA are as follows:

  • Better communication. It facilitates two-way communication between the parties. This communication starts at the beginning of the process to establish an SLA and continues throughout the life of the arrangement. The parties involved come together in order to understand each other’s needs, priorities and concerns, and to gain an insight into the problems which may be faced by each party through the failure of each party to fulfil their obligations

  • Guards against expectation creep. It is not uncommon for one party’s expectations of another to be higher than that which may be considered reasonable. Discussing these expectations and the resource commitments necessary to meet them is one activity undertaken in the establishment of an SLA. The process facilitates the identification and discussion of expectations. As a result, it helps identify service levels that are considered acceptable by each party and which are attainable and achievable

  • Mutually agreed standard. It sets an agreed standard against which performance may be measured. It identifies partner expectations, defines the boundaries of the service provision, and clarifies responsibilities. In the absence of a shared understanding about needs and priorities, it is easy for conflicts to arise between parties. An SLA and the communication process involved in establishing it help to minimise the conflicts between the parties and provides a means for conflict resolution should a problem arise

  • A process for gauging service effectiveness. As the SLA defines standards against which the service may be measured and evaluated, it provides the basis for performing an assessment of the effectiveness of the service

Defect / Bug (SLA Targets)

Priority

Initial Response

Tactical Fix

Full Fix

Priority

Initial Response

Tactical Fix

Full Fix

P1

12 Hours

24 Hours

Next Available Release

P2

24 Hours

5 Business Days

Next Available Release

P3

End of next Business Day

1 Month

2 Months

P4

2 Business Days

4 Months

4 Months

P5

2 Business Days

6 Months

6 Months

Priority Definitions

P1

Urgent

Interruption making a critical functionality inaccessible or a complete interruption causing a severe impact on services availability. There is no possible alternative.

P2

High

Critical functionality or access interrupted, degraded or unusable, having a severe impact on services availability. No acceptable alternative is possible.

P3

Normal

Non-critical function or procedure, unusable or hard to use having an operational impact, but with no direct impact on services availability. A workaround is available.

P4

Low

Application or personal procedure unusable, where a workaround is available, or a repair is possible.

P5

Minor

User specific or cosmetic issue that does not impact the usability of the application and does not require any form of work around.

Enhancement Requests

Enhancement Requests are additional product features suggested by partners/customers to make the product easier to use or add new functionality. Enhancement Requests are tracked in the same Panintelligence issue tracking system as incidents, request, defects, and bugs and are implemented in a priority order.

If an enhancement request is urgent, then contact your Customer Success Manager to discuss a possible Custom Product Opportunity (CPO), where we will consider delivering this specifically to meet your needs - this is a chargeable service.

For any enhancement requests, it is always helpful to understand the background of the issue, therefore information such as shown in the list below would be useful:

  • Partner / Customer Name

  • Total number of users using the product

  • Percentage/Number of users affected by the issue

  • Frequency of issue

  • User Impact Statement (e.g. user experience, performance) (one paragraph)

  • Business Impact Statement (e.g. regulatory compliance, revenue impact - please quantify as much as possible) (up to three paragraphs)

  • Business impact level: (Low, Medium, High, Critical)

    • Low Impact is defined as: Minor problem with small impact or functional restriction, impacting a small number of users (less than a hundred).

    • Medium Impact is defined as: Product can be used but some moderate impact or functional restrictions, impacting a moderate number of users (hundreds), several times a week.

    • High Impact is defined as: Product can be used but an important function is not available, impacting a large number of users (thousands), several times a week.

    • Critical Impact is defined as: Production system is down or is severely impacted

How we progress your tickets

  • Confirmation of Ticket being raised, and assigned reference number

  • Initial triage and qualification of the ticket is performed by the Panintelligence Service Desk team. Further information/clarification points maybe needed to help investigate this further

  • Where appropriate, the Panintelligence Service Desk team will engage with Consultants, Developers, Security and Cloud Engineers to assist with the investigation into more complex matters for you, therefore its imperative that we have a fully loaded breakdown of the information requested when raising a ticket

  • We may require a remote session to access your environment/that of your customer to help troubleshoot the issue, or we might provide you with steps to try to self heal… we use a variety of remote access software, so let us know what you prefer to use

  • If there is a guide or a training video that we believe would help you, we will point you to that also whilst still assisting as needed

Ticket Closure

Once we have resolved your issue, we will notify you that we are closing your ticket and the reason why – at this point we will issue you with a short satisfaction survey. These surveys help us to understand where we can improve, but equally we love to hear when we’ve done a great job – therefore please complete these where you can, as we really appreciate them.