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

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

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.