Community Automation: A Step-by-step Guide for Community Operations

The first rule of creating an automation for your community work? Wait, don’t automate!  

Sure, it might seem counterintuitive. If you're thinking, “Isn’t automation part of a community operations role?”, you'd be right! Automation is sexy; it helps team members focus less on repetitive tasks and more on things that matter.

But if your community is new or you’re embarking on a new program or process, there is incredible value in doing everything manually to start. Yes, this will include more work upfront — documenting processes, the amount of time things take to get done, opportunity for mistakes, etc. However, going through the motions manually when first starting out provides you a better vision of what needs to be automated, where the true bottlenecks are, and what parts of the process should continue to be manual.

Most importantly, processes tend to be fluid and get updated, so starting manually allows you to mold and modify your processes without requiring development resources. As I’m sure budget is a constraint for every community team, the last thing you want to do is build automation before you’re ready, and end up having to spend more money to undo or re-build your automations later on.

Essential pre-automation steps

As you work through the process manually, here are a few considerations to keep in mind.

1. Generate your base metric

This is what you’ll use to measure against once the automation is in place, and ultimately tells you the number of hours (and therefore, money) your team has saved by implementing the automation.

To figure it out, calculate the amount of time that it takes to complete the end-to-end process manually once, and multiply that by the number of times the process is done in a month.

From there, you should have the number of hours a month your team spends doing this process manually. Hold onto this nugget of data — you're going to need it later. (Or, if you need a business justification on why you are looking to automate this process, be sure to include it in your case.)

2. Document everything

Have an idea for automation? Write it down. Tried something slightly different this time? Write it down. New “if... then” encounter? Write it down. Color code. Add emojis. I personally like the green checkbox if something worked well, the thumbs down emoji if something didn’t work, and the black checkbox if it’s an idea and something to explore further.

3. Exception cases

There are inevitably going to be exceptions — you’ll never be able to find a process that works for every possible scenario, especially if your community is evolving and growing.

As you’re building out automation, it will be important that you consider your exception cases and how you’ll handle that within the automated process.

4. Teamwork makes the dreamwork

Include your teammates in this process. They should be involved in testing out the manual process, documenting their experiences and their ideas, and providing their valuable input.

5. Walk an outsider through the process

When you’ve gotten your notes in order, walk an outsider through the end-to-end process. It could be someone who works closely with your team, maybe a teammate who isn’t directly part of this process or program.

6. Be realistic

Given your technological landscape, be realistic about what’s feasible. When thinking of automation, it’s really easy to fall into the “anything is possible” trap.

Technically, sure, anything is possible, but it depends on what technology you have. Know the limits of what your technology is capable of. If you’re lucky enough to work with a developer, ask them. I will often run ideas by my developer and ask him if it’s possible, or how much additional effort it would take to accomplish.

7. Prioritize

Depending on the scope of your automation, you may not be able to accomplish everything you hoped to, whether it’s due to dev bandwidth, budget, time, or competing priorities. As you’re documenting your process, figure out what is a must-have vs. a nice-to-have.

8. Process charts!

That’s right, I added an exclamation point. I love process charts, and it’s a great way to visually see the process that you’re documenting, the various branch points, manual steps, etc. It’s a good step to take once you’re done with the documentation. Use all the items you documented to create a process chart.

While you are doing all of the above, it’s always a good time to check your roadmap. Give your developer a heads up that you are working on this, and make sure there’s no conflicting priorities that would consume dev bandwidth. I tend to aim for a quarter ahead, so there is ample time to prepare and plan for it. This initiative should, however, already be slotted for your annual planning purposes.

Team and manager automation sign-off

You now have a fully-fledged process mapped out, and it’s time to get manager and team sign-off — an essential part of any automation. Getting team sign-off may seem extra, but getting their input and approval on the process will save you time later when it comes to training and knowledge transfer. Including them throughout the process gives them a sense of investment in the new process, and they are more inclined to adopt the new process and understand it earlier than if a new process just shows up one day. After all, it’s a terrible feeling when you spend time working on a new process or automation, only to have no adoption or recognition from the team.

Start by creating a deck with the storyline. Set the scene, the reason why this automation and updated process was necessary, and make the deck in a consumable format. Perhaps break apart the process chart into little pieces, and go over each part of the overall process in a slide. (Even though you and I love process charts, not everyone can read or digest them easily).

Additionally, clean up the original documentation, making sure to leave any of your team’s input. Schedule a meeting, including the context and the links to the deck and the documentation for reference in the event invitation. During the meeting, walk them through the story and mention ideas that team members suggested that are now incorporated into the process.

In the slide deck, create a slide where the team can sign off that they have read and approved the process. After the meeting, give them a few days to digest and review, and ensure each person has checked off their approval box.

Developer hand-off

Now is the time to schedule a meeting with your developer to walk them through the same thing you walked through the team. I typically use the same deck, with a greater emphasis on the process chart. Be sure to record the meeting, as it will be useful for your developer to reference later.

Your developer will take the information you provided and will generate a timeline of how long this initiative will take. As the CommOps person, it will be your responsibility to provide prioritization and any absolute deadline for this initiative, based on other initiatives going on with the team.

If you don’t have access to developer resources, fear not! Skip this section and follow the guidance in ‘No and low-code options’, below.

Automation development program management

