¶ Overview
- Door use Jira Support as the support management tool. It is fully integrated with the support email account support@doorfunds.com.
- Support tickets are automatically generated whenever emails are sent to the support mail address.
- If a client or Door CRM* requires assistance or support they must raise a support ticket by emailing support@doorfunds.com or asking their CRM to raise a ticket on their behalf.
- When a new support ticket is created in Jira Service Desk, an automated response is sent to the client to confirm receipt. Email template sample below
- All “Customer/public” updates within the Jira ticket will be visible to clients (those who raised the ticket + watchers)
- All technical/confidential notes must be set as internal only
*‘Client’ hereon refers to external client or internal CRMs
Email Template
The following is an example of what the client raising a support request will receive.
We include the SLA and definition for clarification.
¶ SLA & Severity Levels
¶ SLA
| Severity Level | Response Time | Status Frequency | Time to resolve |
|---|---|---|---|
| Critical | 30 minutes | 60 minutes | 4 hours |
| High | 60 minutes | 180 minutes | 48 hours |
| Medium | 12 hours | As appropriate | 3 weeks |
| Low | 24 hours | As appropriate | As appropriate |
¶ Severity Criteria
| Severity Level | Criteria |
|---|---|
| Critical | Major application component is down or otherwise unusable via the DOOR Platform which impacts all Users who are unable to use the Service in Customer’s production environment and there is no workaround. Web services module is down in production and is affecting major functionality within the Service. |
| High | Application component is significantly impaired although still operational which impacts an individual User or subset of Users in Customer’s production environment. |
| Medium | Application component is down or otherwise unusable via the DOOR Platform and there is a workaround therefore not preventing the User from doing his/her job. Web services module is working in production; however, there are minor issues. Customer cannot access DOOR help website to download documentation or view tutorials. Any issues defined as Critical or High in production are considered Medium in test environments (test, UAT, Sandbox, Development, etc.). |
| Low | Minor functional or cosmetic issues that have no adverse effect on the day to day business of Customer. |
¶ Process flows
¶ Client Engagement
Support will follow the process flows in order to resolve client requests. The support team will liaise directly with clients via:
- Jira support ticket
- MS Teams (or equivalent screen sharing tool)
¶ Support Engagement
¶ Support Types
- Change Requests
- Service Request
- Incidents
- Internal Requests
- Feedback/Functionality Request
The Jira support ticketing process has the option to change each ticket to the relevant “type” from the above list. Each type has its own process flow that has been documented below.
When a client sends an email to support@doorfunds.com the initial ticket will be raised as “email Request”. It is the responsibility of Support to change the type by following the process flow below in conjunction with this page.
All resolution steps must be documented as internal notes within the ticket, including any 4 eyes resource details.
¶ Support Resolution
Requests from clients that require data changes; but that can be handled without “Product” or “Dev” interactions (i.e. a new build is not required). This can include system configuration changes etc.
Requests from clients asking for information on how to achieve a specific result with the Door Platform.
Request from client that has highlighted a potential issue. The issue appears to be something that will require a code or infrastructure change.
Request from client asking specifically for something that is not yet available within the platform
¶ Direct Database updates
It may be necessary for support to resolve tickets by updating client data directly on the production database.
- Changes should be applied to Support or Preprod and verified as having had the desired effect before a change is made to Production. The scripts generated should always aim to have 2 where clauses for safety where possible and after the 4 eyes process the tested and verified script should and be used in production.
- In order to work with the latest data on support or preprod it may be required that the Jenkins Preprod deploy job is executed to get the latest production database data available.
- As per the process flow, all changes must follow the 4 eyes process
- All changes made against the DB must be documented on Jira
*SQL commands for supporting/fixing regular requests are located on Confluence for those with permissions.
¶ Third line support process
The third line support is managed on the QA/Operations board on the Door Jira project. This process is specific for the Bugs raised on the QA/Operations board. It consists of 2 columns:
- Triage – listing all new tickets created by the service desk manager. Tickets include a link to their original JIRA variant.
- Ready for sprint – Listing all tickets that have been assessed and analysed by PO that can be picked up by a developer.
¶ Process description
The 3rd line support development process works slightly different compared to the normal development pipeline, but it runs in sync to it. The following conditions apply:
- 3rd Line support has a dedicated developer assigned to it each sprint
- The developer picks up the first ticket from the
ready for sprintcolumn - The developer moves the ticket directly from the QA/Operations board to the
In progresscolumn on the Sprint Work board - The ticket follows the normal development/QA pipeline
- There cannot be multiple tickets from the support board in progress simultaneously
- The designated developer can pick up a new ticket from the ready for sprint column as soon as he deploys the fix to D
This flow guarantees a continuous, uninterrupted fulfillment flow of client requests and of bug fixes throughout the sprint. Because the prioritisation is done on a ticket by ticket basis, and not 2 or 3 weeks in advance, the Kanban process allows for even more flexibility than a normal agile sprint.