Performance

How to Document Employee Performance Issues

NBy the Notivo Team · Updated June 2026

Before a performance conversation or a PIP, you need a dated trail of concrete examples and the conversations you already had. Here is how to keep one fairly: behavior not character, captured the day it happens, organized per person.

To document an employee performance issue, write down what happened the same day, while it is fresh, and record four things for each entry: the date, the specific behavior you observed, the impact, and any conversation you already had about it. Keep the entries in one place per person so the pattern is easy to see later. The whole point is a dated, factual record of concrete examples, not a memory you reconstruct under pressure the week a performance improvement plan is due. Describe what people did, not what kind of person they are, and you end up with notes that are fair, accurate, and far harder to dispute.

Most managers wait too long to start. The concern shows up in March, a few more instances land in April, and by the time it is serious in June the early details have gone soft: which dates, what exactly was said, whether it was ever raised. Reconstructed-from-memory documentation is where bias and unfairness creep in, because memory favors what is recent and what fits the story you have already started to tell. A running, dated record fixes that. It does not make you tougher on people. It makes you accurate, which is what fair requires.

The four things to capture for each instance

You do not need a complicated system. For every instance, capture the same four things, dated and specific. Copy the layout below and keep one of these per person you are tracking a concern on.

Copy the performance issue log

PERFORMANCE ISSUE LOG - @[Name]

EXPECTATION (what good looks like for this role / goal)
-

INSTANCES (each one dated, specific, behavior + impact)
- [Date] - What happened (observed, factual) - Impact -
- [Date] - What happened (observed, factual) - Impact -
- [Date] - What happened (observed, factual) - Impact -

CONVERSATIONS ALREADY HAD (so it is not a surprise)
- [Date] - Raised in 1:1. What I said. What we agreed. -
- [Date] - Followed up. Response / change since. -

CONTEXT / MITIGATING FACTS (be fair to the person)
-

PATTERN OR ONE-OFF? (what the dated record actually shows)
-

Here is what each field looks like once it has real entries in it. Specific and dated beats tidy and vague every time.

The expectation. "On-call runbooks updated within a week of any incident; this is in the role’s goals." You cannot document a gap fairly until you have written down what good looks like, in plain terms the person has heard before.
The instance, dated and observed. "Mar 9: shipped the billing change without the migration note; two teammates lost an afternoon tracing the behavior." A date, what happened, and the impact. No adjectives about the person.
The prior conversation. "Mar 12 1:1: raised the missing note, agreed change notes go in the PR template. Apr 2: happened again; reminded." This is the part most documentation is missing, and the part that makes a later PIP land as a fair next step rather than an ambush.
The context. "Apr was the on-call rotation plus the platform migration; workload was genuinely heavy." Recording the mitigating facts is not going soft. It is what keeps the record honest and keeps you from documenting a season as a verdict.
Pattern or one-off. "Three instances across Q2, all the same root cause: skipping the change-note step under time pressure." The dated record is what lets you say which it is, instead of guessing.

Per person, not per page

See what a private, per-person timeline looks like for a whole team.

See manager notes

Write behavior, not character

The single rule that keeps performance documentation fair and useful is this: record what the person did, not what kind of person you think they are. "Difficult," "lazy," "not a team player," "has a bad attitude" are verdicts, not observations. They are unfair, they are not coachable, and they are exactly the kind of thing you would never want written down about yourself by someone who was annoyed that week.

So translate every label back into the behavior and impact that made you reach for it.

Not "unreliable." Write "missed three of five committed dates in Q2, all from late scoping." That is something you observed and can coach on.
Not "bad attitude in meetings." Write "interrupted two colleagues in the Apr 14 review and the room went quiet; we talked about it after." Specific, dated, and about an action.
Not "doesn’t care about quality." Write "shipped without the change note on Mar 9 and Apr 2 after we agreed it goes in the PR template." A behavior, twice, with a prior agreement on the record.

Record only what you observed yourself or what was directly reported to you, and note which is which. Secondhand impressions and "people are saying" do not belong in a record you may one day stand behind. If you did not see it, do not write it as fact.

What to write down before a PIP

A performance improvement plan should never be the first time the person hears the concern. The documentation you want in hand before you get there has two halves: the instances, and the conversations.

The instances: the specific, dated examples, each with the behavior, the impact, and what the expectation was. Three concrete entries beat a page of "consistently underperforms."
The conversations: when and how you already raised it, what you agreed, and what changed (or did not) afterward. This is the trail that shows the person had a fair chance to course-correct before the plan.

