Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we’re betting against real-time team messaging

blog.doist.com

Post reply on HN
Print view View original

21–30 of 220 posts

Re: Why we’re betting against real-time team messaging

#21

Post by robbiemitchell »

We have seen many of these challenges over the years and set out to build something to help manage your team's incoming requests — directly in Slack. We find it's most used for internal assistance (one team supporting many) or as a way for B2B companies to provide support to their top customers.

The goal is to help your team be available and responsive without compromising productivity. To achieve this, incoming requests to a particular team are collected in a "feed" channel. The notifications ping specific people on rotation or on a sequence (according to rules) until claimed, the conversations are explicitly resolved with a "closed" action. We provide assistance for things like inserting knowledge base and template responses, and tagging the conversation. Integrations via Zapier mean a conversation can easily turn into an Asana task, Github issue, etc.

If you're struggling to manage the chaos, give it a shot and see whether it helps.

http://frame.ai/beta/

Re: Why we’re betting against real-time team messaging

#24

Post by pcarolan »

Apple took a step in the right direction with the do not disturb feature in the Notifications bar. When I don't want to be bothered, I turn it on, when I want to be chatty I turn it off. The next step should be apps that are aware of your do not disturb state and update your presence (as an option) when it's set. Then, I want a timer so I can get blasted with updates every 25 minutes like Pomodoro timer.

Re: Why we’re betting against real-time team messaging

#25

Post by d0m »

I like it. Basically the design choice was to focus on threads within channels, instead of simply channels. Slack has that thread feature but I never use it because it's hard to follow. I guess slack could copy them and have a "text mode" and a "thread mode", easily being able to switch between both, and then the threads will be much more useful.

Re: Why we’re betting against real-time team messaging

#26

Post by rovek »

This looks like a great tool, particularly the ground-up focus on threading and giving teams more options. As with its competitors, it can still easily become just another distraction when people use it wrong.

It's easy to see how you could design a "process" around using something like Slack to achieve the same experience and if you don't design a "process" for using Twist then it will suck just as much. We tried to heavily use channels in HipChat as a threading and noise-avoidance mechanism, it worked well but we often ended up with a lot of channels with the same people in; at which point discipline becomes stressed.

Re: Why we’re betting against real-time team messaging

#29

Post by peatmoss »

jwildeboer wrote: post #3

TL;DR they made a modernised version of an nntp client and server ;-)

alt.religion.slack > slack

Jokes aside, the article did hit the nail on the head in its critique of realtime comms. That said, there was always a subset of any team that seemed to have cold feet / anxiety / or other resistance to writing the longer-form messages of newsgroups.

I think if I had to pick between shallow, but broadly used comms, and slow but heterogeneously used comms, I'd still pick the latter.

Post reply on HN