Follow

Actionspace Service Policy

 

This document is an indispensable part of Actionspace End-User License Agreement

Proposed support workflow is based on the ITIL standards and best techniques and includes not only reactive but also proactive procedures to insure high quality of the provided service.

1.1 Summary

This document applies to Actionspace Basic Cloud service customers only.

Actionspace Self-Service subscribers cannot rely on the services described below, as they rely on their own effort while using the Product.

Actionspace Premium services customers benefit from dedicated service policies, including such options 24/7 support, faster response times, phone hot-line support, extended service hours, etc. Such customers are served under a separate contract. Current Actionspace Service Policy doesn’t affect such customers.

Actionspace trial users cannot rely on the services described below, they should forward any requests at info@actionspace.com.

All requests are processed only via our global technical support portal: https://actionspace.zendesk.com , no other way of submitting a request falls under the provisions of this Actionspace Service Policy.

Every Actionspace Basic Cloud service customer is entitled for 5 hours of services per month.

1.2 Benefits

  • The benefits of the proposed Actionspace Service Policy are:

    • ITIL-aligned Incident Management policies, processes and procedures
    • Incident escalation standards
    • Dedicated Incident Management Process owner
    • Incident classification categories
    • Incident reports and analysis
    • Incident communications and education for the staff.

1.3 Definitions

All the definitions provided in End-User License Agreement hold true for this document. In case of any conflict, the definitions in End-User License Agreement should prevail.

 “The Contractor”, “The Consultant” – Actionspace LLC.

“The Client” – Actionspace Basic Cloud service customer.

“The Client ID” – a unique client identification code given by the Contractor to the Client on purchasing the Actionspace Basic Cloud service.

“Actionspace’ cloud environment” – online virtual environment at https:/cloudapp.actionspace.com used to host the Product and provide its functions to the Clients.

 “Change Request” – an optional service, i.e. a request for modification of the existing functionality of the Product or adding new functionality that the Client and the Contractor may from time to time agree to be supplied to the Client by the Contractor. Such requests are handled within separate contracts within Actionspace Premium Services offering and are not included in the current Actionspace Service Policy.

“Incident” – is an event which is not part of the standard operation of the Product and which causes, or may cause, an interruption or a reduction of the quality of the Product. Incident may be classified as Consulting request or Fault.

“Consulting” – consulting of the Client on the system installation, settings, updating and usage, faults analysis, error environment reproduction and the Client’s requirements specification, including possible fixes of the problems that are not related to the system code or database modification.

“Fault” – a defect in the Product which prevents the Client from using a part of or all existing functionality of the Product and which requires code or database modification for fix.

“Priority 1a Fault” – error in the Product prevents the Client from using the Product completely, error is critical for the Client’s business. The priority 1a is assigned if the cause of the error is in the technical platform, Actionspace’ cloud environment, Client’s environment or associated systems.

“Priority 1b Fault” – error in the Product prevents the Client from using the Product completely, error is critical for the Client’s business. The priority 1b is assigned if the cause of the error is in the Product functionality or Product configuration.

“Priority 2 Fault” – error is not critical but prevents Client from using one or more of the main functionalities of the Product but does not prevent Client from using the whole Product.

“Priority 3 Fault”, “Medium Priority Fault” – error prevents Client from using or more one of the functionalities of the Product but the functionality cannot be considered as a main functionality of the Product.

“Priority 4 Fault”, “Low Priority Fault” – error in the Product is not meaningful to Client’s business and the error cannot be categorized in any class above.

“Workaround” – a temporary fix that implies that a genuine solution to the problem is needed, presumes no major changes in the existing functionality.

“Support Manager” - the person appointed by the Contractor to be responsible for the co-ordination of all matters relating to providing the services.  All communications, documentation and materials relating to technical support agreement shall be sent as appropriate by the Support Manager to the Product Responsible Manager.

 “Project Communication” – tasks performed by the Support Manager, i.e. workload evaluation, communication and agreement upon workload and deliveries-schedule; reporting.

