This post has been republished via RSS; it originally appeared at: Yammer Blog articles.
If you’ve been following humanity’s journey with digital technology, you’ll be well aware that social platforms have evolved to places of moderation. And by “moderation”, I mean a place where an individual’s contributions are subject to review. Somewhat ironically, that’s required because of a lack of “moderation” of the beige, uncontroversial kind.
With very good reason, we’ve come to expect the ability to moderate conversations on technology platforms. That could be in a number of different ways, from proactive keyword monitoring to requiring trusted administrators to manually approve posts before they become public, to the ability of users to flag inappropriate content.
Yammer has none of this. People sign up to accounts, and while your company might have a usage policy, the platform only includes some very basic moderation functionality. People who spend their time managing Yammer communities understand why that’s acceptable (hint: it’s not a public, anonymous platform). However, sometimes it’s just a "requirement". In other words, it’s a deal-breaker for Yammer if it doesn’t have that feature. The easiest way to turn on Yammer is to comply with the policy, not have an argument about whether it’s applicable.
At Adopt & Embrace, we’ve been secretly building a Report Post tool for our customers. It’s an escape valve for community management – part of a broader moderation toolset to be used on the rare occasions when someone hasn’t respected your network’s Usage Policy, not to mention deviated from the cultural norms that define what a professional interaction looks like at your company. It’s an interesting request, because generally the conversation goes something like this:
A&E: Why would you want to a Report Post?
Customer: Just in case anyone notices something that isn’t consistent with our Usage Policy
A&E: Are you expecting that to happen?
Customer: No, but just in case.
A&E: What do you want to do with the post?
Customer: We’ll investigate and delete if it’s against the Usage Policy
The motivation comes from a place of discussion boards and anonymity. At its very core, I don’t agree with the fundamental assumptions that underpin the concern. It requires believing that someone in your company will knowingly post something offensive. It requires believing that the behaviour won’t be publicly called out. It requires believing that the author will continue to assert their right to post that content, rather than choose to delete it themselves. It requires believing that your company still really wants to employ that person.
This isn’t Twitter where snarky comments allow the thrill of infamy. You have to work with these people. Those people create your organisational culture. If someone posts something that’s truly offensive, it’s not just a matter for the community manager – you’re going to have to get HR and perhaps even legal involved.
But for whatever reason we were asked to create an escape valve, so we built one. The more interesting part is that we wanted to do it in a way that was easily replicated by other customers. No bespoke code, nothing to “install”. To do this we used Forms, Flow, SharePoint, and … Yammer.
Forms
We built the reporting page in Forms because it has a clean, modern-looking interface. It’s here where the rubber hits the road for very important design decisions. Do you require the name of the person reporting the post? Are you allowing anonymous reporting? Apart from the post itself, what else would you like to capture?
We settled for collecting the reporter’s name and e-mail, the Yammer URL (along with instructions on how to copy that from the browser), the offending author’s name, and a long form box to explain which parts of the conversation are of concern. Of those, everything is ‘required’ apart from the reporter’s name and e-mail.
From a user experience perspective, it is important in the Form description to explain when the Form should be used, what steps you expect the person reporting the post to have done to try and resolve the issue before submitting, and who is going to see the information submitted.
Publicising the Forms URL in your usage policy, making people aware that this is the proper process, is also an important part of the Report Post process.
Flow and SharePoint
Flow is the glue that turns the event of someone submitting a Form into a notification for the Community Manager. Thankfully it’s really easy to use, with templates already published to connect Forms to Yammer.
The temptation is to stop there – as soon as a Form is submitted, send a message on Yammer to the Community Manager and make this as simple as possible. The problem with this approach is that Forms doesn’t allow you to deep link to the submission. That means the notification has to be vague – "a new Form has been submitted" without a link to examine the actual submission.
The alternative is to create a two-step Flow and store the Form submission in a SharePoint list. That has three main benefits:
- It allows the SharePoint list to be the official record of submissions.
- It allows ownership of the Form to be separated out from the permissions to access the SharePoint list. You may want someone to be able to view the list, but not be able to edit the Form.
- It allows detailed notifications to be sent.
There are actually two Flows now. The first copies the Form submission to a SharePoint list. The second sends a Yammer message when a new item is added to the SharePoint list. The advantage of separating out these Flows is that a notification will be sent regardless of how the SharePoint list item was created, even if it wasn’t through the Form.
Flow and Yammer
The Yammer message sounds obvious but actually requires some careful thought too. Like all messages on Yammer, it (appears to) come from a real person. That’s the identity of the person who set up the Flow, so it needs to be made very clear that the message is an automated one. At the end of the message we added a very clear rider: “This message is an automated notification using Flow”.
Secondly, we have to design the Flow for how your Community Manager(s) want to receive their notifications. Posting an Announcement to a private “Community Managers” group is a fairly reliable way of triggering appropriate notifications. Someone can then go and review the post against the Usage Policy. Alternatively, you could specifically @-mention a Community Manager, but that would require editing the Flow if you wanted to change who was alerted.
Learning
While this might have been a fairly straightforward example, we’ve used several Office 365 tools together, with no code, to create a reasonably good community management process. Importantly, this doesn’t lock you into any particular response to how people and posts are dealt with.
We’d always suggest considered human action at this point, particularly as this isn’t expected to be a high-volume task. Learn from each reported event. What could have avoided the content being posted in the first place? Was it a misunderstanding, and could the report have been avoided through clearer communication? Do you need to update your Usage Policy as a result of that content?
Deep down we’re confident that with proactive community management, your network’s conversations will be authentic and respectful enough to never require the Report Post process to be used!
A special thanks to
Benjamin Elias (