Slack Etiquette Part 1: Client Chats
Excellent communication is key to any excellent project. As a service agency, we owe it to our clients and to ourselves to offer the most effective means to get in touch, which is why we invite clients to use Slack. (In case you were just rescued from a bunker after 15 years of captivity and are just starting your normal life above ground, Slack is a messaging app for teams.)
Inviting clients to Slack means putting aside long email threads with the whole world on CC, and opting for direct messaging. The thing with any direct messaging app however, is that we all have this underlying assumption to expect a response momentarily. With e-mails, it’s easy enough to flag a message and come back later to compose a thought-out answer. The expectations towards answering delays are way more flexible when one sends an e-mail, rather than a DM.
So whenever I invite a client team to Slack, I feel the need to provide guidelines as to when to use it vs. other means of communication. This ultimately allows us to focus on our work and ensures aligned expectations in regards to delays of replies.
Le Disclaimer
Prior to inviting clients to join our Slack team, I’ll send a message (usually on Basecamp) outlining some rules on how to communicate with us. Here’s what that message typically looks like:
Hello team!
In a few minutes, I’ll be sending you an invitation to join our Slack team, where we’ve set up a new public channel for our project.
We like having clients on Slack so we can chat in real time when we have quick questions. It eliminates the need for long email threads to discuss minor things and offers a platform for both of our teams to connect and chat on the regular.
Some No-nos:
1. Please do not provide feedback on presentations, demos or any deliverables on Slack. Let’s stick to Basecamp for that. Live commenting on a chat room creates the risk of going on tangents and omitting important pieces of feedback.
2. Direct Messaging the designers & developers. To ensure transparency, when using Slack, let’s try to only use the public project channel we’ve created and avoid direct messaging. Often, we might discuss internally first to make sure we’re all aligned before providing you with an answer, which is why it’s best that everyone has access to all of our exchanges. Of course, for small questions like “What time is the meeting again?” you can DM me, the project manager, to avoid clutter on the channel.
When to use Slack?
Throughout our creation process, the designers/developers will probably have questions that come up along the way. Slack is a good way to chat directly so that no one is blocked for too long before getting an answer.
To obtain clarifications on feedback. It might happen that we’ll need more information to interpret your feedback, or you’ll need to double check design decisions on items that we’ve presented. Slack is a good way to either discuss it directly, or set up a quick call.
Sharing new references, inspiration, etc. You might stumble upon a brand you like, or a website / design reference you feel you should share with us. Just send us that link on Slack and we can have a chat about it there.
—
Lastly, let’s remember that our team is hard at work to deliver an awesome product. It might take us a moment or two before getting back to you. We’ll always try our best to respond before the end of the day.
See you on Slack!
The Dynamo team
Public / Private Channels
The majority of the client projects at Dynamo have a client (public) channel and an internal (private) channel. It’s simple — we use the client channels to exchange with client teams, and the internal channels to discuss the project within our internal team on the day to day.
Inevitably, our internal channels are much busier than the client channels. It’s where we’ll post reference links, screenshots, presentation decks, inVision prototypes, strips of code, depending on the stage we’re at on the project. It’s also where we’ll share meeting notes, and discuss the project during each iteration.
A little heads up before taking the plunge
My fellow PMs at Dynamo will agree; we love having our clients on Slack. It significantly facilitates communication between teams. They’ll also agree however, that there is a clear need to inform clients of how to best use Slack in a way that will benefit the project.
Abstaining from outlining the dos and don’ts ahead of time could quickly result in too many communication streams, thereby obstructing the high level view of a project. Discussing important elements of the project on Slack is also not optimal, as it leaves a very disparate paper trail. At the end of the day, Slack needs to be used properly to be an efficient communication tool, or else it could shoot you in the foot.
Clients with whom I’ve shared guidelines on how to use the messaging app have been really good at respecting them and have expressed team communication as being a key factor in the success of our projects. Of course, it still happens where the client or even I accidentally post something on Slack that should be published on Basecamp instead. It’s important to encourage calling each other out when that happens and make sure to post the information on the platform it belongs.
So there you have it. This is how we introduce our clients to Slack. In a few weeks, I’ll be sharing Part 2 of this series, which will explore some dos and don’ts regarding internal team Slack behaviour .
Until next time!
Nick
