Performance Improvement Plan Template
Four documents and two sheets that check every drafted concern against the record before it goes into the plan.
Free download · No account needed
This pack checks every concern a manager wants to raise in a Performance Improvement Plan against the actual record before any of it is written down. A concern with a dated prior instance, a 1:1 note, an email, a prior review, goes into the plan with its source cited. A concern with no such record does not go in. In the worked example, a manager drafted five concerns for a Support Team Lead. Three had a dated record from the last six months. Two did not.
Two of the five concerns had never appeared in writing before this draft: inconsistent stand-up attendance and resistance to feedback in 1:1s. Neither has a single dated instance in six months of notes or two prior reviews. Both were held out, and the plan issued with the three documented concerns only, 60 percent of what was drafted. A SHRM guide on writing a PIP recommends including dates of prior coaching (SHRM), because a plan without them will not hold up if it is challenged.
The plan then runs on a fixed schedule rather than an informal one. A 60-day plan gets three review dates computed from the length, not chosen by feel: day 20, day 40 and the final review at day 60. Each check-in records a status against every concern independently, because a plan met on three concerns and failed on the fourth is not mostly on track, it is one specific thing still failing. The same evidence habit runs through calibration and review writing: name the thing, or do not write it down.
What is in the pack
Evidence Log
Every drafted concern checked against the record, marked documented or first-mention with its source and date, and a plain yes or no on whether it goes into this plan.
PIP Document
Built only from concerns that survived the Evidence Log, each one citing its source and date, with the actual checkable standard the person is being held to.
Manager Conversation Guide
A script for the delivery conversation, including direct answers to the two questions every employee asks: what exactly is expected, and what happens if it is not met.
Weekly Check-in Format
A short structure completed at every scheduled point regardless of the news, with a status recorded against each concern independently rather than one overall impression.
Milestone Tracker
Review dates computed from the plan length and interval, logged against their due date so a late check-in is recorded as late rather than folded into an informal schedule.
Outcome Note
The final decision with the specific evidence behind it for every concern, and the one observable reason for an extension if the plan is not simply ended.
One rule every prompt reads first
A concern needs a dated prior record or it does not go in, even when the manager is certain it is true and even when it happened yesterday.
How it works
- 1
Send the drafted concerns and the record
The concerns a manager is considering, plus 1:1 notes, prior reviews and anything else documented for at least the last six months.
- 2
Get the Evidence Log
Every concern checked for a dated prior instance, with a plain flag on anything that would be appearing in writing for the first time.
- 3
Draft from what survives
The PIP Document and Conversation Guide, built only from documented concerns, each one citing its source.
- 4
Track the plan to a decision
Check-ins logged against fixed review dates, and a final Outcome Note recording the evidence behind the decision, concern by concern.
Frequently asked questions
What counts as a dated prior record?
A 1:1 note, an email, a documented conversation, a prior review, a ticket, anything written down before today that names the specific concern. A general sense that someone has been struggling is not a record. A note dated 2025-12-03 describing the exact complaint is.
What happens to a concern that gets held out?
It does not disappear. The recommended path is to have the conversation now, document it, and it becomes eligible for the next draft or the next cycle with a real record behind it. Holding a concern out is not a judgment that it is false, only that it has never been raised.
Isn't a manager allowed to just know something is a problem?
Knowing it and being able to show it are different things, and a PIP is the document where that difference matters most. In the worked example two of five concerns were entirely plausible and neither had a single dated instance anywhere in six months of notes, which is what made them unsafe to include.
Why compute the review dates instead of just picking them?
So a milestone logged five days late is recorded as five days late rather than quietly absorbed into an informal schedule. A 60-day plan with reviews at day 20, 40 and 60 gives both sides a fixed date to be measured against from the first conversation.
Can a plan end early if things improve fast?
The pack tracks status at each scheduled check-in rather than assuming a fixed end is the only outcome, so a manager can see and document early improvement. The Outcome Note is where any decision, early or on schedule, gets recorded against the evidence for each concern.
Does a passed PIP mean the person is due for a promotion?
No, and the two are checked separately. A passed PIP means the documented concerns were addressed. Whether someone is overlooked for advancement is a different, tenure-based question a promotion framework checks against the levelling ladder, not against this plan.
How does this connect to the review cycle?
The evidence discipline is the same one a performance cycle applies to a rating: a claim needs something checkable, not a confident sentence. A PIP built from documented concerns is easier to write, because those concerns already read like the observation rows a review draws from.
Find out which of your concerns actually have a record behind them
Send the concerns you are considering and whatever you have on this person's history. The first thing back is the Evidence Log: what is documented, what is not, and what that means for the plan.
Build my Evidence Log