Slack Shared Channels(slackhq.com) |
Slack Shared Channels(slackhq.com) |
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
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.
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.
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.
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...
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.
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.
> 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.
I suspect this announcement was just "oops we forgot to move this feature out of beta, lets announce that its GA"
https://slackhq.com/introducing-shared-channels-where-you-ca...
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.
Shared Channels could make such experience of sharing channels between bot developers and users more common.
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?
> It’s officially out of beta today and available for all paid 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
That said, I can see the appeal. Definitely one of my favorite pieces of software these days.
Well a full history of prior chat and giphy memes. Meanwhile I'll be reviewing past Jira sprints.
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.
It makes it really obvious at a glance before you type into the textbox.
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.
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.
I would actually love that for open channels.
>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.