Part 2: Front and back of the house automation considerations
This is the second article in the series about automations -
- Part 1: Wait. Don’t automate! Gauging when automation becomes crucial
- Coming up: Scoping automation requirements
- Coming up: Automation project management
- Coming up: Automation implementation tips & tricks
From interacting with community members to implementing a new tool, community operators have the unique ability to straddle the line in the community and live in both the back and front of the house. The same holds true for automations. Automations can be front-facing, something the community member directly gets to experience and benefit from, and they can also live behind the scenes, making processes for the community team more efficient and streamlined. In this article, I’ll discuss considerations as you build automations for both sides of the community.
Front of the house automations
Front of the house automations revolve around member-facing interactions and experiences. Whether it’s automated messages and notifications, to updates on statuses for things like event registrations, there are a handful of considerations to keep in mind.
- Personalization. While automations can streamline processes, we never want to lose our personal touch when it comes to community building. Make sure to segment or properly identify the personas and the various routes or experiences they might have and build the automations to match that particular type of member’s experience and use case. You never want your community member to feel like a sheep being herded (I just spent a weekend on a farm with 🐑, so this is not totally random).
- Timeliness. Automated notifications, messages, and processes should be timely and relevant. You should set regular reminders to audit any front-facing automations to ensure they’re still up to date and make sense. Nothing shouts automated like, “Happy summer!” when it’s December. Also, be thoughtful of when an automation triggers — if it’s immediate, delayed, or based off of a previous step.
- User experience. You want to prioritize the member experience when designing front of the house automations. Whereas a backend automation can be strictly operational and maybe have its wonky elements to it (for example, an un-designed or plaintext button), you need to be thoughtful about providing that good frontend experience. To that end, it doesn’t hurt to get feedback through a quick pop-up survey asking how they’d rate their experience.
- Escalations. Sometimes, despite best efforts to audit and maintain them, automations break, or community members can get lost as they go through various processes. Make sure they have a way to surface an issue and reach out to the team if they need support or assistance. Also, make sure there are resources like knowledge base articles or info bubbles accessible to help them help themselves.
Back of the house automations
Back of the house automations are for efficiency; they take care of repetitive, routed tasks so we don’t have to mindlessly click the same things over and over again and spend time doing something that’s not really worth our time.
- Ownership. Even though the automation takes care of itself, for the most part, there should be a designated owner of the process. For example, if the task of reviewing user group leader applications is handled by a community coordinator, it should be that person’s job to monitor the automation, make sure it’s working as it should, and monitoring reports for any outliers or exception cases as the automation runs.
- Auditing and maintenance. Similarly to front-facing automations, make sure you are ‘going in for your 10,000 mile tune-up’ (that’s a 🚗 analogy) and keeping the automations up to date. Programs are always evolving, things are always being fine-tuned, and you want to make sure your automations are keeping up. Add it to your community ops roadmap so you can allocate time to regularly audit your automations, looking at things like the process steps, time delays, copy, exception cases, errors, and how frequently the automations are running.
- Tech stack. As you’re building automations, you may need to connect various tools or platforms in order for the automation to run. Make sure you’re documenting the automations — how they work, what they do, what steps are done in each of the tools, and also how the data flows. This is particularly important if you are working in tools owned by other teams and you (the community team) are not the main admin. Also try to minimize tech debt by clearing out automations irrelevant or outdated processes.
- Documentation. I know I mentioned this a little bit in my last bullet point, but I think it’s important to stress documenting everything in your automation, and this is something I will cover in parts three and four of this series. I recently had a former colleague reach out about an automation I had created that was still running for the community, asking about a configuration detail and why something was set up the way it was. It had been so long ago, I didn’t remember the particulars, and I hadn’t created documentation for it, leaving them in a bind now that the automation needed to be updated. Shame on me.
Conclusion
Automations are amazing to help make things more efficient and run more smoothly, both from the front and back of the house perspective. However, there are various considerations and differences you should take into account when implementing these automations. Being thoughtful and intentional about how, where, what, and when you automate can greatly improve (or hurt) the member experience and your team’s efficiency.
And as a thank you for making it to the end with me, I give you Yoshi in a baking pan. He tasted delicious. Please ignore the mess in the background.
