360 feedback request email

Who should send the request

There are two common setups, and the right email depends on which one you run.

HR-run 360s are typical when feedback feeds formal development plans or leadership programs. HR sends the request, owns the anonymity promise and collects the responses. This gives raters the most confidence that their answers stay private.

Employee-run feedback requests are lighter and more common in teams that want frequent, informal feedback. The employee asks four to eight people they actually work with. Response rates are usually higher because the ask is personal, but answers tend to be kinder and less specific.

Managers asking their own direct reports for upward feedback should always route it through HR or an anonymous form tool. A request that says "tell me what you really think" with no anonymity gets polite non-answers.

Say exactly who will see the feedback

Raters' first question is always "will they know it was me?" Answer it in the email, and only promise what your process can actually deliver.

• Set a minimum number of raters per group (three is the usual floor) before results are shown. With one direct report, anonymity is impossible; say so, or fold that group into another.
• Tell raters that written comments are shown as typed, since writing style can identify people.
• Say whether the feedback affects ratings or pay. Feedback used purely for development tends to be more candid. If it also feeds pay decisions, say that up front, because finding out later destroys trust in the next cycle.

For more background on design choices, see the glossary entry on 360-degree feedback, and use our 360 feedback form as a starting questionnaire.

Keep the request load reasonable

Feedback fatigue is the biggest practical problem. In a company running 360s for every manager at once, a well-liked team lead can receive fifteen requests in one week, and the last ten get rushed or ignored. Cap requests per rater (five to six per cycle is a common limit), stagger 360s across quarters if you can, and avoid running them in the same week as self-evaluations. If people are already working through a self-evaluation reminder email, a pile of peer requests on top will hurt both.

For frontline teams such as contact center supervisors, short is better: six to ten questions, mostly ratings, with two open text questions such as "What should this person keep doing?" and "What one thing should they change?"

Prompts that produce useful comments

Generic requests produce generic feedback ("great team player"). Give raters a nudge toward specifics in the email itself: ask them to describe a situation they saw, what the person did and what effect it had. If the employee has a focus area, such as running calibration sessions or coaching new agents, name it. Raters who know what kind of feedback is wanted write two useful sentences instead of five vague ones.

Timing and follow-up

Send requests two to three weeks ahead of the performance review invitation email so the summary is ready before review meetings. A 7 to 10 day window works; longer windows just delay responses. One reminder is enough, and it should go only to non-responders. Close the loop afterwards: managers who share what they heard and what they'll change get noticeably better participation next cycle.

Mistakes to avoid

• Promising anonymity you can't keep, such as with groups of one or two raters.
• Letting employees pick only friends. Have the manager review and add names.
• Long forms. Over 15 minutes and completion drops sharply.
• No deadline, or a deadline after the review meeting.
• Sharing raw results without a debrief. Unfiltered criticism with no coaching conversation does more harm than good.