This guide will help your team integrate Cost Recovery Service Management (CRSM) requirements into your Workload Management (WLM) platform. There are checklists to make sure required data points are captured, as well as descriptions of the various features and UI components that are available for you to use.
Minimum requirements for CRSM
This section provides you with checklists that contain all the data points that need to be captured to meet CRSM requirements.
New service requests
When a new service request is submitted by a client or created by a TC employee, the following data must be recorded:
- 3-digit service ID (from SIAPI - Service Inventory API - contains service cost, service standard, and activity IDs associated with that service for time tracking purposes)
- Requestor information:
- First and last name
- Address
- Phone
- Receipt, order, and transaction reference number from COPS (for prepay services)
- Payer information (if different than Requestor):
- First and last name
- Address
- Phone
- Service request ID# from MTOA - the first step of WLM-CRSM integration is having an MTOA ID# generated for each service request in WLM.
The MTOA SR ID# is the core component of WLM-CRSM integration because all the CRSM APIs use this number as a unique identifier for each service request. For more info, view the Technical onboarding page.
Employee touch time
After a service has been delivered all employees that worked on that service request must report the time that they spent on that request and the time must be approved by their manager.
For services that require prepayment or pay-upfront services, the service can be delivered before the manager approves employee time. The recommendation is that managers approve their employees’ time weekly, but the approval frequency is at each managers’ discretion. Before a request can move to the “Closed
For services where the invoice is based on the number of hours an employee spends delivering that service, manager approval of time is required before an invoice can be generated. The manager also must approve the invoice before it is sent to the customer, but these two approvals can be done in a single step if preferred.
The following employee touch time data points must be captured for each service request:
- Employee name
- Total amount of time spent on the service request
- Type of time (regular, overtime 1.5, overtime 2.0)
- Manager approval
Time activities need to exist in the SIAPI first before you can select them since the Activities dropdown list in WLM pulls this data from the SPAPI. You can view the full list of activities here and can also request custom activities if needed.
There are multiple ways you can capture employee touch time.
Manual time entry
The base solution for capturing employee touch time in WLM is to have the user add time entries manually by selecting the activity, date, amount of time, and time type (regular, overtime 1.5, overtime 2.0). The user can then submit to their manager from approval.
Each time entry can be edited or deleted. All time data is stored in the TMAPI (Time Management API) database which is maintained by the CRSM team. TMAPI is also used to send time entries to and from the CRSD Manager app for approvals.
Auto-capture time
One solution you can use to capture employee touch time is the Auto-Capture feature: it calculates the time a user spends in a WLM work item session and automatically creates a time entry for that amount of time for each session. There are business rules currently in place for session timeouts:
After 20 minutes of inactivity, a ‘Session expired’ popup is displayed asking the user if they are still working on the work item
If they respond ‘yes’ the timer continues
If they click ‘No’ or there is no response, the previous 20 minutes of time is removed from the time entry so that inactive time isn’t counted
The 20-minute time limit is customizable by each team and can be set to any value
When the work item status is changed to Complete, a dialogue box appears asking the user to verify their time. The time entries can also be accessed from a Time Entries page within the WLM app, where they can be submitted to a manager for approval.
Each time entry can be edited or deleted. All time data is stored in the TMAPI (Time Management API) database which is maintained by the CRSM team. TMAPI is also used to send time entries to and from the CRSD Manager app for approvals.
Default (suggested) times
Another solution for capturing employee touch time is using the Default Times and Activities feature. This feature ‘suggests’ activities and times based on triggers in the work item such as status changes. For example, if a user changes the status to On Hold, a time entry activity for ‘Additional client communications’ will automatically be created with a time of 10 minutes—this amount of time was determined by the business as the average amount of time required to contact a client and this value can be customized.
Each time entry can be edited or deleted. All time data is stored in the TMAPI (Time Management API) database which is maintained by the CRSM team. TMAPI is also used to send time entries to and from the CRSD Manager app for approvals.
Manager approval
Managers are responsible for approving their employees’ time entries for each service request. If time is rejected, the manager must provide a justification comment. Once a time entry is rejected, the employee can then either edit and resubmit, or delete the time entry. Currently, the manager views time, approves time, and rejects time in the CRSD web application and not the WLM application. Note that currently, the SR# displayed in CRSD is the MTOA ID# and not the WLM ID#.
For CRSM integration, contact Krista Miller and Sherrie Richer with your service ID to make sure your service exists in CRSD DEV, ACC, and PROD (for example, the service ID for MIU is 212). You must also ask them to give the approving manager of your business line the MTOA role permission ‘approve/reject time entries’.
Service performance
Service performance (SP) measures the service delivery speed against the service standard, which is customized for each service. The service performance for a request is determined by calculating the time difference between MTOA status changes, which are mapped to WLM statuses. For customized statuses in your own business line’s workflow, use sub-statuses. For example, if you are waiting for more information from your customer, you can change the WLM status to ‘Waiting for more info’ and this can be mapped to the MTOA status ‘On Hold’ which signals that the service performance clock is PAUSED during this time.
The following image shows 5 Stage Model for SP calculation:
Service Performance is calculated by the SPAPI (Service Performance API) so your service must be set up with MTOA and CRSM – contact Krista Miller and Sherrie Richer to make sure your service is setup for DEV, ACC, and PROD. You can use RDIMS 16701557 as a reference to help you.
The following data must be collected:
- Service performance start date (usually triggered by a status change)
- Service performance end date (usually triggered by a status change)
- Service performance adjustment caused by extraordinary circumstances (if required)
- Justification of extraordinary service performance adjustments (if required)
- Service performance adjustment for delays caused by the applicant/fee payer
- Calculation of service performance (total elapsed time after adjustments)
SPAPI considers statutory holidays and weekends so you don’t have to worry about it.
The current implementation of service performance in WLM includes showing the ‘time before deadline’ which is the amount of time before the service standard is exceeded.
Remissions
If the service performance exceeds the service standard without any justification of extraordinary circumstances, then TC must pay remissions to the client: a percentage of the original fee paid (basically like a partial refund). Low-material fees are not subject to remissions.
Remissions can only be adjusted and/or approved by managers. For adjustments, the manager can adjust the days/hours so that the service performance falls within the service standard and must provide justification for the adjustment. In this case, no remissions are paid.
If the service standard is exceeded and there is no justification for adjusting, the manager approves the remission, and the credit/refund is processed. This happens through interactions between SPAPI and the Oracle Financials API.
Currently, the remission workflow is not yet implemented in WLM and will likely be included in the CRSD Manager app soon.
For more technical information on Service Performance and Remissions, you can refer to this slide desk:
Contact us
For any questions and support for integrating Cost Recovery requirements into your WLM platform, please reach out to us using the MOLE Intake Form.