Information - CORE Team

Raise awareness about the program; so that, BC Public Servants are enticed to join.

BC Government employees submit an application to join the program and become a CORE Team member.

CORE Team members are aware of the different roles and sections that they can volunteer in and are receiving proper training and onboarding to fulfill those roles.

CORE Team members are getting contacted by Coordinators to learn about their availability for deployment and the function/role they want to volunteer in.

CORE Team members go back to their base jobs and are able to provide and receive feedback on how they did on their deployment.

EMCR Dashboard & Member Profile

To keep a complete list of EMCR CORE Team members, active and inactive, and their availability. It’s a database that retains information regarding members such as:

• Availability

• Roles/Functions members are interested in volunteering

• Region/Location

• Member information: Name, Ministry, Union Membership, etc.

The dashboard replaced the multiple excel sheets that regional coordinators are managing to keep track of members and their availability.

Updated Intake Form

Intake form was created through a common component called CHEFS

CHEFS replaced the job posting for the intake on the PSA site, we also shorten the questions that are needed to be filled out by BC Government employees.

Approving new applicants through the dashboard

When a new application get submitted through CHEFS, a Coordinator can approve or decline whether that person meets the criteria to become a CORE Team member.

Coordinators get notified in the email inbox if a new application got submitted; however, this has become burdensome to manage because keeping track of who met the criteria to become a member is being done manually through an excel sheet.

BCWS Dashboard & Member Profile

To keep a complete list of BCWS CORE Team members, active and inactive, and their availability. It’s a database that retains information regarding members such as:

• Availability

• Roles/Functions members are interested in volunteering

• Region/Location

• Member information: Name, Ministry, Union Membership, etc.

The dashboard supplemented the current system that fire regional coordinators are using to keep track of CORE Team members and their availability.

Integrated Intake Form

Intake form was created through a common component called CHEFS.

There used to be two different intake forms and process for BC Government employees to go through to join EMCR and/or BCWS CORE Team programs. This created a confusion for which program to join; simultaneously, BC Gov employees do not see the difference between two programs.

We consolidated the two intake forms into one to create a single entry for both programs. BC Government employees can simply select whether they want to join one or both of the programs into one platform.

This has also helped BCWS to retire an old system that they used for their intake form.

Enablement of notifications to support the 2025 recommitment process

We will enable notifications to prompt the recommitment process for 2025. The start of recommitment is January 20, 2025. Due date to recommit is February 21, 2025.

The system will do the following:

• First automated email will be sent out on January 20, 2025 to notify the current CORE Team members about their recommitment for 2025 and to start to talk to their supervisors about their involvement in the program. Simultaneously, the supervisors will also receive an email about recommitment.

• Second automated email will be sent out on January 27, 2025 for inaction: an email will be sent out to CORE Team members to remind them of recommitment. Simultaneously, if a supervisor hasn’t approved an employee, they will also get a notification.

• Third automated email will be sent out on February 03, 2025 for inaction: an email will be sent out to CORE Team members to remind them of recommitment. Simultaneously, if a supervisor hasn’t approved an employee, they will also get a notification.

• Fourth automated email will be sent out on February 10, 2025 for inaction: an email will be sent out to CORE Team members to remind them of recommitment. Simultaneously, if a supervisor hasn’t approved an employee, they will also get a notification.

• Fifth automated email will be sent out on February 17, 2025 for inaction: an email will be sent out to CORE Team members to remind them of recommitment. Simultaneously, if a supervisor hasn’t approved an employee, they will also get a notification.

• Final automated email will be sent out on February 21, 2025 at 4 pm for inaction: an email will be sent out to CORE Team members to let them know that because they did not recommit, they are now inactive in the system and will not be contacted for future deployments. However, if the member changed their mind, there will be a path forward to be active again in the program. No email to supervisors.

Coordinators send out emails to notify their current members to recommit to the program. In this email, there will be a set of documents and instructions that CORE Team members will need to follow. However, tracking recommitment, including which members has started the process of recommitment, and who needs to be notified again are burdensome to track. Some Coordinators track this in an excel sheet, but following-up has not been consistent.