When both halves are present and dated, a PIP reads as a clear, fair next step backed by a record, instead of a surprise assembled from a vague memory. It also protects the person: if the issue really has been raised and supported, the documentation shows that too. And it protects you, because "we talked about this on Mar 12 and again on Apr 2" is a very different position than "I’m pretty sure I mentioned it once."

Captured the day it happens

Jot one dated line after the meeting and let it file itself by person.

Start free

Common mistakes that make documentation useless

Most weak performance documentation fails for one of these reasons. None of them are about how serious the issue is.

Reconstructing it at the end. Notes written the week the PIP is due are vague on dates and shaped by how you already feel. Capture each instance the day it happens or the detail is gone.
Character labels instead of behavior. "Lazy" and "difficult" cannot be coached, cannot be disputed fairly, and read as bias. Always write the action and the impact.
No record of the conversations. Instances without the talks you already had make any next step look like an ambush. Log when you raised it and what you agreed.
Only logging problems. A file that is nothing but misses becomes a grievance log and loses credibility. Note the context and the things that went well too; a fair record cuts both ways.
Treating the notes as the decision. Documentation informs your judgment and your organization’s process. It does not make the call. Keep that line and the record stays a tool instead of a weapon.

Why a per-person notebook is the low-friction way

The hard part of all this is not knowing what to write. It is capturing it consistently, in one place, the day it happens. That is exactly what Notivo is built to make effortless: a private, per-person running log you actually keep up with.

You write a quick note, "Mar 9, @Sam shipped the billing change without the migration note, cost two teammates an afternoon, raising at next 1:1," and tag the person with @ and their name. It files into that person’s timeline. Type @Sam later and the whole dated history is there, searchable, so before a performance conversation or a PIP you read the trail top to bottom instead of reconstructing it. You can capture from the web, from WhatsApp on the way out of a meeting, or from the ChatGPT and Claude connectors. An AI assistant can draft a recap or answer a question from your own notes only; it never trains on your data, so it surfaces what you already wrote rather than inventing anything. For the most sensitive entries, a PIN-locked Black Box vault (tagged @bb or #bb) is end-to-end encrypted, with the standard tradeoff that losing the key means losing the contents.

On storage, the honest answer: your regular notes are private by default and scoped to your own account, and they are stored on secured infrastructure. That is platform-level security, the protections that come with reputable cloud storage. It is not a claim that your note content is encrypted end-to-end (only the Black Box vault is) and we are not going to pretend otherwise. So use the same judgment you would use with any cloud notes app: this is the right home for your working record of who did what, and not the place for the most sensitive personal data you would never put in any cloud tool.

A fair, dated record

Walk into a hard conversation with specific examples, not a vague impression.

Start free

Frequently asked questions

How do you document an employee performance issue?

Write down what happened the same day, while it is fresh. For each entry, record the date, the specific behavior you observed, the impact, and any conversation you already had about it. Stick to facts you witnessed, describe behavior rather than character, and keep the entries in one place per person so the pattern is easy to see later.

What should I write down before starting a PIP?

A dated trail of concrete examples and the conversations you already had. List the specific instances with dates, the impact of each, what was expected, and when and how you raised the issue before. A performance improvement plan lands fairly when the person has heard the concern before and there is a clear record, rather than a surprise built from a vague memory.

Are a manager’s performance notes an official HR record?

No. Your own notes are a personal memory aid for your recall, not your organization’s system of record. They do not make decisions, set anyone’s rating, or replace your HR process. If something belongs in an official file, enter it through the proper channel. Notes inform your judgment; they are not HR or legal advice.

How do I document performance issues without it sounding biased?

Record behavior and impact, not character labels. Write “missed three of five committed dates in Q2, all from late scoping” rather than “unreliable.” Note only what you observed or what was directly reported to you, date every entry, and include context and any mitigating facts. Specific, dated, behavior-based notes are harder to dispute and fairer to the person.

Where are the notes stored?

On secured infrastructure, private by default and scoped to your own account. This is platform-level security. Notivo does not claim that your note content is encrypted end-to-end, so use the same judgment you would use with any cloud notes app.

How far back should performance documentation go?

Far enough to show whether the issue is a pattern or a one-off, which usually means the current review period and the weeks around when the concern began. Capture entries as they happen rather than reconstructing them at the end, so the dates are accurate. A per-person timeline you add to over time gives you that history without a separate filing effort.