Recognition is the thing intranets are asked for most often and support least well. Someone does something good, a manager sends a private email, and nobody else ever knows. SharePoint Online has no recognition or kudos web part, so most organisations improvise - and the improvisation is usually the reason recognition quietly stops after a month. This guide covers what people try natively, where each approach breaks down, and how to put a proper recognition wall on a page.
What people improvise with
- A news post per shout-out - looks right for a week, then floods the news feed and buries actual company announcements.
- A "Kudos" list with the native List web part - stores the data fine, renders as rows of grey text nobody reads, and the form asks people to fill in fields rather than say thank you.
- A Teams channel - genuinely works for the team in it, and is invisible to everyone else. Recognition that only reaches people who already saw it happen is not recognition.
- Viva Engage praise - a real feature, and a good one, but it lives in Engage rather than on the intranet page people actually open, and it needs Engage adopted first.
Where the native approaches break down
- Effort per thank-you. If recognising someone takes more than about ten seconds, it competes with real work and loses. A list form with six required fields kills the behaviour it is meant to encourage.
- Nothing is scannable. A wall of identical rows tells you nothing at a glance. Without colour, photos or structure, nobody browses it - and a recognition wall nobody browses has no audience, which is the entire point.
- Permissions get in the way. A list where everyone can add items is also, by default, a list where anyone can edit anyone else's. Get that wrong and you either lock the list down so hard nobody can post, or leave it open enough that a like counter can be overwritten.
- It goes stale invisibly. Nothing prompts the next cheer. Birthdays, work anniversaries and milestones pass unmarked because nobody remembered to check a list.
The supported way: a recognition web part that reads and writes as the user
The right approach is a SharePoint Framework (SPFx) web part that stores recognition in ordinary SharePoint lists on your own site and renders them as a designed wall - reading and writing client-side as the signed-in user, so SharePoint's own item-level security decides who can change what.
This is what Glow Cloud Kit Cheers does. Giving a cheer is four choices - colleague, badge, why, optional photo - and the wall renders it as a colour-coded card, with the newest recognition taking a full-width spotlight. Likes and comments live in their own lists, so one person's like is one row that nobody else can overwrite. Birthdays and work anniversaries surface from the same opt-in celebrations list the Directory uses, each with a one-click prefilled cheer. It uses no Microsoft Graph permissions at all, so there is nothing for an admin to consent to.
A checklist for recognition that lasts past month one
- Make giving a cheer take seconds, not a form. Every required field costs you posts.
- Put the wall where people already go - the homepage or a landing page - not on a page they must remember to visit.
- Use badges that match your actual values, not generic ones. "Lived our safety value" beats "Great job".
- Check the permissions properly: everyone able to post, nobody able to edit anyone else's post.
- Give it a prompt. Birthdays, anniversaries and milestones surfaced automatically are what keep a wall alive between spontaneous posts.
- Let leaders be seen using it. A recognition wall with only HR posting reads as a policy, not a culture.
Related
- Glow Cloud Kit Cheers - the product overview.
- Cheers setup guide - install and configuration steps.
- How to build a staff directory in SharePoint.