“Product Responsible Manager” - a person appointed by the Client to be available to connect with, respond to queries from the Support Manager, to monitor and follow-up technical support activities and progress, as well as decide if and when the Faults and Change Requests priorities should be altered.

 “Support team” – specialists of the Contractor involved into service process including developers, testers, and deployment engineers. Support team is not involved into the communication between the Client and the Contractor and is controlled and managed by the Support Manager.

“Service time” – 8:00 to 17:00 (Central European Time), Monday to Friday, except on days which are official holidays in Russia.

“Business hour” - shall be any 60 minutes period of time in Service time.

“Overtime hour” – hour out of Service time, that can be utilized for service activities on the special request by the Client. Overtime hour services are available for Premium Services customers only.

“Working Day” – one day full Service time period.

In case the services are provided at the Client’s premises and the Client and the Contractor may agree to follow business days, business hours and Overtime hours according to the Client’s location, Such services are available for Premium Services customers only.

“Help Desk System”, “HD system”– software, which is used to manage and track incidents, requests for consultancy, change requests and work orders. Help Desk System also provides functionality of Knowledge Base allowing tracking the history, gathering statistics and re-using experience. Help Desk System is to be defined by the Contractor. As of now the HD system to be used is
at actionspace.zendesk.com.

“System downtime” – the time while the Product is not available (either the technical platform of the Client is up and running but the Product does not respond to user requests or the Actionspace’ cloud environment is down).

1.4 Service workflow

This section provides detailed description of the service process, its definitions, steps and tools.

1.4.1 General terms

  1. The Client shall assign a Product Responsible Manager(s) and provide him/her with the Client ID to be able to send requests via HD system. The final contact-list is to be defined and sent by the Client to the Contractor no later than 10 days after the Order procured by the Client on the Site. If the Client doesn’t send the Product Responsible Manager(s) list as stipulated above, the Contractor retains the right to decline the service of the requests by such Client.
  2. The Client is to register in the Help Desk System to be eligible to submit requests.
  3. The Product Responsible Manager(s) shall always indicate the Client ID while sending their requests via HD system. If the Client ID is not indicated the Contractor retains the right to decline the service of such requests.
  4. The Contractor assigns a Support Manager(s) to communicate with Product Responsible Manager and the Client’s representatives, gather requests and provide consultancy help. Support Manager may be changed by the Contractor at any time with no consent by the Client required.

1.4.2 Prerequisites

  1. The actual information or a part of information from the Client’s account can be restored in the Contractor’s test environment if it is proved to be necessary to provide the system support. The operation should be confirmed by the Product Responsible Manager.

1.4.3 1st and 2nd levels of support

1st and 2nd levels of support are covered by the Contractor, where 1st level involves Consulting on simple, recurrent requests on the Product functioning and 2nd level involves Consulting on complicated, non-typical requests requiring deep engineering skills in managing the Product.

1.4.3.1 Incident detection and recording

  1. A representative of the Client submits a request via a Help Desk system to the Contractor. Each Client has a code assigned to him on the moment of the Order. The nature and priority of an incident shall be determined by the Client following the error types specified in the Section 2.3 of this document and agreed by the Contractor inside the request in the HD system.
  2. The Support Manager acknowledges the request about the incident and informs the Client about the start of its processing by changing the status of the request in the Help Desk system. The acknowledgement contains essential information on the incident. The response time conforms to the response time specified below and depends on the priority, determined by the Client and agreed by the Contractor.

1.4.3.2 Classification and initial support

  1. If the request is accepted by the engineer (Contractor’s support specialist) on duty, it is transferred by him to the Support manager. The Support manager analyses the request and estimates changes feasibility and time/resources needed.
  2. If the nature and the priority of the incident are not initially defined, the parties (represented by Support Manager and Product Responsible Manager) are to define it in writing prior to any further activities. During the processing of the request its type (Fault, Consulting or Change Request) can be changed based on new information.
  3. In case an incident is qualified as a Fault report and requires code modification, it is transferred to the Contractor’s development team, if configuration adjustments, access-right alterations etc. are deemed as insufficient.

