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
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.
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.
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.
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.
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 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.
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.
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?
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.
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.
“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.
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.
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!
..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.
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)
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