Slack Shared Channels(slackhq.com)
slackhq.com
Slack Shared Channels
https://slackhq.com/slack-shared-channels
71 comments
This feature is such a game-changer - I take the occasion to plug my own Slack app Smooz[https://www.smooz.io] which does the same thing, creating shared channels, even if it will probably be replaced by Slack native feature when they extend it to free plans
When it came out, it was really a big deal for our users, so I can understand why Slack worked so hard to add this feature. The engineering description is fascinating. Also, while it's never fun to see your app being taken over by the platform, I must stress that Slack API team was very fair and gave me a heads-up far, far ahead of release
When it came out, it was really a big deal for our users, so I can understand why Slack worked so hard to add this feature. The engineering description is fascinating. Also, while it's never fun to see your app being taken over by the platform, I must stress that Slack API team was very fair and gave me a heads-up far, far ahead of release
We've been using this for months. Didn't realize that Slack hadn't officially released this till now.
> Using a shared channel, when the junior auditors start, they see a full history of prior work.
Well a full history of prior chat and giphy memes. Meanwhile I'll be reviewing past Jira sprints.
Well a full history of prior chat and giphy memes. Meanwhile I'll be reviewing past Jira sprints.
WHERE IS THE DARK MODE SLACK ????!
Cheers I honestly did not know. I opened a support ticket last month and I was told that "it's coming" and they closed my ticket.
Yeah, it was released last week
It was beta before today? These channels have been a thing for forever, I assumed it was already GA.
Had the same thought. We have had it at our company for almost a year and I just thought it was a feature of Slack..
I have to wonder what "beta" or "moved out of beta" in this context means.
I suspect this announcement was just "oops we forgot to move this feature out of beta, lets announce that its GA"
I suspect this announcement was just "oops we forgot to move this feature out of beta, lets announce that its GA"
Yeah it's been in Beta for like 2 years I guess.
https://slackhq.com/introducing-shared-channels-where-you-ca...
https://slackhq.com/introducing-shared-channels-where-you-ca...
Our whole company has relied on this for the past few months in order to communicate with some of our clients, rather than invite them into our private Slack. It's been wonderful.
We have a shared channel too. It's great for times when you want to pull a client or a vendor into your slack for long term. You do want to be careful about getting pulled into slack (see this post and discussion from a week or so ago: https://news.ycombinator.com/item?id=20895853 ).
There's actually another use case where a vendor provides a bot and wants users of the bot to be easily able to file help requests. We wrote an app for that and outlined our thinking here: https://www.transposit.com/blog/2019.09.17-amazon-slack-shar...
There's actually another use case where a vendor provides a bot and wants users of the bot to be easily able to file help requests. We wrote an app for that and outlined our thinking here: https://www.transposit.com/blog/2019.09.17-amazon-slack-shar...
How do you communicate about things related to the project, but doesn't need to have the client involved in? Do you have a separate internal channel per client?
My company has this, and I highly recommend it in general for security and data loss prevention purposes.
Any channel that may have external to the company users must have `-ext` at the end of the name and there should also be a non `-ext` channel for internal discussion that relates.
This ends up working really well because the channels sort together next to each other and you can tell very clearly from the name if you are talking "publicly" or not.
Any channel that may have external to the company users must have `-ext` at the end of the name and there should also be a non `-ext` channel for internal discussion that relates.
This ends up working really well because the channels sort together next to each other and you can tell very clearly from the name if you are talking "publicly" or not.
I feel like they should just have different themes for private and public channels. That way, you know at a glance!
In the shared channels it says right above the text input: `foo is in this channel` (with their logo) where `foo` is the name of the other company.
It makes it really obvious at a glance before you type into the textbox.
It makes it really obvious at a glance before you type into the textbox.
That would be amazing. I’m tempted to switch back to in-browser Slack just so I can write a Chrome extension to do this.
We do the same as other people replying, we’ve got a few shared channels with a major client, and alongside that internal channels related to work for them. You do have to be careful you’re in the right channel before letting rip about that one person at the other end everyone dislikes, but otherwise it works fine.
When companies are having to hire people and set policy to police their Slack channels for endless discourse by their employees, that is NOT wonderful.
Why is that worse than corporate governance over communication via email or other instant messaging?
I like shared channels quite a bit and have been using them for several months. Unfortunately it seems that "user groups" do not seem to work with them yet. (i.e. add a group to a shared channel and the users are not auto-joined)
Looks like they're finally available for enterprise grid customers too! Last time I checked it was only for standard plans.
Strange - I was using Shared Channels on an enterprise grid plan over a year ago...
For a long time you could use them within a grid, but not between a grid and the outside world.
The issue with the channels are the same than communicating over slack:
You customers are feeling like they can ask any question and get an answer in 1 minute, and if you dont answer them straight away then they are unhappy. Definitively not something I recommend
You customers are feeling like they can ask any question and get an answer in 1 minute, and if you dont answer them straight away then they are unhappy. Definitively not something I recommend
Don’t blame the tool for mismanaged expectations.
but the medium is the message
If the tool is presented as an instant messenger, people often get upset when responses aren't instant.
This is spot on. You should blame the tool for mismanaged expectations if the tool inherently sets the expectations.
I'm just trying to imagine ways you could use slack and not set an expectation of having someone online to chat to. Use a bot to resond with "we'll get back to you when we can"? There's no option that doesn't feel like an incredibly frustrating experience for the user.
I'm just trying to imagine ways you could use slack and not set an expectation of having someone online to chat to. Use a bot to resond with "we'll get back to you when we can"? There's no option that doesn't feel like an incredibly frustrating experience for the user.
No matter how you look at it, if you can't reply in under a few minutes, you shouldn't be presenting your support as a chat. Just use email.
Other support chat tools have solved this for quite some time with a queue and display of estimated waiting time. You may not get an initial response immediately, but once an agent becomes available they're assigned the chat and do communicate synchronously.
In comparison, Slack has no way to indicate that an agent is already working with someone else in another channel, nor any good way to assign a specific owner--customer questions are dumped into a channel with X support agents as members, one of whom will hopefully respond.
In comparison, Slack has no way to indicate that an agent is already working with someone else in another channel, nor any good way to assign a specific owner--customer questions are dumped into a channel with X support agents as members, one of whom will hopefully respond.
What confuses me is that's just not my experience. I've seen and helped run multiple company Slack channels, and none of them regularly had instant responses.
Would be an interesting slack integration to enable setting SLAs. Say a message prefaced with (question) starts a timer and then you can track an SLA against that.
I would actually love that for open channels.
I would actually love that for open channels.
If you expect to not reply immediately (or "soon"), what's the point of using any chat program instead of email?
Either you're fine with short, possibly intense (maybe even urgent) conversations, and chat works well.
Or, people want to communicate more async and you can take a day or two to answer. People generally use forums/emails for this.
Either you're fine with short, possibly intense (maybe even urgent) conversations, and chat works well.
Or, people want to communicate more async and you can take a day or two to answer. People generally use forums/emails for this.
No, don't use a instant messaging tool like an answering machine. You set the expectations when you open up slack as a support avenue.
Is this intended for support? We use single channel guests at the moment to collaborate on projects with external companies without any issue. This seems to be geared towards that.
I imagine it's intended for any use case in which you want to communicate with people outside your company via slack, but don't want to invite them into your org. I was responding to these comments:
>You customers are feeling like they can ask any question and get an answer in 1 minute, and if you dont answer them straight away then they are unhappy. Definitively not something I recommend
>Don’t blame the tool for mismanaged expectations.
>You customers are feeling like they can ask any question and get an answer in 1 minute, and if you dont answer them straight away then they are unhappy. Definitively not something I recommend
>Don’t blame the tool for mismanaged expectations.
So am I, "Don’t blame the tool for mismanaged expectations.". This is correct IMHO. Inviting customers in that expect support is setting their expectation that they'll get support in real time. I could think of potentially two of our customers that pay enough for us to consider this. The tool just needs to be used the correct way.
...I feel like I meant to reply to the first one. I agree.
I took over a customer who previously only got answers over email in 1 week, and they were useless crappy answers even then. When I started slacking them they got useful answers in 1 minute and the customer was much happier.
My point is that even if the customer feels they can only get an answer in 1 week so they don’t expect any more than that, that feels shit especially if the answer sucks.
My point is that even if the customer feels they can only get an answer in 1 week so they don’t expect any more than that, that feels shit especially if the answer sucks.
It's all about setting expectations. I use this both to let customers in our Slack, and talk to people we're we are the customer. In the later case, the bigger company said "our reps will only reliably respond within these hours, may be delayed by x minutes".
Once we know the ground rules, we're all happy. I've taken to doing the same with our customers, so they know not to ask each and every tiny question with a @here ping, or whatever, and that our employees don't live in Slack 24x7.
Once we know the ground rules, we're all happy. I've taken to doing the same with our customers, so they know not to ask each and every tiny question with a @here ping, or whatever, and that our employees don't live in Slack 24x7.
I don't think I've experienced either side of this. I've never seen people who otherwise have reasonable expectations of response time go crazy because of Slack. And I have never, ever seen someone with unreasonable expectations of response time behave well just because it's e-mail. Especially since e-mail has been put onto smartphones, I don't really see a whole lot of difference in how people behave based on the size of the text box.
the UI s definitely differentiate. Typing indicators, compact display, persistent reply prompt ... these things prime the users over how to use the box.
We combine Slack + Zendesk for this reason. Users can start however they like + we can pick to shift. Enterprise SLAs are generally 1hr for ack anyway, and early stage needs to be customer centric, so works great in these settings.
i have used shared channels to coordinate with outside contractors. not having to add every single contractor as a guest to a channel was a major win for me. each of their orgs already had a slack setup.
This is new? I assumed Slack would already have had this for some time. What’s their story around security and compliance? - it’s good to see another choice emerging alongside Bloomberg/Eikon/Symphony for inter-firm chat but it’s hard to justify having more than a couple of these on any given desktop.
This seems like a security issue waiting to happen. My guess is these channels will have to be highly monitored.
I love using discord for my open-source projects as I feel that the individual role and channel permissions are a little more powerful. I wish Slack adopted this full customization permission ability into their software.
Hard to imagine using Discord for open source projects, but this is likely all marketing/branding association for me.
That said, I can see the appeal. Definitely one of my favorite pieces of software these days.
That said, I can see the appeal. Definitely one of my favorite pieces of software these days.
Rust and React are on Discord, you should check them out, seems to work pretty well
Certainly this has its benefits. But how often does it happen that someone types (especially pastes) something into the wrong channel erroneously? Not that uncommon in my experience. That's much more dangerous if you have business partners/customers in the same chat system. Sending a message to the wrong email recipient is much less common in my experience.
I'm a Slack App developer (http://amixr.io incident management), we have a client who added us to their Slack and it changed a lot. Seeing how users collaborate with your app (and next to your app) gives us a lot of insights.
Shared Channels could make such experience of sharing channels between bot developers and users more common.
Shared Channels could make such experience of sharing channels between bot developers and users more common.
Aren’t these like a year old now? Feels like we’ve been using them forever.
I think this is a great idea and I'm biased because I came up with the same idea when brainstorming Slack new features in a job interview. One thing that concerns me about it is the amount of confidential information that people bandy about on their corporate Slack that could accidentally be leaked to a shared channel. Is that something that comes in practice?
“New people coming into a project can readily access a project’s archive, allowing them to ramp up swiftly.”
How many people have ramped up quickly by reading the chat history of a channel? That’s not documentation—instead it’s like a really bad screenplay. I hate digging through channel history as I join and kinda resent the expectation that I’m supposed to do that.
How many people have ramped up quickly by reading the chat history of a channel? That’s not documentation—instead it’s like a really bad screenplay. I hate digging through channel history as I join and kinda resent the expectation that I’m supposed to do that.
Slack history was invaluable to me when I was ramping up at my current role. You get a real sense for the struggles the teams are dealing with.
Unfortunately Slack is where documentation goes to die. When I face a weird internal issue the first thing I do is search:
> in:@<channel> <error>
You would be amazed at how much unofficially documented stuff is sitting in Slack. It is unfortunate but paying attention to the right Slack channels at work can be very important in understanding company strategies and decision making, as well as random tidbits on architecture decisions.
Of course I would prefer official documentation but sometimes you gotta make do.
> in:@<channel> <error>
You would be amazed at how much unofficially documented stuff is sitting in Slack. It is unfortunate but paying attention to the right Slack channels at work can be very important in understanding company strategies and decision making, as well as random tidbits on architecture decisions.
Of course I would prefer official documentation but sometimes you gotta make do.
The alternative in most cases is _no documentation at all_. It's not like people would go spend two hours writing up documentation if Slack didn't exist.
In large teams it's worth the reduction in 'code velocity' to have engineers document what they are building.
I specifically make efforts, and encourage others to do the same, to keep most documentation outside of slack. Do you have a question about a ticket? Ask it in a comment not slack. Do you have a question about how our system works? Ask it in the private Stack Overflow. Want to advertise a cool new internal service we can use? Great tell everyone in slack, but also add it to swaggerhub.
I specifically make efforts, and encourage others to do the same, to keep most documentation outside of slack. Do you have a question about a ticket? Ask it in a comment not slack. Do you have a question about how our system works? Ask it in the private Stack Overflow. Want to advertise a cool new internal service we can use? Great tell everyone in slack, but also add it to swaggerhub.
However, simply having important pinned items, and the ability for colleagues to provide stable links to backchat is a useful part of making history of a company accessible.
It seems to me that a) this is an inherent and long-standing feature of messaging systems that use open, free, and/or federated protocols, b) it invites even more interruptions as you're blending policies of two or more organisations, and lowest common denominator will likely 'win', c) you're still stuck mapping any non-trivial issues raised in chat back onto a proper tracking system.
The suggestion that your knowledge 'archive' is located in an off-site subscription service that's not indexed with the rest of your institutional knowledge systems, and likely with a poor signal:noise ratio, is worrisome. Do some organisations actually work this way?
The suggestion that your knowledge 'archive' is located in an off-site subscription service that's not indexed with the rest of your institutional knowledge systems, and likely with a poor signal:noise ratio, is worrisome. Do some organisations actually work this way?
I imagine over the years Slack has really made a dent in Gmail's intra-organization messaging rate. Now cross organization is getting swallowed. Does Google care?
This feature is close to useless for me since the admin of the slack account has to “connect” the two teams/domains/whatever - how does that enable free and ad-hoc collaboration in a medium-to-large organisation??? I’m used to tools like Dropbox, email, Asana, G-suite where you can mostly just collaborate with whomever you want around the world. I think slack is missing a huge opportunity by keeping it so locked down!
Keeping it locked down is how they keep enterprise security teams happy, and selling to enterprises is how they make a lot of money.
..and that's how rogue use of other tools start and how "shadow IT" became a thing :-) .. these super locked down systems become "security theatre" and create a false sense of amazing data governance and buttoned up security.
We’ve helped a lot of companies, especially serious tech/infrastructure companies, manage dozens of active channels with their most valuable customers. They also use it with internal-facing “escalation” channels to facilitate collaboration.
On the operational side it uses PagerDuty-like notifications, state management, open convo reminders, and webhook integrations.
https://frame.ai/frame-for-slack