Viewdeck

SaaS Shop Service Level Information

Service Operations

We provide 1st, 2nd or 3rd line Service Operations for our Services depending on the Service Levels required. In all cases, Viewdeck will provide a service desk, incident and problem management, service reporting and event management function to clients.

Service Desk

Our Service Desk provides both manned and automated self service to clients 24 hours a day. The Service Desk provides the hub and control over service issues and the central repository for all service actions. 1st line support will provide end-user help desk capability, providing resolution and triage where necessary. 2nd and 3rd line support desks operating as part of the clients resolver group/Service Strategy, will support integrated incident and problem resolution and integrate support desk/ tooling where possible.

The Service Desk provides the Service ticketing and case management, providing control and management of service calls (Single ticket view, automated escalation, integration to alerting and reporting, team hand-off and resolver group co-ordination, KPI/SLA reporting and single view for clients).

Clients can interface to the Service Desk function via telephone, email and web browser 24 hours a day, and self service to raise, track, update and escalate tickets.

Tickets raised with the Service Desk will be acknowledged and triaged within 30 minutes of receipt, and then handed off or responded to based on the priority assigned to the Service Incident. All service requests will be authenticated by the service team, with only known, raised or registered/authorized service contacts. 2nd line service requests will typically be from known named business owners/administrators, and not expected from the clients (technical) 2nd line resolver team, having confirmed other local factors and having isolated the problem. They will be expected to provide detailed Incident details, to assist with resolution (including Application Logs, Ping Trails, Error Message and Screen Shots).

Problem Management

Problems raised by clients for catalogue items (eg. password resets, changes to user permissions, snapshot requests) will be triaged and responded to by the Service team within core service hours. Initial response will aim to resolve all 2nd service line tasks within 2 hours, 90% of the time. By definition, problems will be considered P3-P5 status, and prioritized accordingly, with P1/P2 incidents taking priority in such circumstances. The service incident ticket will get updated in the event that the problem/service change request cannot be resolved within the time, to keep the client appraised of the solution.

Incident Management

Incidents raised with the Service Desk will be triaged and responded to within 30 Minutes and actioned accordingly.

Each incident is assigned and responded to based on the following prioritisation and response model.

Priority
code

Urgency of response

Target response (within core hours)

Target resolution (within core hours)
(M-F x 9-5 )

P1

Immediate, sustained effort using all necessary and available resources until service is restored.

Immediate response, action within 15 Mins (Enterprise 24×7) , 1 hour (Outside Support Hours)

4 hours

P2

Immediate response to assess the situation, staff may be interrupted and taken away from low or medium priority jobs.

Immediate response (within contracted Service Hours), action within 2 hour

1 working day

P3

Response using standard procedures and operating within the normal frameworks

Email notification of call being logged (within contracted Service Hours) 1 hour. Response by email or phone within 1 working day.

2 working days

P4

Response using standard procedures and operating within the normal frameworks as time allows.

Email notification of call being logged (within contracted Service Hours) 1 hour. Response by email or phone within 1 working day.

5 working days

P5

Response using standard procedures and operating within the normal frameworks as time allows

Email notification of call being logged (within contracted Service Hours) 1 hour. Response by email or phone within 1 working day.

10 working days

During core Service Hours, incidents will be prioritised and managed by the Service Desk team. Regular updates to tickets will be provided to named recipients via email, as well as available via a web interface. A slack interface is also available to clients to interact with resolver teams if desired.

P1 / P2 Incidents

P1/P2 Incidents can be raised in the same way. Authorized client service representations (depending on where 1st, 2nd or 3rd line support has been requested) will be expected to provide supporting materials. P1/P2 Incidents will nearly always be highlighted by the event and service monitoring function prior to a service ticket being raised, and in the event that no information is available, clients will need to provide supporting information to correlate the request. The 3rd Line technical resolver group will be passed the ticket once basic triage has been conducted. 3rd Line technical support will liaise with the clients technical teams (typically their 2nd line Tower/ SIAM provided). 2nd / 3rd line support functions do not work with end users or 1st line support functions, as technical resolution often requires service analysts and technical resolution capability within a client to act as business liaison and service resolver across the wider service.