Additionally, having a set date of when recommitment happens will create more consistency. Both members and Coordinators having clarity on what to expect and when to expect recommitment are key to the experience.

The date for the recommitment was based upon:

a. Being prepared for Freshet.

b. Alignment of learning and training activities that happens after the New Year.

c. For wildfire, having clarity on the number of active CORE Team members earlier on aligns with their resource planning activities before wildfire season hits.

Dashboard for supervisors to approve their employee’s recommitment

Supervisors will be able to log-in to a dashboard where they can see their employees who are members of CORE Team. Supervisors will be able to:

• Approve or decline their employee to recommit for 2025.

• They will be reminded to speak to their employee first if they were to decline their recommitment.

• If a supervisor declines their employee to recommit, they can indicate the reason why and only them and the Coordinators from the BCWS and/or EMCR side will be able to see that reason.

The members are the ones initiating the recommitment process with their supervisors which involved printing recommitment forms, then scanning, saving, and sending them in an email to provide to CORE Team Coordinators from EMCR and BCWS.

Dashboard for CORE Team Members: initiate recommitment, edit member info and availability

CORE Team members can action and start the process of recommitment where they will be prompted to ensure that they have updated their current supervisor and any prerequisites they need to fulfill to meet the criteria for recommitment. CORE Team members will be able to:

• Indicate their interest whether to recommit or not.

• If they have decided not to recommit for 2025, they will be prompted to provide a reason. Only CORE Team Coordinators will have access to this.

• Edit their member information such as phone number, current supervisor, role and function they are interested in volunteering.

• Edit their own schedule, they can indicate their availability for deployment.

Members used to notify their coordinator to update their information and availability, they have to submit it through an email and fill out an excel sheet.

Hence, creating administrative burden for members and coordinators.

Continuously improve the recommitment process - Recommitment re-initiation

Expanding the recommitment process by ensuring that after the recommitment due date, there is a way for Coordinators to re-initiate the process for a CORE Team member who have missed the deadline.

We need to be able to address use cases where a CORE Team member may miss the recommitment deadline and wish to return to the program; so that, we can retain as many members as we could.

Update the calendar feature

Enables the Coordinator to know that members' availability have been recently updated.

For our Release #3, we have introduced a new feature to enable members to update their own calendar:

• Members want to only indicate when they are not available and treat it like an Outlook calendar. Hence, by default, they are showing as available until they mark certain dates for when they are not available.

• Coordinators need to be able to know that members have recently update their schedule because it helps them in planning which members to deploy.

• We currently do not have a system in place to track/mark when a member has recently updated their calendar. Hence, when Coordinators search for available members, the results may include users who have never updated their availability—or potentially never logged in since recommitment.

We are solving for this to ensure that CORE Team members who have not set their availability should continue to appear as blank or some label that indicates unconfirmed, rather than being marked as available. This would ensure that searches for available members only include those who are actively engaged in the program and have intentionally set their availability, rather than mixing in members who have not updated their status.

Enable re-participation of inactive members

Inactive members who wishes to participate in the program and are eligible should be able to recommit to the program.

• "Restart Recommitment" is always enabled except during the recommitment cycle. Could talk about disabling it at the start of the year too before the recommitment cycle starts.

• Active toggle is always available to deactivate or activate a member.

• Restarting recommitment tends to be for people that declined or let their recommitment period pass

There are some CORE Team members in the inactive tab that wishes to come back. It is not clear why they have been inactive and for how long but we need to create a pathway for them to be active again in the program.

• We're only here until March and future development is unknown, product is most likely going into maintenance mode. Hence, if we cater to edge cases without a dedicated team, it would be hard to respond to feedback and changes, when needed.

• Research is not clear. The last research we did with Coordinators didn't show us conclusively on what they wanted to do with inactive folks. Certain triggers for whether they make someone active, inactive, archive is undefined and very based upon the reason why the member and/or supervisor declined. It is so situational and logic for decision-making on what status to put a member varies from coordinators.

• We need to ensure we have flexibility; so that, we empower folks to make those choices. Once a clearer parameters on what different statuses mean have been established, it would be easier to build different logics for edge cases.