1.4.3.3 Investigation and diagnosis

  1. The Contractor can send requests for information (details) on a submitted request to the Client using Help Desk system and expect to get response in proper time – see response-time specified below. If the response is not received from Client’s specialists in time, the time frame is to be extended for the period of such delay (with the downtime to be covered by the Client).

1.4.3.4 Resolution and recovery

  1. If an incident implies Consulting service:
    1. The Contractor’s specialists provide it either themselves or giving the requested advice to the Client’s representatives. The definitive approach is to be defined separately for the request during its issuing and acknowledgement.
    2. The Contractor’s specialists perform support activities that correspond with the request type. Prior to any actions that may affect the system availability, data or users, the Support Manager informs the Client’s representatives about the steps to be undertaken.
  2. In case an incident is qualified as a Change Request:
    1. The Support Manager estimates the resources needed and agrees on the Change Request further activities with the Product Responsible Manager.
    2. Further activities are performed within a separate agreement between the Client and the Contractor.

1.4.3.5 Incident closure

  1. The incident status response (e.g. completion of the incident processing) shall be sent by the Support Manager to the Client’s representative that submitted the request via the HD system.
  2. If the Client’s representative is satisfied with the answer or activities performed in the scope of the request for Consulting, he or she acknowledges the request is satisfied and closes the corresponding incident.
  3. If the Client’s representative is not satisfied with the answer or activities performed in the scope of the request for Consulting, he or she may resubmit the request with more details and new information for its further solving.
  4. After the incident closure is confirmed by the Client’s representative or Product Responsible Manager in writing, the incident’s record in the Help Desk System is marked as closed.

1.4.4 3rd level of support

3rd level of support is covered by the Contractor’s high-skilled programmers.

1.4.4.1 Resolution and recovery

  1. The time frame within which each Fault must be resolved starts upon the Contractor’s receipt of a notification of the Fault from the Client via HD system.
  2. The Contractor can send requests for information (details) on a submitted request to the Client using the HD system and expect to get the response in proper time – see response-time table below. If the response is not received from Client’s specialists in time, the time frame is to be extended for the period of delay (with the downtime to be covered by the Client).
  3. In the event that the Contractor anticipates that the Fault will not be resolved within the specified timeframes, the Contractor shall inform the Client as soon as possible that deadlines will not be met and give detailed reasons for the delay, as well as the estimation of the time necessary to fix the delayed Fault.
  4. If there’s a workaround for the reported Fault, the Support Manager informs the Client about it using the HD system.
  5. The Contractor performs support activities that correspond with the request type.
  6. Processed requests are published in the HD system.

1.4.4.2 Incident closure

  1. The incident status response (e.g. completion of the incident processing) shall be sent by the Support Manager to the Client’s representative that submitted the request via the HD system.
  2. The Client’s representative checks the incident completion and acknowledges, if the request is satisfied and approved.
  3. If not approved, the incident is returned to further fixing. The Client’s representatives or IT personnel are to provide necessary details of the error to the Support Manager.
  4. If approved, the Client’s representative acknowledges this in the HD system, the incident is then closed.

1.4.5 Monitoring activities

Besides the activities on the incidents reported by the Client, the Consultant also performs standard monitoring routines of Actionspace’ Cloud infrastructure. The definitive routines are defined to guarantee the highest reliability and ensure business continuity.

The following options are proposed, but not limited to:

  1. Monitoring the server availability
  2. Monitoring web services proper functioning via auto-tests
  3. Monitoring of the operational logs
  4. Manual monitoring of the key integrations with Office 365