P1/P2 Incidents under a 1st and 2nd line support agreement include the appointment of a ‘Gold Commander’ to oversee and provide end to end resolution. 3rd line support in a technical resolver group, and in this scenario, the client will be expected to run/maintain the service incident team (with our 3rd line technical resolver group communicating back to the clients technical representatives in their service incident team). On successful resolution of the incident, the major incident report should be completed. For 1st and 2nd line support services, the VCL Service Incident Team will author and publish this report within 10 working days. In the core of 3rd line support only, we will provide technical details and any residual actions to the clients service incident team for inclusion in their Service Incident Report.

Clients should always follow through incidents raised via email or secure messenger that they believe are P1/P2’s, with a call directly to the Service Desk to ensure that the triage process has been initiated. P1/P2 incidents will be handled out of hours, 24×7.

For 2nd or 3rd line support services, the clients own service desk and resolver teams are expected to have triaged incidents before they reach the VCL Service Desk. Hence out of hours call outs that are labelled as P1/P2’s but show no fault in the VCL service, will be charged at the out of hours catalogue price.

Service Hours

Standard Service Support hours are Monday to Friday 09.00 to 17.00. Extended service operations are available as a catalogue upgrade, providing support 08.00 to 20.00 Monday to Saturday or 24×7 for ‘always available’ support functions. Ad hoc out of hours service requests are available as catalogue items to support client requirements (such as migrations, service transition or performance testing).

Service Reporting

We will provide regular monthly service reporting against key service performance indicators, including:

1. Service Problem and Incident Status /Performance

2. Service Availability

3. Service Highlights, Lowlights and forthcoming major events (eg planned outage, patch deployments).

Reports will be provided as PDF’s via email or web interface. Additional reporting will be available as a catalogue item.

Service Performance / Event Monitoring

Automated Service Monitoring and Performance benchmarks will be configured and baselined during the service design phase to reflect the requirement. The automatic monitoring will highlight service performance issues around responses and usability and will automatically raise an incident in the event that the Service has or is about to go out of bounds. Clients should raise incidents in the event that they are experiencing performance issues outside normal hours.

Catalogue change and change requests

Catalogue, small change requests should be raised through the service desk. In the event of approval needed against any agreed service order, additional authorization may be required before a service request can be actioned. Authorization and approvals will be confirmed during the Procurement Phase, and confirmed in the Service Agreement (or Call Off Contract). Larger change requests that fall outside normal catalogue items will be analysed and responded to within 5 working days. Changes that effect a change to the Service will be accompanied by a Change Impact Assessment. Where the Client is seeking Consulting or technical support in line with the service scope, budgetary figures for Time and Materials activity, to help the client achieve their goals, will be provided. Approved activity that requires additional resources will be actioned, with the expectation that any request will be started within 20 working days where new or additional capability is required.

Operational Security

The VCL Solution provides infrastructure/network based events management to support DDOS and other external network based attacks. These Services are provided by the underlying platform/ IaaS provider.

System Logs and events are captured by all hosts and centrally stored. These logs can be made available and shipped/streamed to the clients SOC/SIEM on request. (Streaming or forwarding is available as part of the service set up /design fuction, or as an additional catalogue item after service Live). Bespoke or ad hoc log extracts, log investigation and log shipping by the encrypted file to the client is available as a catalogue item.

VCL secure services include a range of security enforcing and reporting capabilities. As part of reviewing the Service, we will watch and act on any event that causes alarm or reaches appropriate thresholds. We will maintain the Service in a secure operational manner, and will advise /alert your security Lead in the event of wider concerns or events that need escalation.

Support for security investigation that goes beyond the need to maintain the Service and data/security obligations are available as a catalogue item.

