Escalation Policy - PS x SO

Summary

When an issue is reported by a client or discovered internally by Solution Operations (‘SO’) team, it needs to be escalated through the Escalation Process, first to Product Support (‘PS’) and then to Development team (‘Dev’) which follows the Product Support Escalation Policy (‘Escalation Policy’) to determine Priority and management.

The process should allow us to efficiently reach a resolution, whether that is: an immediate fix, a workaround or a longer term code fix.

More information on ticket formatting / templates can be found here. 

Escalation Process

Overview

1. Reported Issue - Client or SO team report an issue.
2. SO Internal Review (Replicate + Troubleshoot) - SO attempt to replicate and troubleshoot the problem. SO ask client for more detail if needed.
3. SO Ticket + Track - Once replicated, SO make ticket for PS, setting out the i) steps / details to replicate, ii) expected results and iii) actual results. Need to include Priority of fix.
4. PS Investigate (SO Update Client) - PS Investigate in line with the Escalation Policy, trying to replicate and will escalate to Dev as necessary, providing regular updates to SO at the relevant intervals.
5. SO Update Client - If it is an urgent / important issue or the investigation is taking longer than a day, SO to regularly update client.
6. SO Test Fix - PS revert with the outcome of the investigation. Either a fix or alternative workflow, and SO test before reporting to client.
7. SO Update Client - SO report to client.

1. Reported Issue

1. Clients will report a problem via phone or email. SO need to respond as soon as possible - quick responses are key to avoiding unhappy clients.
2. The initial response can just be confirmation that we will investigate the issue and revert if we need further information or with any updates.

3. Do not apologise at this stage. Wait until we know if it is our fault and not a workflow issue - 

   apologising too early or too many times liquidates the sentiment of the apology.

2. SO Internal Review (Replicate + Troubleshoot)

1. SO must attempt to replicate the issue to verify it is a problem, before escalating to the PS team - it is very difficult to fix a problem that cannot be replicated. SO should be attempting to fix the issue if possible, but do not spend ages attempting to do so.
2. To replicate, follow the steps that the client has outlined or use own knowledge to fill in gaps.
   1. Note - If using own knowledge, you must be certain that is the only way they can achieve the outcome.
3. If you can’t replicate because there is not enough information, ask the client for further information, ensuring we are asking the correct questions to get the information to replicate. Exact questions will depend on the issue but generally a as a few examples: What is their exact workflow in terms of steps / buttons pressed, provide Bundle/Tab (or unique ID) examples, are other colleagues facing the same behaviour, send screenshots of any error messages (including Console), what is their setup (WFH / in office, wired / Wi-Fi etc), are they using Chrome etc.
4. If we get further information and still can’t replicate or fix, send message in SO team chat and ask for assistance. If S(S)OL cannot replicate or resolve, escalate to S(S)OM before creating ticket.
   1. Note - If S(S)OM unavailable, please proceed with escalating to PS via ticket.

3. SO Ticket + Track

1. SO need to write an email ticket in line with the PS / SO Escalation Policy, setting out the relevant information as listed below.
2. Priority is a scale of P1 (highest) to P4 (lowest) with value being assigned based on importance of the issue, urgency of fix and if there is a workaround. Each stage will trigger a different approach to updates and speed of onward escalation to best manage resources. It is very importantthat we assign the appropriate Priority for the issue and we do not overplay (or underplay) the Priority – it should adhere to the Escalation Policy.
   1. Note - Only S(S)OM can assign P1.
3. Any tickets should include the below: (Template example and populated example attached)
   1. To:se-uk@opus2.com 
   2. CC: Relevant SO team (Arb / Lit / Inq)
   3. Subject Line:Priority - Server - Case Code - Brief Description of Issue.
      1. i.e. P2 - UK30 - 12345A - Client can’t export.
   4. Body:
      1. Priority: Priority as per escalation policy
      2. URL: Full URL of workspace (including Workspace ID)
      3. Timelines: Any key timelines for fix / update, in line with Escalation Policy
      4. Description: Brief summary description of issue
      5. Steps to Reproduce: Step by step guide so someone can follow and click through the platform to re-produce (including any examples with URL of document or Database IDs (not just Bundle/Tab or Magnum ID etc) for relevant workspace, any tests we have run)
      6. Expected Result: What should happen
      7. Actual Result: What actually happens
