4 ms·

some good comments and thoughts in here. the Slack status feature you mentioned is -- sadly -- most often used by Slack users to add a cute emoji or whatnot. t

some good comments and thoughts in here. the Slack status feature you mentioned is -- sadly -- most often used by Slack users to add a cute emoji or whatnot. this is unfortunate. Slack administrators can set suggested or "default" statuses. it's at https://<yourslack>.slack.com/customize/statuses https://<yourslack>.slack.com/customize/statuses and so, a company can set statuses that staff can be required to pick from, perhaps some common ones like: - In the office - Working from home - In a meeting - PTO and the company can then make it known to staff that their status icon should accurately reflect their current work ... status, and not whatever cute emoji they want to use. DND/Do Not Disturb should not affect use of Slack status. Force the notification through if your message is urgent. this is not rocket science. if Slack usage is affecting how a company works because staff can't tell if someone will respond or not -- change the way the staff use Slack to better suit the business. /shrug

mdip 7y ago
You make fair points and I'll be the first to say that my experience (and preference) lies elsewhere, so I'll explore the links on Monday to see if they make life easier. The major point that I didn't make clear enough about statuses "not working" is that even if there were more statuses, they are manual. We observed that people manually changed their status, most often, to "Available" from another non-available status, under Skype for Business. Outside of that, people simply didn't manually manipulate their status. And when they did, they'd often leave it that way for a ridiculously long time because they'd simply "forget". Inadequate status choices are not as bad as completely unreliable statuses. Teams shined in providing enough status about a user, automatically, for a non-developer, non-technical user to reliably answer the question "Will I get an answer to my IM/call when I send it?" and "Is my IM/call highly likely to be an interruption?". If you used it for telephony, or had the Skype for Business mobile client installed, you switched to "In a call" when you were on the phone, "In a conference" when you joined a Skype for Business conference call, "Do not disturb - Sharing" when you started screen sharing (and it kept inbound messages from showing up on-screen for your audience). Honestly, it seems like one of those under-the-fold bullet point features, but it is its most important. In the scenario you talk about, above, two things have to happen (after configuration is altered to allow changing statuses). The user has to regularly change their status to signal their availability (not physical presence or time of day, but "I am busy doing something that should keep me from responding"). And the rest of the users have to rely on that status. The only way that happens is if the status is accurate far more often than it is wrong. That won't happen unless everyone is rigorous with making status changes... and that's not a memo I want to send. Lync/Skype for Business (and I assume Teams) gives you both options. Let it run automatically and it'll switch your status when you receive/make a call, join a conference or have a meeting time blocked out in your calendar for you and put it back when you're done, or set it to what you want. And you could extend this capability[0] and automate it in different ways. [0] The old on-prem version was insanely customizable; you could completely re-implement the client, they provided every hook required to re-implement dial-in conferencing (an "Enterprise" feature) in Standard edition (and actively assisted in a project I worked to do just that).

mdip 7y ago

You make fair points and I'll be the first to say that my experience (and preference) lies elsewhere, so I'll explore the links on Monday to see if they make life easier. The major point that I didn't make clear enough about statuses "not working" is that even if there were more statuses, they are manual. We observed that people manually changed their status, most often, to "Available" from another non-available status, under Skype for Business. Outside of that, people simply didn't manually manipulate their status. And when they did, they'd often leave it that way for a ridiculously long time because they'd simply "forget". Inadequate status choices are not as bad as completely unreliable statuses. Teams shined in providing enough status about a user, automatically, for a non-developer, non-technical user to reliably answer the question "Will I get an answer to my IM/call when I send it?" and "Is my IM/call highly likely to be an interruption?". If you used it for telephony, or had the Skype for Business mobile client installed, you switched to "In a call" when you were on the phone, "In a conference" when you joined a Skype for Business conference call, "Do not disturb - Sharing" when you started screen sharing (and it kept inbound messages from showing up on-screen for your audience). Honestly, it seems like one of those under-the-fold bullet point features, but it is its most important. In the scenario you talk about, above, two things have to happen (after configuration is altered to allow changing statuses). The user has to regularly change their status to signal their availability (not physical presence or time of day, but "I am busy doing something that should keep me from responding"). And the rest of the users have to rely on that status. The only way that happens is if the status is accurate far more often than it is wrong. That won't happen unless everyone is rigorous with making status changes... and that's not a memo I want to send. Lync/Skype for Business (and I assume Teams) gives you both options. Let it run automatically and it'll switch your status when you receive/make a call, join a conference or have a meeting time blocked out in your calendar for you and put it back when you're done, or set it to what you want. And you could extend this capability[0] and automate it in different ways. [0] The old on-prem version was insanely customizable; you could completely re-implement the client, they provided every hook required to re-implement dial-in conferencing (an "Enterprise" feature) in Standard edition (and actively assisted in a project I worked to do just that).