TimeSimplicity & Other Product Ideas

For accrual plans that require employee work a certain amount of time ("vesting period") before they can use any accruals they've earned, SwipeClock accrues the premature earnings as "Unvested Time" that becomes available once the employee completes the vesting period.  Currently there is no way to adjust the balance for Unvested Time, however.  This product idea makes a case for why users should be able to make adjustments to Unvested Time aside from Vested Time.

Consider the following usage case which would necessitate the ability to post Unvested Time:

1. A new client with a TOR policy that includes a 120 day vesting period is onboarding onto the SwipeClock platform for the first time.
2. In order to have the TOR policy function appropriately, any YTD or carryover balances already applicable to the employees need to be entered as an adjustment on the Accrual Balances screen.
3. Some of these employees inevitably will have been employed at the company for less than 120 days, the vesting period.
4. Employees at the company for less than 120 days should only have Unvested Accruals, not Vested Accruals. 
   
   

   Let's say the employee's name is Carl and he has earned 6.87 hours of Unvested PTO.

5. When I post an accrual adjustment of +6.87 hours in Carl's PTO bucket, those hours are immediately vested, but they shouldn't be.
6. It would be helpful if one of the following two scenarios occurred instead:
   1. Less Ideal: I am offered two columns to input Accrual Balances into, one for Vested Time and one for Unvested Time.  This way I can segregate the vested from the unvested hours and not allow an employee to use TOR time prematurely.
   2. More Ideal: The system, based on the TOR script, detects that this plan has a 120 day vesting period, sees the employee I'm posting an adjustment for hasn't been employed for 120 days yet, and then automatically codes my adjustment as Unvested Time.

This seems like an essential component for accurate TOR setups for existing companies and would also make it easier to transition a client from using a different time-off component (e.g. one from their payroll system) to the TOR component in SwipeClock.

Thank you for any and all consideration!