4. Where possible, S(S)OM should check tickets before sending - If S(S)OM unavailable, proceed with sending ticket.
5. Once the ticket is created, add the client email to the board for tracking purposes and include the ticket number in the comments, with a status i.e. ticket raised at 4pm, waiting response from PS. Flag with the late / US shift if we need to give updates etc. Need to chase PS following day if no update received. Need to make sure we are following through with tickets as a team, not just individuals.

4. PS Investigate (SO Update Client)

1. PS should investigate the issue in line with the Escalation Policy. In the event it is escalated to Dev, PS will create an incident channel (Slack) and the issue will be discussed. SO to monitor channel and assist where needed.
2. PS should be providing updates in line with the Escalation Policy. If not adhered to or client chases SO, follow up with PS on the ticket (and Slack if P1/P2).
3. SO should update client at sensible intervals depending on Priority, i.e. at least once a day before signing off for standard issues, if more important / urgent, need to update more regularly. Where possible, consult with S(S)OM on wording for updates.
4. For each update, ensure SO say when the next time is we will provide an update to a client so we can manage expectations, especially on important / urgent issues – very important to ensure we are meeting the provided timeframes.

5. SO Test / Fix / Alternative Workflow

1. Once PS revert with the outcome of the investigation, do not assume it is fixed. SO must test the fix / alternative workflow to ensure they i) fully understand the issue and fix (so you can explain to a client and field any queries) and ii) SO are happy the issue is fully resolved.
2. When testing, SO should follow the exact steps to reproduce as provided by the client to confirm it achieves the desired outcome.

6. SO Update Client

1. Once fix / alternative workflow confirmed, SO need to update the client. Consult S(S)OM on wording for update as needed - apology should be included at this point if Opus’ fault.
2. In the response, keep it light touch / concise / factual, clients won’t generally care about the details as long as it is fixed – explain to client if they need to do something differently. Only say it won’t happen again if we are 100% sure of this.
3. For larger issues or unhappy clients, fluffier explanations can be helpful with some more detail and apologies etc. S(S)OM consultation required.
4. In the event it is an issue in the code and therefore requires long term development work, usually improvements or bug fixes, can use ‘We have logged the issue / idea for development however this is unlikely to be available in the life cycle of your matter’ etc.

Product Support Escalation Policy

Overview

The Escalation Policy sets out the framework for i) how SO should assign Priority status to a ticket and ii) how PS should subsequently manage the investigation. Adhering to the policy should ensure efficient management and effective communication until a resolution is found.

1. Assigning Priority

1. P1 – Critical failing of the platform or issue with high client impact or sensitive confidentiality / security issue.
   1. Escalation - All hands-on deck approach needed and PS to escalate to Devs immediately if PS don’t know the answer from the outset.
      1. Example: Server outage, user access issues, data recovery, confidentiality breach.
2. P2 – Major failing of the platform which results in loss of core functionality where there is no workaround or where PS intervention required to complete a time-sensitive task or resolve a time sensitive P3 issue.
   1. Escalation - PS to initially investigate but should escalate to Devs if answer cannot be found after two hours of ticket creation.
      1. Example: Core functionality issue (Upload / Export / Search), unarchive not working.
3. P3 – Standard failing of the platform which results in loss of functionality to less important tools or to more important tools with a work around. 
   1. Escalation - PS to initially investigate and escalate to Devs only where needed, on a less urgent basis.
      1. Example: Export from a tag level not working, cannot use Sort tool.
4. P4 – Low failing of the platform which has minimal impact on a client or SO team but should be resolved in the long term. 
   1. Escalation - PS to initially investigate and escalate to Devs only where needed, on a non-urgent basis.

      1. Example: Button wording is spelt incorrectly.

2. Communication and Escalation Timeframes

The expectations for a. SO raising tickets and timeframes for b. PS communicating updates and escalating are outlined below. All times are in minutes and should be maximum intervals.

1. SO
   1. Raising a Ticket – The method for SO notifying PS. Each stage will always need a Ticket creating. Only use Slack for P1 and urgent P2 tickets, to flag with PS it has been created and needs urgent attention.
2. PS
   1. First Response – Acknowledge they have received the ticket and are investigating.
   2. Plan of Action – Confirm what the plan is, who is looking into it, do they need more information etc.

   3. Subsequent Updates – Time intervals for when updates should be provided. These don’t always need to be substantive updates but confirms active investigation.

      1. Before signing off for the day, should provide SO with an end of day update, confirming what the plan is for the next day and that no further updates will be sent that evening.