Patch Management

Services will be patched and maintained in accordance with best practice, our service description and our ISO27001 operational principles. The underlying operating system and supporting infrastructure will be patched regularly (at least monthly) for non urgent /non-security related patches. Most operational systems will have host security patches deployed automatically as soon as they become available.

Application/Platform patches and Service upgrades will take a controlled approach, using a POC-Pilot-Live approach that sees upgrades tested in non-production environments before deployment to Live Services. VLC will work with the client to agree the deployment of all patches, and confirm the successful operation before moving from non-production to production. Services that require emergency security patches will be risk managed with the client and expedited through the testing process to ensure no service impacts. A backout/remedial plan will always be available for Application/Platform upgrades. Most Host/Operating system patches require a host reboot, which will be managed to support no service outage. This process will be conducted with the support /knowledge of the client and completed during low-risk times to minimise impact to patch deployment features.

3rd line support functions will only be expected to test/assure to the technical API layer (the wider business / Integration test being the Clients 2nd line resolver group responsibility).

Planned Service Outage

All technical services will have the need for planned service outages from time to time as a result of technical, operational or security events. Cloud Services run on shared infrastructure (eg. AWS) and can be subject to unplanned or very short notice service outages. While technical design provides high availability, the need for planned service outage has to be considered. As part of the Service Design process, planned outage windows will be agreed to provide opportunity to planning. Normal, non critical service outages, where necessary, will be informed 5 working days in advance. Critical changes that need to be acted on will be relayed to the client ideally 2 hours in advance, but may need to be at shorter notice in extreme circumstances. Client requests to postpone or avoid these outages for operational reasons will always be considered and agreed mutually as a risk managed loss.

Availability and Reslience

The Solution reflected in the Service Design provides technical means to overcoming compact and underlying failures. The service levels agreed reflect the projected availability levels, and correspond to design, architecture and underlying components.

As part of the solution provisioning, automatic recover and availability will be tested in common and predictable scenarios. Cloud Services have, by design, inherent weaknesses that can lead to frequent outages and changes. The VCL Services are designed and built to overcome problems that we and others have seen, but as with all solutions, removing all single points of failure is often not 100%. The Solution includes a number of resilient components to provide a stepped route to service recovery, some of which are automated (HOT), some on standby (WARM), requiring service desk action, and as a last resort, Disaster Recovery, with the Service being re-established in a new environment as quickly as possible

VCL Services use “infrastructure as code”/DevOps provisioning for all its services, ensuring consistent, automated rebuilding of capabilities in the unlikely event of the need to rebuild a capability from scratch. Our Services include the ability to distribute, shared, multi honed, geographically dispersed designs, targeted on different IaaS providers to reduce the risks to failures.

Access Management and Roles

During the Service Design Phase, initial access roles, accounts, passwords with any corresponding 2nd factor authentication (eg. fixed IP’s) will be agreed. Client representatives with agreed roles and responsibilities will be confirmed and baselined. The Service on boarding function will confirm the Service parameters.

Changes to access will be available by raising a problem ticket with the Service Desk and handled as a catalogue item.

Service Transition

Service Testing and Assurance

As part of the Service on boarding process the Service Design will be agreed, and the testing/Assurance process required, confirmed. Key service management functions including raising and managing service tickets, access to the Service Desk, Service Reporting, Access and Roles, Incident and Problem process, Financial and Change process will all be agreed and confirmed.

Technical/Functional services will be released and tested to confirm performance, availability (and resilience) backup (and recover), access and audit/log functions are enabled. Self service features will be tested. System monitoring, event logging, and alerting will be tested and integrated to the Service Desk.

As part of the clients service onboarding/Assurance process, we will provide test and confirmation of achieving sufficient maturity to meet go-live criteria (which would reflect a service with no equivalent P1/P2, and less than 3 P3’s or equivalent). The Service will be deemed accepted in its live operation once the client is using the source for real business transactions. Additional support for on boarding and Assurance process will be available as a catalogue item.

