Incident Reporting:
Bidlogix customers will report incidents using one of two methods:
By email to the Bidlogix Service Desk ([email protected])
By telephone to Bidlogix (+44 (0)845 056 1277)
Incidents reported by email or telephone will be logged in Bidlogix's Service Desk (Freshdesk by Freshworks) and internal software development tool (Atlassian JIRA) as and where applicable.
Bidlogix staff will report incidents to the Client Services Manager, Training & Support Officer, CEO and/or Product Owner, who in turn will log these in Bidlogix's Service Desk (Freshdesk by Freshworks) and internal software development tool (Atlassian Jira) as and where applicable.
2. Incident Assessment:
All reported incidents are assessed as follows:
Initial assessment is carried out by the Client Services Manager and/or Training & Support Officer (CEO if out of hours).
If the reported incident cannot be resolved by the Client Services Manager and/or Training & Support Officer it is escalated to the CEO and/or Product Owner.
The CEO and/or Product Owner will assess the severity of the incident and identify the appropriate course of action to facilitate a resolution.
Incident severity classifications:
โ
Low: Incident is due to lack of familiarity with the system and/or configuration options. Typically resolved by the Training & Support Officer and/or Client Services Manager by system training and/or application configuration changes.
Medium: Incident is due to a system defect but workarounds exist. Typically resolved by the Training & Support Officer and/or Client Services Manager by identifying suitable workarounds which reduces the impact of the incident to low, and any system improvement opportunities are assessed by the Product Owner for potential inclusion in the development backlog.
High: Incident is due to a system defect but workarounds exist. Typically resolved by the Training & Support Officer and/or Client Services Manager by identifying suitable workarounds which reduce the impact of the incident but as the overall impact remains high, a high priority development task is logged by the Product Owner in the development backlog to implement a resolution in the short term.
Critical: Incident is due to a system defect and no workarounds exist. Typically escalated by the Training & Support Officer and/or Client Services Manager to the Product Owner and/or CEO (as applicable) who will assess and raise an urgent development task for immediate resolution if/as required.
โ
3. Incident Communication:
Low severity incidents: targeted initial responses are within 3 working days, with resolutions (workarounds) targeted at within 5 working days. Progress updates are not typically provided.
Medium severity incidents: targeted initial responses are within 3 working days, with resolutions (workarounds) targeted at within 5 working days. Progress updates, if required, are typically provided daily.
High severity incidents: targeted initial responses are within 1 working day, with resolutions targeted at within 1 month. Progress updates are typically provided weekly, or at frequencies agreed with the incident reporter.
Critical severity incidents: targeted initial responses are same working day, with resolutions targeted at within 1 working day. Progress updates are typically provided every 2 hours (during working hours).
4. Incident Tracking and Review:
Bidlogix leverage Freshdesk by Freshworks for management, tracking and communication of incidents raised internally and externally. The system provides tools to report on incidents and these are reviewed quarterly for trend analysis and lessons learned.
Bidlogix leverage Atlassian Jira for management and tracking of incidents caused by system defects which require development resources to resolve. The system provides tools to report on incidents and these are reviewed every two weeks for trend analysis, root cause analysis and lessons learned.
Both aforementioned systems log incident steps, evidence, communication, status and outcomes.
5. System Recovery:
In the event of system failure necessitating system recovery where a host has failed, Bidlogix will:
Access hosting provider's management console and shut down failed host
Identify back up of failed host
Restore the previously shut down host and/or create a new host from the identified back up
Review and confirm networking configuration
Perform an exploratory test of the application to ensure it is back in production
Perform Root Cause Analysis and lessons learned