Continuously improve the intake process - Build intake form

Pivot away from CHEFS by building our own form to ensure stability, easier maintainability of the application, and improved UX experience for applicants.

Integration of the intake process for attracting new members to creation of member profile and their ability to edit their own information.

We need to focus on further stabilizing the application. With the expansion of the application to introduce the ability of members to log-in to their own profile, and some automation of the intake process, we are discovering that CHEFS is no longer the long-term solution that serves the purpose of the process we need to maintain to ensure efficiency of program delivery.

Developing a custom form for our application instead of using a third-party solution will enhance user experience (UX) for members and coordinators, improve data quality and reliability, and streamline development processes.

Current Limitations with CHEFS:

• Lack of Two-Way Communication: we lack proper two-way communication with CHEFS. Users can resubmit forms after logging in, leading to situations where they receive confirmation emails for applications our system ultimately rejects.

• Asynchronous Data Retrieval: Users with different email addresses in our system can create duplicate entries.

• Guided User Experience: Access to user data before form submission lets us guide users to the right program based on their circumstances. CHEFS can't access private member data before submission, limiting this capability.

Benefits for the members of having our own form:

• Access to Authenticated Data: By integrating data from authenticated endpoints within our system, we can create personalized, dynamic forms tailored to each logged-in user.

• Customized UI Elements: Building our own form enables UI elements that match our existing member profile design seamlessly.

• Two-Way Communication: This feature prevents false submissions and strengthens the application process's reliability.

• Control Over Notifications: We can customize post-submission email notifications with tailored templates and extend them to supervisors, coordinators, and other relevant parties.

• Streamlined Access: Users can access the intake form, member profile, and dashboard through a single URL, simplifying navigation.

• Eligibility Checks: Two-way communication allows users to apply for BCWS if they're in EMCR, and vice versa. This solves the current issue where users can't access the system if they're in one program but not the other. Unlike CHEFS, we can check eligibility before form submission using private member data.

Better Experience For Coordinators:

• Elimination of Duplicate Entries: Two-way communication prevents duplicate submissions, making coordination more efficient.

• Increased Qualified Member Pool: Coordinators gain access to more qualified members, reducing the manual work needed to include members in both programs.

Data Quality, Reliability, and Ease of Development

• Syncing the schema between our database and CHEFS is time-consuming and error-prone. Since CHEFS schema can't be edited through code, we can't implement peer reviews or track changes effectively.

• While CHEFS works well as a no-code or low-code solution for simple cases, our complex requirements demand easy implementation of custom logic. Despite CHEFS offering dynamic data fetching and conditional logic, it can't handle authenticated requests from our private endpoints‚ a crucial requirement for our use case as this enables us to customize the form based on program eligibility, and to prevent false or duplicate submissions. Without a pull request process for reviewing changes to custom logic in CHEFS, errors can occur when moving from development to production. Since we've already developed the backend work and many UX components within our application, switching to a self-hosted solution will significantly improve our capabilities and user experience.

Continuously improve the intake process -Integrating CHIPS data

Reducing the amount of information BC Gov employees need to fill-out in the intake form to become a new CORE Team member.

Currently, although the intake form has removed a lot of unnecessary questions in the intake form, we can further improve this by integrating with CHIPS data.

For example, the current intake form still asks basic information about an individual, such as name, ministry, employee ID, ministry, supervisor, etc. In our research, BC Gov employees were taking a significant amount of time to fill out this info; meanwhile, this same information already exist in CHIPS.

How might we reduce the redundancy of information that they need to fill out to be part of the program?

Hence, reducing friction to volunteer for the program and attract new members.

Export of data for reporting

Enable the export of data from dashboard. Examples of data we need to be able to export from the dashboard:

• Number of active members

• Number of members in a particular ministry

• Number of new members

• Number of excluded vs. BCGEU members

By collecting and showing our data, we are able to learn about how we can continuously improve the program.

Currently, the collection and demonstration of data is very limited and inconsistent. Additionally, we typically hear from decisionmakers the need to have better access to data to support decision-making.