Service Levels
In addition to providing Software Service Levels for the dashboard software, we provide them for our Platform Hosting Solution - known as pi SaaS. The sections below detail the service levels covered for both aspects, depending on your needs.
Software Service Levels
All partner cases which are raised through our Service Desk are qualify to be either an Incident, whereby something has perhaps stopped working, or a Request whereby you need some help to understand an issue better and how best to configure something that is not obvious. These are seperate to raising a Feature Requests.
On occasion, it can happen that an Incident identifies a problem/bug within the dashboard software and for those occasions we will adapt the ticket and switch it to be classified as a problem/bug.
The basic objectives of an SLA are as follows:
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.
Expectations. 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 Standards. 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 helps to minimise the conflicts between the parties and provides a means for conflict resolution should a problem arise.
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.
Problems / Bugs
Problems/Bugs exist within a version of the software that prevent the product from performing a function that the documentation claims it can perform. A software change is generally necessary to resolve a problem/bug, however a workaround to the issue maybe possible to help as an interim step before a software change is delivered.
If a problem/bug is confirmed by our Development team, the case will then be assigned a priority for resolution;
Priority | Description / Example | Initial Response | Tactical fix 24 | Full Fix |
|---|---|---|---|---|
P1 | A complete business down situation or single critical system down with high financial impact. The client is unable to operate. | 12 hours | 24 hours | Next available release |
P2 | A major component of the clients’ ability to operate is affected. Some aspects of the business can continue but its a major problem. | 24 hours | 5 business days | Next available release |
P3 | The clients’ core business is unaffected but the issue is affecting efficient operation by one or more people. | End of next business day | 1 month | 2 months |
P4 | The issue is an inconvenience or annoying but there are clear workarounds or alternates. | 2 business days | 4 months | 4 months |
P5 | The issue is a background or planned task and will be addressed when time permits or on the planned date. | 2 business days | 6 months | 6 months |
Resolution
For P1/P2 problems/bugs, new code is usually delivered in the form of a Hotfix (only applied against the latest version of software) - this approach maybe considered should the partner be experiencing an emergency situation.
For lower priority problems/bugs, we prefer to address these in one of our future releases, particularly if the creation of a hotfix is not suitable.
Our SLA uses Greenwich Mean Time (GMT/BST) as standard. Times expressed as a number of “Business Days” applies as per our Support Hours page.
Platform Service Levels
Pi SaaS
Availability |
|
|---|---|
Guaranteed Uptime | 99% uptime commitment for customers on the PiSaaS subscription. |
Downtime is the overall number of minutes Pi SaaS was unavailable during a defined period of time, e.g. calendar month. Server monitoring software is used to monitoring the software and measure the server side error rate, ping test results, web server tests, TCP port tests and website tests.
Downtime excludes the following:
Slowness or other performance issues with individual features
Issues that are related to external applications and data sources or third parties
Any products or features identified as pilot, alpha, beta or similar
External network or equipment problems outside of our reasonable control, such as bad routing tables between your internet service provider (ISP) and our server or software issues on local machines
Scheduled downtime for maintenance
Scheduled Downtime
Sometimes we need to perform maintenance to keep Pi SaaS working smoothly. If scheduled downtime is necessary, we’ll give you at least 48 hours’ advance notice - with details being recorded on our System Status & Maintainance page.
Support Hours
We provide PiSaaS support during our standard Support Hours, which can be found HERE. For all piSaaS requests, please Raise A Support Case through our Service Desk.
NEWS: We are pleased to share that our April 24 dashboard release is now available to download, see HERE for more details