Content Comparison

Employees with non BC Gov emails joining the program

There are emails that do not have @gov.bc.

ca emails that are wanting to join the program (i.e., Auditor General). These non-bc gov emails typically means they do not have an IDIR. IDIR is an important aspect of being a member as it provides access to BC Gov systems.

For example, some of the volunteers in logistics in EMCR need to use WebEOC and the CORE Team application, both IDIR activated. Similarly, some of the volunteers in BCWS need to use their own systems like Resource Manager, also IDIR activated.

What do we do in situations where a CORE Team member used to be from a ministry, then they moved to Auditor General, does it mean that they are no longer a member?

Simultaneously, there is an overarching vision from senior leaders to have every public servant join the program.

The program/policy will need to be clarified first before any tech solution can be delivered. What we need to figure out:

• Program/Policy: Are we allowing folks that do not have BC Gov emails/IDIR to volunteer?

• Program/Policy: Are there different compensation models that exist for non-bc gov employees that we need to investigate?

• Program/Policy: Are there different work safety policies that apply for non-bc gov employees that we need to consider?

• Tech: Are all non-bc gov emails cannot use our systems? Is there a way to request IDIRs for these folks (PSA + OCIO?)?

Phase 1 of the User Journey: Awareness

During our research with potential members and current members, there is a need to expand our content to entice public servants to volunteer and to provide clarity on what is expected throughout the different phases of the journey as a volunteer.

Content revamped:

For potential members:

• Create videos of CORE volunteers that are not

• necessarily from BCWS or MCR. We heard from potential members that they would like to hear from someone who is from a “non-emergency” response ministry that they can relate to. For example, hearing from a member from the Ministry of Finance who is a Financial Analyst who is volunteering as a Planning Officer.

• Make it clear what’s in it for them

• to become a member: what do they gain as a volunteer for the program.

• Potential members have indicated having clear “job descriptions” for each of the roles can guide them on which roles they would want to volunteer for.

• Hold AMA

• sessions with seasoned volunteer vs. new to share experiences and learn about what happens during deployments.

For people leaders:

• Make it clear what’s in it for supervisors to approve their staff to be part of the program and for deployment

• Make the compensation process clearer for them; so they understand how their employees are being paid and who is paying for which portion (i.e. OT).

Phase 2 of the User Journey: Intake

Pending Applications:

There are still manual processes involved when Coordinators approve pending applicants in the system.

For example, members still have to send emails for their supervisor approval to the Coordinators and other required materials (i.e. ParQ in BCWS). Additionally, not having a solid set of requirements + transparency for when a pending applicant becomes an active member creates confusion.

We want to make our intake process user friendly as much as possible so we can attract new members to join.

More automation

need to solidify requirements first

design the dashboard

Continuously improve the intake process - Expand notification feature to send reminders for members to update their availability

Expanding the notification feature to enable Coordinators to send notification to CORE Team members to update their availability for deployment.

Coordinators will be able to send reminders to update availability individually, by region and/or in bulk.

Currently, Coordinators will need to remind CORE Team members to update their availability in an email with an excel sheet to be filled out; so that, members can indicate their availability 3 months in advance. However, we have found from research that what is needed is for a more timely manner of members to update their availability which needs to be triggered by the Coordinators.

Onboarding & Training

• Creating clearer criteria for what constitutes as Experienced vs. Chief level experience

• Map out an experience/skill level evaluation: where you know that if a member has been deployed 3 times vs. that they are experience

• With the associated role/function, a dedicated set of trainings are accessible and available

• Have the dashboard show all the trainings for a member

Deployment

Deployment history

Coordinator has the ability to send automated notification to members to update schedule

Post-Deployment

Deployment surveys

Payment/compensation

Data: STats

showing in the dashboard