Need to connect a Freenode channel to a room in HipChat? Or want to give customers a simple way to connect to a channel in your Slack team?

Sameroom does that!
Learn more

 Subscribe via RSS

Team Chat: The Trouble with Guest Access

By Andrei Soroker

As team chat is rapidly replacing other forms of internal business communication, it's not surprising that companies—and agencies in particular—are increasingly using this technology for external communication as well.

While this is, overall, a welcome and exciting development, significant dangers lurk beneath the surface. In this post, we'll take a look at a few of these dangers.

Since email continues to serve as the preeminent cross-company collaboration medium, we'll also consider how some important workflows differ between email and team chat.

Teams Don't Scale

With time, accepting a new Slack invitation is becoming a bigger and bigger ask. If 10 of your colleagues need to join as well, the ask gets multiplied by 10.

(It doesn't have to be Slack—any team-centric system with guest or multi-team access will have the same problem.)


Figure 1: Artist's impression of a decade of joining Slack teams

Being in many teams with the same group of people means that you've got as many unique direct message (DM) histories with each person as there are teams. You have to be vigilant to always head to your "home" team to DM with your colleagues. If everyone has the same avatar and name in each team, things can quickly get confusing.

This may not seem all that bad, beyond the obvious observation that being a guest or a full participant in many teams doesn't scale particularly well.

But, we're just scratching the surface. There are serious problems with guest and multi-team access—ranging from project management to data governance.

Presence and DM Considered Harmful

When you give your customer access to your team's online presence, along with ability to message every team member individually, you're summoning Sauron.

It's often noted that the beauty of email communication is in the ability to respond at your own pace. With email, you're offline by default.

If you work at an agency (management consulting, PR, marketing, development, design—you name it) and you've got many companies as customers, you're undoubtedly tending to multiple concurrent fires at any given moment. This often means hopscotching around the schedule and the communication matrix with the goal of maximizing throughput ($$) without blowing deadlines or pissing off clients. It's a delicate dance.

Email and its "offline by default" mode lets you control the switchboard explicitly.


Figure 2: Explicit control of the communication switchboard

Email has many other redeeming qualities, like the ability to forward messages, a global user directory, and being truly cross-platform.

For tight collaboration—with fires aflame and all—email kind of sucks. Hence the recent and ongoing hypergrowth in the team chat space.

Team chat makes it really easy to tell whether someone is online or not—this feature is called presence. Another near-universal feature of team chat is direct, one-on-one messaging (DM).

Turns out, presence is not necessarily desired in agency-client communication, and neither is the ability to DM.

Here's how the problem plays out.

You've got three customers, three projects. Your team are guests in each customer's team chat. You've got major fires with two projects and just a little bit of smoke with the third.

The third customer, the one with the smoke, engages your team in a conversation—you're all online—available!—after all.

You ignore. Not because you don't care, but because your entire career hinges on preventing the two burning projects from turning to ash.

The third customer thinks that maybe you didn't get the messages, so he DMs you. You ignore for a few hours, then respond with "I'm so sorry," and come up with chipper-sounding reason for being slammed.

Now he knows you're ignoring him.

Just to be sure you respond from now on, the third customer stops using the multi-user channel altogether in favor of DMing you. Now you have to copy and paste stuff from your DM with the customer into your "home" chat, so your colleagues know what's going on. So long, transparency!

The same scenario is more likely than not to play out on every single project, causing a bit of a mess.

Presence and 1:1 DM is a privilege for inner-circle colleagues. Extending this privilege to customers and other external contacts is not a great idea.

They Control Access

Whenever two companies are engaged on a project, each party needs the ability to unilaterally invite additional members to relevant project communication channels. Guest access robs the guest party of this ability.

Complex, long-running projects often require the attention of experts to solve critical, but very well-defined problems.

To maximize the effectiveness of an expert, a project manager has to engage the expert—call the Wolf—at just the right time, provide the least—but sufficient—amount of context, enable the expert to temporarily take the wheel, which will often include calling their own Wolves, and remove the expert once the problem is solved.

Traditionally, this has been handled over email, but email is notoriously unkind to experts in the long run. Here's how.

Bob, the project manager, is faced with a problem only Alice can solve. Bob adds Alice to the main project email thread, provides sufficient context, and asks her to steer. Alice solves the problem with the help of Jo, who is also copied, but neither Alice, nor Bob can get Alice or Jo reliably removed from the thread going forward.

Alice solves critical, but well-defined problems on many concurrently-running projects. In the end, Alice, Jo, and all other experts get every single email for every single project they touch.

This is one of the most common criticisms of email—it's hard to modulate noise and almost impossible to undo "invitations".

If you're the one inviting customers as guests, team chat actually solves the problem of the ever-expanding noise for your experts. You're free to bring them in and out of channels as needed, they are free to engage their own experts, and everyone can use notification settings to ignore anything that doesn't concern them.

But if your team are guests in another company's chat, you lose the ability to invite your experts—instead, you have to ask an admin of the other team to do it. Your experts are even worse off—they have to ask you to ask an admin for further invitations.

Relinquishing the right to engage and disengage team members at will is a huge problem for project managers—it hinders the very essence of the job. Project managers absolutely need the ability to unilaterally grant and remove access to a project's communication channels.

They Own Your Data

Whenever two companies are engaged on a project, each party should own a complete copy of all communication history at all times. Guest and multi-team access prevents the guest party from owning history.

The problems caused by allowing DMs and presence in vendor-client communication, and the inefficiencies in project management process introduced by the lack of access control are significant.

Still, they can be dealt with by patience and clerical endurance, so to say. As long as clients pay their bills, agencies will take a near-arbitrary amount of abuse.

The biggest problem—one that simply cannot be ignored by any serious business—has to do with ownership of communication data. If your agency are guests in a customer's team chat, you're always a few hostile clicks away from losing all collaboration history.

The example scenario is simple: your agency spends a few months working on a project. You believe the resulting deliverable is according to spec. The client disagrees. The client refuses to pay, breaks off communication, and revokes your guest access from their team chat.

Time to sue!

You see where this is going: you have no access to the hours of chat transcripts and gigabytes of shared files proving your case. Your client may delete it all and plead ignorance.

The number of ways in which this turns ugly is endless.

No legal counsel would advise or sign off on a collaboration solution where your company does not own the communication record.

But We're Never Guests, They Are

What if you're always inviting clients to your team chat, and not vice versa?

There are two problems with this approach.

One, it can't continue forever: sooner or later you'll encounter a client in the know. Since they pay the piper, you won't have much choice but be a guest in their team chat.

Two, as Confucius once said, what you do not wish upon yourself, extend not to others.


Need to connect a Freenode channel to a room in HipChat? Or want to give customers a simple way to connect to a channel in your Slack team?

Sameroom does that!
Learn more

 Subscribe via RSS