Rosterfy - Feature Ideas

Currently Rosterfy supports: -Outbound Email (manual & automated, individual & bulk) -Outbound SMS (manual & automated, individual & bulk) -Inbound SMS -Inbound 'Contact Centre' messages, converted to email Not supported is: (1) Inbound Email (2) Outbound Contact Centre message (1) Email responses or notifications of 'Contact Centre' inquiries are sent be email to a mailbox which is hosted outside of Rosterfy. What would be beneficial would be the following features: -Inbound Email from Volunteer is associated to Customer record -Inbound Email from Volunteer is routed to an appropriate Queue based on configurable rulesets -Emails can be sent on an ad-hoc basis or in response to an email sent from Lifeline -Emails are threaded -Responses to Volunteer can be manual (based on manual selection from a queue) or automated (based on rules) This would enable a 1:1 communication experience as well as a single source of truth for Contact History (and replace the need to use another Ticketing system or Mailbox for some of the comms). (2) An alternative (or addition) to #1 would be the ability to respond to Volunteer Contact Centre messages through the application. I.e. an asynchronous messaging-based approach to keep all communications within the Rosterfy platform.

For our events, we have Captains for specific roles each captain is sent a roster report that shows them who is working their shifts. The current process is Build the Report > Download Report > Create Email for Report > Send out Report If there is just a way to send reports from the Reports page that would help save a lot of time and steps.

Each automation should have a record of its runs, including which steps failed and which succeeded. It would also be nice to receive notifications of any failures.

When selecting a template to send out to the volunteers some time there are certain changes that need to be made to the templates. If there was a feature where you are able to edit the body of the email after selecting the template. Would help minimize steps because then we would have to create a new template to send out. It would just make it less steps.

Can a filter be added for the user profile to include Mandatory & optional for training courses.

Create automation tasks such as 'Event - Demand met' or 'Role Offer - 80% demand reached', so that administrators can be emailed or notified, or, even better if a new type of action like 'Unpublish role offer' can be implemented. This would be so helpful for staff at any organisation to keep track where they experience high volumes of applications to lots of different roles in certain periods, and would minimise the risk of frustration to potential applicants.

Regularly some of our volunteers aren't required to complete/pass certain training modules assigned to a role offer they're volunteering in. This can be due to things like support needs the individual may have, which staff who manage that volunteer are aware of. It often means the volunteer doesn't perform a certain part of the role during their volunteering, e.g. operating a cash register in a shop. When moving to Rosterfy we have lost the ability to mark user training records with an 'Exempt' status, meaning: our overall reporting on training is wrong the volunteer and staff members looking at a volunteer's record may interpret an 'incomplete' or 'complete' status incorrectly, leading to confusion. I'm aware of other charities that will also require the ability to mark user training with an 'Exempt' status as part of their inclusive volunteering offer.

If an admin wants to manage incoming communications within Rosterfy - the Contact Centre list doesn't show if a communication is outstanding.

Any of your clients who are moving from one volunteering system to using Rosterfy will want to import their existing volunteers and their current role offers into the site, they will not ask these volunteers to reapply for roles they already have. Depending on the size and resources of the organisation they may want to take a phased approach to this. Clients may want to manage importing their own data, in which case they need to be careful that journey or standalone automation actions don't run which could unduly email the group being imported (e.g. when adding them to a role offer to thank them for applying, when updating the status of the role offer user to complete to congratulate them for completing the journey). The simplest way to avoid this from happening is to remove the email address field from the user import, and use user ID for subsequent imports like role offers and training, then import update the email addresses using the user IDs once all other data is in Rosterfy. This is preferable to disabling automations, as in our case we've had a phased launch, where different departments of volunteers are launched at different points in time. Therefore disabling automations could impact any pre-existing Rosterfy users and their current journeys. When trying to import email addresses to user accounts Rosterfy returns an error - I'd like to be able to import email addresses using the user ID.

It would be cool for Group Leaders to be able to see a calendar with all of the shifts/events they are listed on, all together in one place. Especially if they could click on a shift/event and see the description, who else is assigned to that shift, and the demand. Similar to when an admin looks at shifts in the weekly calendar view on the backend. Also if they could click on a user's name and pull up their little profile box with all the attributes that are visible to them, that would be super useful!

In organisations with larger and more complex volunteering offers: admin users in one department (e.g. Fundraising) shouldn't be able to process volunteer applications made to another department (e.g. Retail). admin users in one location (e.g. Birmingham) shouldn't be able to process volunteer applications made to another location (e.g Edinburgh). However, since each volunteer has a single user account that they should use for all their applications to roles over time, admins should be able to see the application history for that volunteer, even if made to other departments/locations. Please can the permission roles be built out to allow for admins to have visibility (read-only access) to role offer user records on a user's profile only, irrespective of the department/tole description/location/venue? This would strike an excellent balance as admins would have visibility of a user's entire volunteering history, without completely opening up permissions so that admins having to set up and run lots of advanced finds each time they use Rosterfy so that they're only presented with applications they're supposed to process, which also runs the risk of mis-processing.

It would be useful if web links could be restricted by additional criteria beyond just the user checkpoint, e.g. visible to those in certain groups or on certain role offers.

Subsequent updates to criteria and actions within journey steps should update the existing role offers associated with that journey and the role offer users, provided the applicant hasn't yet reached the step with the updated journey elements. Not having this flexibility really limits us if we have volunteering roles (e.g. for our shops) that evolve over time, as many charities do when there are updates to their internal policies/ strategy, and/or external legislation. For example we may start allowing young people to volunteer in shops, which will require a parental consent form to be added to the shops journey. We don't want to have to create a new journey, replicate existing roles pointing to that journey (which would break any existing shared links to a specific role), then move the existing role offer users to the new role offers, then delete the previous journey and role offer (which would presumably break any links shared to those role offers). Nor do we want to have to create automations that sit outside the journey (which we have unfortunately had to do already), as then the applicant user won't see the criteria in the step in their portal, and admin users cannot see the completion of the action when they review the role offer application, and our internal sys admin has to check both the journey and the automations list to fix issues etc.

It would be ideal if the name (portal) field in a job title record could be changed when a user adds a new role offer that links to back that job title. This might mean moving the portal name field to the role offer entity instead of having it on the job title. A lot of large charities need this flexibility. Example scenario: An 'Interpreter Volunteer' job title exists, but in reality we want to be able to give role offers a more specific and meaningful name e.g. 'Romanian Interpreter Volunteer'. For reporting purposes, we want to report on all 'Interpreter volunteer' roles collectively so allowing us to change the portal name, whilst still linking back to the single job title, is preferable. We don't want to have to import and manage an endless list of job title records, especially as we don't have access to 'Create' or 'Copy' functions for job titles.

Other charities also need this functionality in order to attract volunteers. We'd like to be able to create a custom field like a one-liner about a role, and have this display instead of the full address, or the 'applications are open/closed' notice for example.