Our safety committee is dealing with incident reports from 15,000 members and those incident reports are going into volunteer emails and haphazard spreadsheets when they really need to go in a ticketing type tracking system (maybe uservoice) where they can be marked as in-progress or completed and have a thread that shows communication/work that has been done. Ideally you'd also be able to tag issues. This allows committee members to easily see which incidents need to be followed up on and which incidents are happening regularly and it needs to be escalated to a risk management issue. Right now there is a ton of manual sorting that happens at the end of each year for annual safety recommendations but a lot of the way that is being done is just living in the safety chairs head which doesn't allow for someone else to step in. AND we dont have extra eyes on open issues where it would be good to have extra eyes to make sure issues dont fall through the cracks.

Separate the near-miss report and incident report. They serve different purposes and require attention and follow-up on a different scale.

Thanks for your feedback Jacob. As we shared in our last update, we are working on inclusion across our organization, and are seeking ways to be sure the behavior complaint form is more visible on the website so it can be used when needed. The E&I Committee hopes to eventually partner with the Safety Committee on ways to incorporate emotional safety into our safety reporting. To keep all of our safety committee improvements stored in one place, we're merging this request with Create More Robust Safety Committee Data Analysis.

After an activity, the behavioral complaint form should be also be included with the safety report form. If a member experiences any sort of discrimination we need to have the path of reporting a complaint simple and easy to find.

This is possible and would be a medium-sized project or maybe a big project depending on the needs and desires. It requires:

1. Changing the Incident Report Form from a web form to a content type (i.e. data object in both Plone and Salesforce with a Plone-SF sync of all the fields).

2. Salesforce licensing is staff only, so either a staff person would need to be responsible for incident reporting or we'd have to reconsider Salesforce licensing options and access for key volunteers.

Connecting incident reports to flow into Salesforce would allow us to use reports and dashboards to identify trends in more robust ways. Is this possible for the future?

Below are some draft incident reporting classes/categories we have played around with in the Tacoma Branch Kayaking Club. I think the same thought process could be applied to other activities. From an incident reporting standpoint, I took this concept from my 30 years in Army Aviation. I believe establishing classes or categories of incidents would encourage incident reporting but also help the reading audience understand the severity of the event right off the bat.

Kayak Safety Reporting Classes:

Class A: Loss of Life

Class B: Injury requiring external evacuation/medevac
Incident or equipment damage requiring external evacuation

Class C: Injury not requiring external evacuation but causing internal evacuation
Incident or equipment damage that significantly impacts paddle

Class D: Minor Injury not requiring evacuation
Minor incident or equipment damage that does not impact paddle

Class E: Unintended wet exit requiring self/assisted rescue in a non-training
environment