To be honest, I don’t really, but I should.

So I’d encourage you to earmark the time and do it now, as you’re planning. 

Even well after you’ve launched you will find yourself answer the who, what, why, when, and how of community for your colleagues. It’s good you’re thinking about it now. I’d recommend coming up with a a solid singular slide on each of those questions and then support SLA documentation wherever your company does that. That’s what I’m working on now. 

Otherwise, you spend two years (like I did) answer the same questions in Slack or recreating versions of the same slides for different meetings. 

You’re on the right track. Sorry I don’t have any good examples to share. 

Oh, two pieces of advice I like to give:

1. When you make your documentation, I recommend putting a “TL;DR” summary of the top 3-4 bullet point items they should know. 
   
   Your documentation is likely to be detailed and longer than they’ll want to read at first glance. Don’t make them go searching for the key insights. Put the most critical items at the top and entice them to read further. 
    
2. A picture is worth a thousand words. Visualizing processes will aid understanding and increase adoption. 

I talked about each of those a bit at 24:20 in this event recording (skip to 36:40 for when I talk about those two things) 

I agree with @DannyPancratz about even after planning and in our case, implementing we are still iterating and changing things up like the who, what, why, when and how.

The Community Guidelines and Welcome area of our Community is public so you are welcome to take a look at the examples. I got inspiration from searching other Communities that used the platform.

As Community is/was new for us, we kind of took the SLA and how/who timelines a little more relaxed to start, 48 hours or so. Now that we have an official Ambassador program in place, we are working more towards 24 hours. 

I would recommend starting the focus with tone and guidelines for internal teams, especially customer facing teams so that they know how and what to say to customers to drive the behaviors you want to see in Community (this takes time and is definitely something we’re still working on).

For the customer facing terms & conditions, I had to work with our Legal team to make sure it was good to share. I also got that example from inSided Communities.

LOVE these tips! Just wanted to point out this guide which I wrote a while ago, hope that it helps:

This sentence resonated with me @DannyPancratz  I continuously have to repeat myself.

Thanks all in all for the suggestions folks! @Julian found that guide a bit ago and will say very-well done. Love the information in it and will definitely repurpose some of it for our guides.

I’ll keep you all posted what documentation that I’ll be formalizing with my teams and share any tips I learn along the way.

Cheers!

Hiya folks! Figured I owe the Gainsight community an update after creating this topic eons ago.. we’ve officially hit the half year mark of going live with our community and some internal resources I’ve created are the following:

• Community Policy for all employees (dos and don'ts, reiteration of our community mission statement)
• Community Style Guide (tone, style of writing)
• Community Contributors (think a table chart for roles we have for internal employees that participate often in our community other then Community Managers)
• Community Guidelines for our Community Writers (think length of Product Update posts, how to submit your document to the Community manager team, how we publish on their behalf etc)
• Community Basics and FAQ for CSMS (How CSMs can use community with our customers, their role in community and other resources)

All in all I’ve been busy writing up a lot of internal documentation for our company. We host these policies/guidelines on an intranet and while not mandatory it is something that our employees can search for in our intranet and it’s super helpful for our Community management team to send as a quick link resource to our employees.

My current focus is documenting resources moreso for our Community Management team such as workflows, moderation tips, escalation process etc. If anyone has moderation tips or workflows that they’ve leveraged using the features available in the CONTROL area please share. 

@genells  I am working on Community Guidelines and looking for any public resources like those that @ryanne.perry  shared. If there are any resources that you could share I would love to study them.

Thanks for your input on the subject!

Hi @Grzegorz Byrski ! Are you looking for Community Guidelines for community members or Community Guidelines/Policy for internal employees?

While I do have guidelines for our community members (collaborative effort between our marketing and legal departments), my thread above was discussing the guidelines I created for our internal teams. For my internal guidelines, unfortunately I had no public resources to go off of so I ended up creating my own from scratch.  (It was quite the endeavor)

Here is how I outlined our company wide policy regarding community (aka internal guidelines):

1. Purpose (mission statement and type of community we have for our customers)
2. Expectations (what the community is and what it isn’t)
3. Access levels (who has access to what)
4. Roles (who has permission to contribute in our community)
5. Engagement Metrics and where they live (think CRM, Dashboards for engagement, registration etc)

From there, my internal documentation for my peers branched out to other documents like I listed above; style guide (for those roles who contribute to community), Customer Success positioning (to help our CSMs position our community), walkthrough documentation for accessing our community through our SSO solution, Roles and Responsibilities documentation for those who are contributing to our community, and Ideation Guidelines to set expectations internally on how our Product team dispositions ideas and how that review process looks like.

Hope that helps!

Thank you @genells 

Really I was referring to both types, but at least I have a starting point.