Building the bridge
Developing for Shared Channels
Hi! We’re Frame, and our mission is to make collaborating with your customers as easy and productive as collaborating with your own team. If someone adds the Frame app to a Slack channel in which they speak to their customers, it will:
- help manage attention by notifying an account owner or on-call team whenever a customer starts a conversation
- automatically import customer profiles and export conversation summaries to tools like Zendesk, Salesforce, Asana, and JIRA
- tally up conversation analytics to give visibility into the customers and topics that a team spends their time on
Frame started out by providing custom Slack apps to help companies like Simon Data scale a Slack-first customer success experience for enterprise accounts. Slack’s recent release of Shared Channels made it possible to connect two Slack workspaces, opening the gates for apps like ours to reach a growing set of companies adopting Slack for their B2B relationships.
With shared channels bringing companies together, app developers have a new challenge. Previously, apps could interact with users in two distinct ways: in a public channel (e.g. Pagerduty alerts) or a direct message (e.g. Abacus expense approvals). Now, we need to think not only about individual versus team, but also about two teams — each with potentially distinct goals — in one channel.
When developing a Slack app for shared channels, ask yourself the following questions:
- Who is in your shared channel, and what are they trying to accomplish together?
- Which workspace invites your app, and how is each workspace’s expectations of it unique?
- What are your app’s responsibilities to the other workspace, and what are their expectations of your app?
Answering these questions helped us learn some lessons we’re excited to share.
Lesson 1: Use targeted messages to avoid clutter
Since people join a shared channel for different reasons, they don’t all need to see the same messages from your app. For example, some of the help Frame gives to service providers might not be as relevant to their customers. Reviewing what we wanted to communicate and to whom, we divided our app’s flows into three types of messages: public, private and personal.
Public messages are messages that everyone in the channel needs to see — the standard chat.postMessage we all know and love. Frame first talks privately to the app’s inviter, then announces itself to explain why it’s in the channel.
Private messages are messages everyone in the workspace that invited the app needs to see. In the example below, Brandon uses Frame to create an Asana ticket linked to the conversation. Sharing with Brandon’s team keeps them aware and avoids duplicated effort, but there’s no need to share that internal ticket with the customer.
We implement private messages with what we call “multiphemerals” — which is just repeating a chat.postEphemeral for each user who should see that message.
Personal messages respond to an individual user’s interactions using ephemeral messages. Narrowly targeting these messages allows us to offer a richer app experience without distracting others in the channel.
Even while targeting messages carefully, we’re constantly challenged by customers to make our app interactions as concise as possible.
If you’re using an app to enhance a conversation, it’s important not to get in the way of that conversation! To avoid being disruptive, Frame divides long lists of message attachments into “tabs” that can be selected one at a time using a message menu (see the “actions” dropdown in the screenshot above).
Lesson 2: Establish a home channel for your app
Using ephemeral messages introduced another set of design considerations. Ephemerals are great during a conversation, but they disappear when someone reloads or switches clients, and aren’t available to anyone who joins the channel later. We needed a place to post private and permanent messages.
Channels are the main tool teams use to organize their Slack lives, so most app interactions should stay within one channel the user chooses. But because shared channels are sensitive, it can be useful to have another place to communicate with your host team. Apps for individual users can probably do this using DMs. Since Frame is about helping customer-facing teams coordinate, we found it useful to designate another channel as home base: the Feed Channel.
Our Feed Channel started as a place to inform the service provider team about new conversations, and to keep a permanent record of conversations that have already been closed.
After we set it up, we realized it was also the perfect place to communicate with the host team about Frame configuration, onboard new agents, and much more. We use membership in the feed channel (which is private) to determine who can see Frame data and invoke integrations during conversations, which are sometimes sensitive.
In short, giving our app its own home base let us cleanly separate two modes of interaction with our users: configuring the app and team, versus helping our users serve their customers.
Lesson 3: Work in tandem with other apps
Slack apps can see each other’s posts via the API, which means there’s an opportunity for them to work together. App collaboration can happen in all channels, but there’s particular reason we wanted to make it work in shared channels: it’s much harder for someone to pause a customer conversation to work with their Slack apps!
Usually, it’s up to users to coordinate their stack of apps. For example, you might use one app to retrieve customer info, another to put that info into a work ticket, and one more to link that ticket to your CRM. It’s much easier to do that in Slack instead of jumping between three windows! But for a user trying to copy and paste between apps while keeping up with their customers, it can feel like trying to juggle and play ping pong at the same time. In shared channels, taking helpful actions automatically is especially important, so that your user can focus on their customers.
We started asking whether Frame could work with other apps, without forcing the user to connect the dots. For example, many people use Guru, a knowledge management app, to share info and answers with customers. By listening for Guru cards in a channel it’s assisting, Frame can capture a link and automatically add it to the conversation summary, making sure it will be linked automatically to a followup ticket in Asana generated later on.
We found opportunities to recognize and work with other apps: customers can ask Frame to automatically import customer data from tools like Mixmax or Clearbit, or to share conversation metadata with external tools like Asana, Salesforce, and Zendesk. When you integrate with other apps, you add value to your users’ current stacks, rather than just competing for the same attention.
If you’re building a Slack app that helps work with customers in shared channels, we’d love to hear about it and how we can connect.
Conclusion: Always be learning
In this post, we described a few customer needs around shared channels and how we reacted. But in the same few weeks, we spoke with users who were evolving their Frame usage in ways we hadn’t thought of. A few examples that raised questions for us:
- One company we talked to is using multiple shared channels per customer in order to separate topics and tiers of stakeholders. Should Frame aggregate analytics by both channel and remote team to help teams understand where their time goes?
- Companies that use shared channels for their largest customers are already running “communities” where they support customers publicly as guests. Does Frame need different “modes” to help conversations in both large and small groups?
When a major new feature like shared channels is released, developers and users help each other explore all of its potential uses. If you’re applying shared channels in an interesting way or developing a product that assists in shared channels, we’d love to hear about it. Please comment or just reach out to george@frame.ai.
Learn more about building apps for shared channels.
