Absence Management Data Conundrum: History or “Clean Slate” with New Vendor?
By Ashley Chodorowski, MBA
Sr. Business Consultant
You have spent months looking for a vendor to help you administer your absence program, and you finally found the one! Regardless of whether you choose to outsource all absence services or use a third-party software solution, you will be faced with a conundrum: do you load up historical leaves, or do you start fresh with a clean slate?
Before we dive into the details, let’s answer some common concerns when changing vendors. Either the new vendor can take over all claims or the old vendor can administer the “runoff” of remaining closed leaves until all associated compliance tasks are fulfilled. The new vendor may charge to take over those old claims, making implementation costs higher. Or if the old vendor retains the old claims, they may have some motivation to charge reasonably as contracts in the industry are not typically long-term, and returning to a former vendor is quite common.
In general, for a smooth transition, you want to move as much as possible to the new vendor. If you have an old vendor administering the runoff, encourage coordination between vendors; don’t allow a vendor change to inconvenience your employees.
Because loading historical leaves is so much more complex than starting fresh with a clean slate, we will devote most of our time to the former. In the vendor transfer process, loading all historical leaves into your new system has challenges and potentially hefty fees. Your new vendor should provide you a document that details the required fields and preferred layout that is needed to successfully load historical leaves. Most systems will need to know the reason for the leave, relationship of the family member, status of the leave, and start and end dates. You may also see eligibility elements needed for federal and state entitlement such as hours worked in the last 12 months, length of service, or work state.
With the data layout document in hand, you need to do a thorough analysis and identify any gaps your data may have.
Common Gaps or Data Conversion Pitfalls
Some units of your organization may have been very consistent and thorough when tracking leave requests and activity, while others were erratic and inconsistent.
An organization must include all leaves for all employees who are similarly situated. When certain employee populations are excluded, it is imperative that similarly situated employees are treated equitably. For example, a retailer requested to include the first shift and exclude the second shift of a department, since the second shift supervisor did not consistently record or track absences. We strongly advised against this because all employees in the department were non-exempt/hourly, and this would not have been equitable treatment.
For intermittent leaves, data on each individual absence is missing or tracked inconsistently.
Inconsistent intermittent absence records are quite common. For example, a large manufacturer had a call center with over 500 employees. However, they only had Family and Medical Leave Act (FMLA) intermittent absence records for eight employees. Why so few? They said they decided to only track intermittent absences for the employees whom they thought were abusing the absence policy.
This employer also could not produce any proof that proper FMLA notices were given to the eight employees they were tracking. It was clear that standard procedure was not being consistently followed in collecting, tracking, and communicating the absences for all employees. This leave data was not a good candidate to load for historical purposes because it was not all-inclusive, consistent, or defensible.
Some key data elements are missing.
Usually eligibility data such as hours worked in the last 12 months or months of service comes from a human resources (HR) system, which is typically a different data source than leave data. So providing eligibility data may require extracting data from another system. To avoid this difficulty, some employers simply enter a default value for certain data elements.
For example, a large retailer was missing family care relationships on some leaves and decided to default missing relationships to “parent.” This was confusing for leave specialists in the system who could not accurately answer questions regarding the relationship on some family care absences. Many employees saw the defaulted data on the self-service portal and phoned the call center with this concern, so the call center experienced higher- than-normal call volumes, which led to longer hold times and a less enjoyable employee experience.
Data must be formatted in the layout specified by the vendor.
By following the vendor’s preferred data layout for submitting historic data, you increase your chances of more accurate mapping and thus having better data quality. Occasionally, it is not possible to follow the vendor’s preferred data format. It is important to discuss this issue and understand if your new vendor can be flexible.
Most vendors will accept an extract that provides the required data elements. However since it is not in the preferred layout, converting historic data will require more time, and you will likely have to provide a data dictionary along with the extract that the vendor will use for data mapping. For example, a large healthcare employer was unable to provide data in the new vendor’s preferred format. The current vendor charged a six-figure fee to extract leave data in the new vendor’s layout. This was a large unforeseen expense for the employer, and it resulted in negative feelings that affected the transfer process.
Assess Impact of Gaps
Additionally, for the gaps in historic data that you identified, you will need to analyze their impact on the leave data system, eligibility, and entitlements. Your new vendor should be able to help answer questions regarding the severity of impacts. If you determine that certain employee populations are missing or the data is unreliable for specific groups, you should discuss the matter with your corporate counsel. If you are making exclusion decisions, it is imperative that similarly situated employees are treated equitably.
Is loading historical leaves into your new system a viable option for your organization? Here is a checklist. If you can answer “yes” to each of these, then it may be:
- Data includes all leaves for all employees who are similarly situated.
- All required leave data fields specified by the vendor are available and reliable.
- Leave decisions are defensible, and there is proof that the employees received proper notice.
- Leave data can be provided in a format that is amenable with the new vendor.
- Leave data can be extracted without an excessive burden to your resources or budget.
Finally, you will need to make a decision. Will you proceed with loading historical data, or will you take a clean slate approach? Loading historical data is the more popular approach. The mere suggestion of a clean slate approach is often met with the same scowl as paper cuts!
No employer finds it easy to admit that their leave data may be unreliable or indefensible. Employers also fear that a clean slate approach could lead to a higher incidence of absence, as absence abusers hear about the clean slate approach and become even more emboldened. There is some evidence to support concerns about increased absence cost. This potential cost may be offset by avoidance of litigation and non-compliance fees that are more likely when historical data is loaded into the new system. Both costs are virtually impossible to quantify. One or two adverse legal opinions from loading historical data could easily offset any loss from increased absence under a clean slate approach.
Figure 1: Comparing Approaches for Transition to a New Absence Vendor
The fear of being perceived as “going soft” on absenteeism in the clean slate approach has driven some bad data conversion decisions that have irrevocable consequences. I have never heard an employer regret their clean slate decision. However, I have witnessed many employers and operational teams suffer for months to recover from a bad data conversion. Sometimes letting go of the past and starting over is the best thing, especially if you have doubts about the quality of your historic data.