Security

The Service will be Pen-tested against all external interfaces to the Service against industry known/best practice attack vectors prior to go live. Given the Automated/Infrastructure Code nature of deployments, a risk based approach may be taken to avoid unnecessary duplication of activity.

Pen tests will ensure no major/critical issues have been identified (left unresolved) and a manageable remedial list of minor issues are under control.

Copies of the Re-test reports will be made available on request. Additional Pen tests (either internally or externally) are available as a catalogue item. Accreditable and “Authority to Operate” approvals are typically the responsibility of the clients Project Owner (who owns or represents the ‘use’ of the data). Any additional security or governance functions will be agreed at the Service Design stage and available as a catalogue item.

Training on Business Change

As a 2nd or 3rd line support and resolver group, Business and End User training, delivery and materials will be expected from the Clients Service Change Team. 2nd line services will typically include Business Administrator or Service representative training (‘train the trainer’) and will include product materials or internet provided Powerpoint, PDF’s, online videos and training functions. This will normally be limited to one training session, on-site, with additional training options available as a catalogue item. 3rd line services will typically be provided to the clients technical resolver group. Client technical services will be expected to have strong domain skills and knowledge, across a wide range of services and technologies in order for them to be able to triage and identify faults before escalation to VCL. This training session will again include existing product and service materials provided from 3rd party websites, online, PDF, Powerpoint and training materials. Additional training services will be available as catalogue items if the need should arise.

Release Management

Following integration testing, services will be released before acceptance to clients to provide early availability and opportunity to conduct client assurance functions. Prior to going Live, services may be taken down to remediate, conduct performance or penetration testing or to reconfigure.

Once operational, services will aim to also use a POC-Pilot-Live approach, releasing service changes (Patches, upgrades), initially in its non-production environments for clients to confirm/demonstrate Business/Application integration works successfully, (3rd Line services will demonstrate to the the API level that functionality remains unaffected). Business/Component integration remains a function of 2nd line resolver group.

All Application or Platform changes will be communicated and unless critical (and not able to be risk managed) will be sent/forwarded to the clients nominated Change Manager for approval. Once confirmed in a test/non-production environment, the clients approval will be sought (that all tests have been completed), prior to roll out into the live environment. Where deployment requires co-ordination across the resolver team, both parties will work together to identify mutually acceptable times to ensure smooth transition of Service. Out of hours support to the release process will be available as a catalogue item.

For clustered solutions, where patches and upgrades alllow, a staggered approach to roll out will be used to ensure there is no service outage. Additional VM’s /Hosts may be temporarily used to support migration, to enable cluster integrity and roll back options to exist in the event of unanticipated issues during the release.

Change Management

Change management inside the scope of the Service Agreement will be handled by either small catalogue based change, or Change Impact Assessments, resulting from a service desk request (or problem) that was outside the bounds of the normal operation. Change Impact Assessments can result in one of the following outcomes;

a) Simple T & M / Catalogue based approach to meeting the Service Request.

b) An assessment to the activity needed to fully assess the change impact, and budgetary costs to achieve;

c) An initial ROM (“Range, Order, Magnitude”) assessment to support planning and Business Case production.

d) A contract change note to make small alterations to the Service Agreement/ Call-Off contract to meet the request.

e) Rejection to the change request with indications of reasons, and mitigation to achieving the service change goal.

In all cases, each party will aim to provide a response and decision within 10 working days.

Knowledge Management

All Service assets, information and reports will be made available via self service interfaces, and typically web driven interfaces. All non proprietary and service related information (including Training materials and links) will be provided via secured web /internet based portals. The client will need to ensure users have access to VCL and trusted third party sites to enable its team members to have access to materials. (This may include access to video and streamed powerpoint content). Hardcopy materials can be provided as a catalogue item on request.

A project/Service home page/ wiki, will provide links to Services, tooling and contact details. Service details will be available also via the Project wiki.