Support SLA

The provision of support services is dependent on the creation and agreement of a support Service Level Agreement (SLA) with our customers. The SLA may be part of or independent from a contract or statement of work.

Service Desk Portal

The Jira Service Desk portal offers customers a way to submit and track any ClinSpark issues.

Service desk access is granted to site subject matter experts who are part of each site’s core ClinSpark team and who deliver first line support to end users. This group of SMEs may change over time, so it’s important that customers ensure there is adequate coverage in the necessary functional groups and across geographies.

Registered service desk users can reach out to receive a list of currently registered portal users for their organization as needed. This may be helpful to do from time to time in order to confirm an accurate listing of team members who can collaborate on tickets.

Communication

The support team is geographically diverse and subject matter experts in various areas of ClinSpark. Communication on tickets may come from several members of the support team depending on the timezone and topic.

Customers who are in contact with a project manager / account manager may seek clarification on support topics through those resources. The PM/AM will ensure proper parties are notified on the support team for any particular topics that require attention or follow up.

Ticket responses are provided during contractually agreed upon business hours. All ticket correspondence is available to all service desk agents.

Service desk agents are also capable of opening up video/voice calls if necessary to walk through any challenging and urgent issues. This need is determined on a case-by-case basis.

Proactive Issue Resolution

Self Help

We expect sites to work with their ClinSpark subject matter experts to deliver first line support to end users. Customers are encouraged to try and solve issues that arise on their own first, seeking the answers in the Help site documentation. If issues cannot be resolved through self help methods, then the service desk portal is the best way to reach out to us.

ClinSpark Log Statements

ClinSpark was designed with a dynamic error log ‘appender’ to raise potential issues to support team members in near real-time. The ‘appender’ is designed to notify our support team when messages surface, and in addition, display the logging details in a support module available in ClinSpark to our personnel. Each environment server also maintains log files, which can be accessed by engineering and reviewed as needed for issue resolution.

When our team members notice a log statement that indicates a potential issue, a service desk agent may reach out to site SMEs to acknowledge that something was noticed and attempt to gather more information. When this happens, a ticket may also be raised on behalf of the customer and assigned for follow up.

Our goal with these efforts is to be proactive and resolving issues as they emerge, before customers notify our team. We want to try and address certain issues as they arise immediately, and when necessary, help customers in creating and following up on service desk tickets proactively as part of our overall support efforts.

Ticket Triage

Service desk agents will perform ticket triage to review details and assign tasks for follow up. To offer the best possible support experience, we ask for several important details when creating tickets. This may include requests for detailed screenshots or screen recordings of issues.

As part of triage we often verify the following:

• Full context of the issue, summarizing any steps that may have been taken or need to be taken to reproduce

• Environment details, including the URL of the environment the issue is related to

• Study, epoch, cohort, study event, and subject details wherever applicable

• Component/module of ClinSpark the issue relates to; referenced via left menu item (such as Samples > Processing)

• A specific date/time the issue started happening or reoccurring

• The usernames of any ClinSpark users experiencing or impacted by the issue

• Device details such as the type of device being used (laptop, iPhone, etc) and browser type/version

• Attachments that are related to the request, such as example reports or related documents that are directly applicable to the request

Ticket Follow Up & Closure

Standard procedure for ticket closure is for the customer, or service desk agent, to acknowledge that no further actions are needed and the ticket can be closed.

As needed, service desk agents may attempt to reach out to customers to verify the resolution status of an open ticket. After two repeated failed documented attempts to contact a customer to close an issue, an agent may close the issue.

Customers should not follow up with additional comments on tickets that are closed. Closed tickets leave actively monitored queues and follow up may not be available to all team members. Instead, for the highest visibility and potential to receive prompt follow up support, customers should raise a new ticket as needed for follow up. When doing so, referencing any previously closed ticket IDs will help establish links and context for reply.

Incident Tickets

Tickets that are classified as Incidents are established with a priority level to apply SLA goals applicable to response times. These goals are established via customer specific contract or statement of work. For most standard agreements, our target response times depend on severity of the issue.

Upon receipt and triage, a service desk agent may alter the ticket type and priority as appropriate upon investigation.

Non-Incident Tickets

Customers can also raise non-incident tickets to gain general support as needed. These may be ticket types covering ClinSpark use in pre-production environments (feedback from UAT or testing), requests for new environments, system configuration changes (reports, dashboard components, etc), or just general questions about the product.

Issues Not Eligible for Support

Requests to “Fix” data or report outputs after an error in study conduct

Sites may occasionally experience operational errors in study conduct. For example; data collection might be made against the wrong study event, or, subjects might be activated against an incorrect cohort. IQVIA may reject these requests to alter data or reporting outputs to “correct” such errors. Instead, these sorts of errors will need to be addressed by the customer’s Data Management team.

The reason for this is that we consider the integrity of the study data to be of the highest importance and a founding principle of eSource systems. We want both customers and Sponsors to trust that data is preserved as collected and with all audits accurately reflecting the original data lifecycle. For similar reasons, reporting from ClinSpark must reflect the actual state of this data in order for these outputs to be transparent and trustworthy.