Service Milestones Are The Easiest Win And The Most Often Botched

Every other earning mechanism depends on somebody doing something. A manager has to notice. A peer has to bother. A claim has to be approved.

Service milestones depend on nothing except a date in a file, which makes them the only part of a rewards program that runs itself. They are also, consistently, the part that generates the most complaints.

The First-Year Problem

Most milestone schedules start at one year. In a workforce with high turnover, that means a large share of staff will never reach the first milestone, and the ones who do have already made their stay-or-go decision months earlier.

If retention through the first year is the thing you care about, the schedule needs a rung before twelve months. Three months and six months cost very little and land at the two points where people are actually deciding.

The front-loaded version costs perhaps fifteen dollars more per person over the first year and reaches everyone rather than only the survivors.

Timing Beats Value

A milestone that arrives three weeks late is worse than a smaller one that arrives on the day. Late says the date was looked up rather than known, which is exactly the impression the milestone was meant to counter.

An anniversary reward that arrives in the next monthly batch is not an anniversary reward. It is a monthly batch.

Automate it against the start date and let it fire on the day. If your start-date data is not good enough for that, fixing the data is the project — not adjusting the schedule to accommodate bad data.

Backdating At Launch

This is the decision most often made badly, usually because it is made late.

When a program goes live, everyone already has tenure. A five-year employee sees a one-year employee receive a milestone next month and gets nothing until their next anniversary, which might be eleven months away.

Three options, in order of how well they work:

1. Grant the current tenure band at launch. Everyone receives the milestone matching their existing service. Most expensive, and by a distance the best received — it reads as the program acknowledging that people were here before it existed.
2. Grant a flat launch bonus to everyone. Cheaper, simpler, and does not differentiate. Fine, but it is a launch gift, not recognition of service.
3. Start from zero and say so clearly. Acceptable if it is communicated before launch rather than discovered afterwards. Unacceptable if people find out by watching a newer colleague get something they did not.

Say What It Is For

Points arriving with no message attached are just points. The milestone should carry a line that names the length of service and, ideally, comes from a person rather than the system.

The difference between "Milestone reward: 2,000 points" and "Three years today — thanks for sticking with us through the Cannington move" is the entire value of the exercise.

Part-Time And Casual Staff

Service is service. A casual who has been on the roster for four years has been there four years, and pro-rating a milestone by average hours is a fast way to make a long-serving casual feel like a lesser employee.

Use elapsed time from the start date for everyone. It is simpler to explain, simpler to configure, and it is the version people consider fair.

A Short Checklist

• Is there a rung before twelve months?
• Does it fire on the day, automatically?
• Have you decided the backdating question, in writing, before launch?
• Does the notification say what the milestone is for?
• Are casual and part-time staff on the same basis as everyone else?
• Is the start-date field in your team file actually reliable?

That last one is the sleeper. In roughly half the implementations we run, the start-date column turns out to contain the date the record was created in the current HR system, not the date the person started. It is worth checking before the first milestone fires and somebody's twelve years quietly becomes eighteen months.