In general our workflow is to have 2 people in the org able to reply to tweets. And the rest of us are the peanut gallery just expressing what we think in the channel. So it works better to have it read-only in a single channel - at least for our purposes.
Right now we just see name, username, link and tweet. So it might be useful to unfurl that a little and show number of followers/following and give permissions to specific usernames to reply in-channel. Also create @channel or @username alerts when a twitter user has more than X followers - although I really hate that idea because I've seen people who (I'm pretty sure) buy followers bullying companies on twitter to get VIP treatment - but I guess that could be useful too.
It's a channel for every "conversation", not tweet. The benefit here is that you can keep talking to someone without asking them to email support@company.com.
There is usually a window of open channels -- 15 or 40, say, that remain active in parallel. Oldest channels outside the window get auto-archived. You can also favorite directly from Slack with "-sameroom <3".
That is one way of thinking about the world. Another way is to consider all software as support software. The machines are supposed to be there to help us.
There are countless players offering transactional support systems, and just like every other Big Software Vertical, the industry is still re-aligning around "Web 2.0". Desk's primary market distinction is that Salesforce owns them. (That's a huge selling point in the enterprise, but not necessarily interesting to the HN crowd.)
The grandparent post is describing a workflow for more conversational customer interactions. The industry term-of-art for this is something like multi-channel support, but Slack's Big Philosophy is to just be more playful. The "proper software" to use is the software that gets stuff done.
[0] shameless