RosterApps Shift Leveling Bids - Part 2

(Please refer to the Part 1 article before reviewing this information)

Exchanging for Open Shift Type Shift Leveling Bids

The other type of Shift Leveling Bid is the ‘Exchanging for Open Shift’. This is the type where the employee user will exchange a shift currently on their calendar for an Open Shift bid item, but only if that exchanged shift is in an overstaffed position, according to the relevant Minimum Staffing Plan.
When you go to set up the Exchange type of Shift Leveling Bid, you will note a slight difference to the interface where you specify the settings for the bid:


These settings control and reference the shifts from the Employee’s calendar being exchanged. You can limit the window of time that shifts being exchanged must fall within, as well as requiring the shift duration be identical traded-in shift / Open Shift, as well as where or not the Skill listed for the shifts must be the same and whether or not the shifts need to be in the same calendar week as specified for the Location in question.
Keep in mind that Date Range of Shifts to Exchange settings will directly impact which Minimum Staffing Plan is used for determination of Overstaffed positions. This might be different than the date range of the Open Shifts themselves, if you so configure it.
 
The minimum staffing plan relevant for our example bid looks like this:

 
So, any exchanged shift would need to be from a date/timeframe where there were more users on-duty than the minimums shown above for the day and time indicated.
Note: the entire time frame for the overage must be allowed for. If the timeframes on the minimum staffing plan don’t match up with relevant shift start/stop times, then RosterApps won’t allow that particular shift to be exchanged in the Shift Leveling Bid.
RosterApps will also enforce any override dates, should they come into play from an Employee user who wants to exchange a shift on such an override date.
When the Employee User goes in to conduct their Shift Leveling Bid, they will see a screen similar to the following, allowing them to choose Bid Items, and the shift(s) they want to exchange:


If the employee user doesn’t check the checkbox so indicated, they will have choices from any shift in an overstaffed position, that might be in a timeframe ineligible for exchange in this Shift Leveling Bid. Even if they select such shift(s), they won’t be able to exchange them as they might want.
As the bid participants make their way through their bids, their results will be visible in the ‘Select Participants’ link, on which page you will be able to see the preferences submitted by users as they complete their bids:

Once your users have completed their bids, and the bidding window closes, you can run the award, and either Unaward the results, or Approve and Finalize when you are ready. If you have made any changes since the start of the Shift Leveling Bid, it is best practice to Unaward all, and run the award from the beginning. There are some RosterApps users who conduct such bids in increments, where they keep previous awards in place. The choice is up to you, but the fairest way to run the award is to give all employees the same chance as their co-workers.

You can run the awards process as many times as you like, and then Unaward all at the end of your testing. If the results look good, you can Approve and Finalize the bid awards. That page appears as follows:

Other Considerations and Notes

The inclusion of shifts from multiple work groups is allowable under the Shift Leveling Bid functionality, but unwinding problems in such situations can be problematic. For example, if you have multiple work groups represented in bid items (shifts), and multiple work groups worth of employee users included, the work group trade rights of those individual employee users will vary one to the next. Some of those users will have visibility into most or all of the shifts in the Shift Leveling bid, and others may have very limited visibility into the majority of the bid items. This would all be attributable to Work Group Trade Rights of the individual users. If the skill of the relevant bid item isn’t one that the given employee user has, then they will not be able to claim that bid item.

Additionally, there can be questions from time to time about why one bid item was awarded to a given employee and not another. The ‘Shift Leveling Bid History’ link provides a history of the bid, and individuals’ choices, and critically, why a given bid item was not awarded to a given employee if that was one of their listed choices. Running down results like this by hand can be done, but can be time consuming.

Lastly, the Run Awards process can be done as often as the user wants, and the results of those award runs can be undone each time before another run is made. Additionally, a client may want to run such a bid in stages, and *KEEP* the awards between each run. This is totally acceptable, but might not be fair to all participants, if that is a consideration.