Once your developer gets back to you on timing, it’s time to start creating a project plan. This isn’t a super extensive project plan, but rather just a few key milestone dates and things to keep you organized. These are a few things I tend to include in my project plan:

Developer milestones

Your developer should let you know when the project will be dev complete, when it will be ready for you to test (in a sandbox, obviously), when QA will take place, and go-live date.

Check-ins

You probably already have recurring stand-ups or syncs with your developer, but if not, schedule a few reminders to periodically check in and see how things are going.

Team updates

Update your team once you get the timeline from your developer. Additionally, make sure you’re being transparent with your team and providing them updates on progress. This way, it stays in their minds and doesn’t fall off their radars.

Internal documentation

With any process, even if there is automation, there will be things that the team members may have to do, or parts they will need to reference if they are helping a community member. Make sure to document any of these scenarios and add them to your internal knowledge base. It is also very helpful if you proactively think of any Frequently Asked Questions (FAQs) that you anticipate being asked by community members and create email templates that the team can use too. You can partner with your content manager for copy editing and review.

External documentation

Make sure you are updating any help articles on your community help site. It’s helpful to pre-draft these, work with your content manager for copy editing and finalizing, and have them ready to publish when the project goes live.

Community automation testing

Testing the new functionality should be a team activity. It helps get them acquainted with the new process before go-live, and having more eyes on it before launch is always incredibly helpful. You may need to provide the team a platform to provide feedback (whether it’s a shared doc, a form, or if you prefer to receive updates via chat).

Team training

Run a training session before go-live, and refer back to the documentation that you created. This will help the team connect the dots and see how what you previously walked them through has come to fruition in a final product. Also in this walkthrough, review the internal and external documentation. Make sure you allow time for questions so the team has full understanding, and also communicate timing for when the go-live will happen.

No-code and low code community automation options

Not having a developer on-hand to help is certainly not a make-or-break for your grand automation plans. There are plenty of incredibly successful community teams who are able to handle setting up automations themselves, thanks to all the great automation tools out there.

Many low-code and no-code platforms allow you to essentially drag and drop components, like items and actions, into a process or application without having to write code. Among my favorites are:

• Zapier: A great example of a no-code automation tool is Zapier, which allows you to connect various platforms and create rules and flows by simply putting components and actions together.
• Salesforce: Also currently has Process Builder and Workflow Rules, two similar features that allow you to click and drag to create automated rules and triggers (note: Salesforce is sunsetting both Process Builder and Workflow Rules and is launching Salesforce Flow beginning in their Spring ‘22 release).

If you know you will be hard-pressed to get developer resources, you can also take that consideration during your vendor selection process. Many platforms recognize the value of no-code/low-code and often have options for basic automation and design tools this way. It could be something as small as moving designed components around on your community site, to something more extensive like email triggers for targeted recipients.

Lastly, there are always options for simple workarounds and peripheral tools. For example, at a previous company, I had a hard time getting marketing automation resources to send emails out, so I found a Google Sheets add-on that would allow me to mail merge emails and sync it to my CRM.

If you know that you want to optimize a process but don’t have developer resources, sometimes doing research on the Internet can yield great workaround solutions.

Community automation maintenance

OK, you have your automation set up. Congratulations! That’s awesome, and you should give yourself a pat on the back. This process is now running on its own, which gives you and your team time to do other things that should require more personal or manual attention (like engaging and doing things with your community members)!

However, it’s important to set up a monitoring and maintenance procedure to continuously check the automation and not only make sure that it’s running as it should, but even start preparing for the next round of iterations.

Set up a report that tracks the processes completed by the automation. For example, let’s say you automated approving user group meeting reimbursements that are under a certain dollar amount. You’d want to set up a report that shows all reimbursements that were auto-approved with this automation. Check this frequently (daily, even multiple times per day depending on the process and frequency) when first starting out. You want to look for any anomalies — this could be a missed exception rule, or maybe something else that hasn’t been considered.

You may find a few hiccups when the process is first implemented. That’s totally fine, but also one of the main reasons you always want to “Wait, Don’t Automate.” By doing things manually from the start, doing thorough documentation, exception investigations, and running it by multiple team members, it helps mitigate this potential risk.

Create a shared team document where any feature enhancements or improvements can be documented. Though a second version or iteration may not happen for a while, it helps ensure nothing gets forgotten. My team frequently encounters an, “Oh — this [insert feature here] could be helpful next time we do this.” Though it’s minor and not a roadblock for the success of the automation, you don’t want to let it slip through the cracks and forget about it when the time comes to re-visit and update the automated process.

To that end, give yourself an estimated timeline on your roadmap to assess this automation and see if a new iteration or version is needed. Whether that recalibration is in two quarters or two years, adding a placeholder to your roadmap will not only put it on your developer’s radar, but will ensure that your team accounts for it as they’re planning out the other items in the roadmap.

Proving the worth of your automation

Remember that base metric I mentioned earlier? Use that, and compare it to after the automation has been implemented. Take the amount of time the process took you to do manually, multiply it by the number of times a month you had to do that process. Then account for the time any manual steps may have to be done with the automation in place, by the number of times a month.

From there, you’ll be able to calculate the number of hours (and therefore dollars) saved by implementing the automation, or the percentage decrease in time. It becomes very impressive very quickly. Then show it to your manager, and your manager’s manager — and prepare for a few pats on the back.

‍