1.4.6 Incident ownership, monitoring, tracking and communication

  1. Incident ownership is hold by the Support Manager though all its lifecycle.
  2. Operational monitoring of the current incident’s status can be performed by both Parties represented by Support Manager, Support Team, Client’s representative and Product Responsible Manager with the help of the Help Desk System.
  3. Communication between the parties is performed only via HD system

1.4.7 Measurements and control

The Consultant performs internal control of the time spent on servicing the requests by each Client and the quality of service (Actionspace cloud infrastructure availability statistics, response and resolution times of Client’s requests). The information regarding a specific Client is available for such Client on demand.

1.5 Obligatory content for client requests in HD system

The following information is obligatory to provide with the incident report:

  1. Incident type and priority
  2. Application part to which error appears
  3. User for whom the incident appears
  4. Steps to reproduce the issue
  5. Screenshot, if available.
  6. Client ID.

1.6 Requests classification

Requests are broken down into types by the following criteria:

  1. Problem type (this is identified by the Client’s representative submitting the request or, if not defined originally, by the Support Manager and then approved by the Client).
  2. Priority (this is identified by the Client’s representative submitting the request or, if not defined originally, by the Support Manager and then approved by the Client in writing): high, medium, or low. The priority reflects the level of importance of the problem and can affect the order of request processing.

1.7 Communication Plan

This section describes the important details about the communication process that is held by the Client and the Consultant during system maintenance and support, also this section provides list of responsible persons, channels and methods of communications.

The Consultant guaranties the constant access to the support facilities within the limits of SLA. We expect that the reports from end users will be gathered by the dedicated Client representatives and then transferred to us via HD system.

We also expect that the incoming requests will be evaluated by the Client representatives in order to prioritize them and provide the maximum of available details (see section 1.5). Client representatives should report the requests straight to the HD system. Other requests shall not be processed.

All the decisions taken and the information transferred should be put into the Help Desk system to keep history.

We encourage the close communication between the representatives of the Client and the Consultant on project matters in order to secure the fast and precise delivery of the up-to-date information to the Parties. 

2 Service Level Agreement

In this section all formal service level requirements and penalties are stated.

2.1 Product availability

The Product should be available 24x7, unless for the service time to do Planned Maintenance work, such as backup, system upgrade, etc.

All of this planned work should be planned to fulfill service time requirements and the Client should be always informed by e-mail about the period of such non-availability.

“Non-operation” means that the Product does not respond to the user requests outside the period of Planned Maintenance work.

2.2 Service time

Hours of service are 8:00 to 17:00 (Central European Time), Monday to Friday, except on days which are official holidays in Russia.

2.3 Response & Resolution Time

##

Types of Requests

Response time

Workaround time

Fix time

a)

Critical Fault (1a and 1b)

1 hr

4 hrs

16 hrs

b)

Priority 2

2 hr

10 hrs

10 days

c)

Priority 3

8 hrs

4 days

20 days

d)

Priority 4

16 hrs

8 days

n/a

If the response is not received from Client’s specialists in proper time, the Response Time is to be extended for the period of such delay (with the downtime to be covered by the Client).

In case the incident is classified as Critical Fault (priority 1a and 1b) and was reported during Out of Service time, the Response Time is counted from the moment of incident acknowledgement by the Consultant.

2.4 Non-operations and SLA breach penalties

In case of non-operation (downtime) of the Product which wasn’t due to the Client’s inability to provide relevant information to Consultant, the penalty is calculated proportionally as a ratio of such non-operation (downtime) to the overall service period. E.g. if the Product was non-operable for 1 hour during a month then the penalty size will be calculated as (The monthly payment per Basic Cloud Package) divided by (The number of days in a given month) multiplied by (1/24).

In case of breaching the Response and resolution times specified in the Section 2.3 Consultant should extend the number of service hours available for the Client within the next service period (month). E.g. if the overall delay in response and resolution time is 1 hour, then the Client is eligible for 1 additional hour of service within the next month of service. The maximum number of extended hours of service should not be greater than 3.

Submit a request →

Comments

Powered by Zendesk