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
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.
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.
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.
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.
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...
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?
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.
“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.
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.
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.
This is a handy time to mention that my employer makes a Slack app for shared channels that provides support-like operational assistance and analytics.
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.
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.
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?
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 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 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
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.
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!
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?
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.
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)
[+] [-] polote|6 years ago|reply
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
[+] [-] raulk|6 years ago|reply
[+] [-] ubercow13|6 years ago|reply
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.
[+] [-] banana_giraffe|6 years ago|reply
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.
[+] [-] cwyers|6 years ago|reply
[+] [-] lmeyerov|6 years ago|reply
[+] [-] tomphoolery|6 years ago|reply
[+] [-] mooreds|6 years ago|reply
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...
[+] [-] nickfromseattle|6 years ago|reply
[+] [-] kordlessagain|6 years ago|reply
[+] [-] toddmorey|6 years ago|reply
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.
[+] [-] vinceguidry|6 years ago|reply
[+] [-] cfors|6 years ago|reply
> 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.
[+] [-] simtel20|6 years ago|reply
[+] [-] Operyl|6 years ago|reply
[+] [-] matdehaast|6 years ago|reply
[+] [-] giancarlostoro|6 years ago|reply
https://slackhq.com/introducing-shared-channels-where-you-ca...
[+] [-] robbiemitchell|6 years ago|reply
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
[+] [-] motakuk|6 years ago|reply
Shared Channels could make such experience of sharing channels between bot developers and users more common.
[+] [-] Jedd|6 years ago|reply
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?
[+] [-] usr1106|6 years ago|reply
[+] [-] tptacek|6 years ago|reply
[+] [-] aeternum|6 years ago|reply
[+] [-] crtlaltdel|6 years ago|reply
[+] [-] igornadj|6 years ago|reply
[+] [-] biot|6 years ago|reply
> It’s officially out of beta today and available for all paid plans.
[+] [-] donmatito|6 years ago|reply
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
[+] [-] stormtv|6 years ago|reply
[+] [-] nickstinemates|6 years ago|reply
That said, I can see the appeal. Definitely one of my favorite pieces of software these days.
[+] [-] ohnope|6 years ago|reply
[+] [-] daniel_iversen|6 years ago|reply
[+] [-] robbiemitchell|6 years ago|reply
[+] [-] justinhj|6 years ago|reply
[+] [-] andylynch|6 years ago|reply
[+] [-] rogerdonut|6 years ago|reply
[+] [-] arcdigital|6 years ago|reply
[+] [-] arusahni|6 years ago|reply
[+] [-] shamir|6 years ago|reply
[+] [-] Yhippa|6 years ago|reply