Managing high number of private messages

planned

(OG) #1

Hello,

I’d like to bring this topic into attention and ask about your management methods for Private messages that could help me organize my PMs better. And maybe I’ve just missed something…

I find current PM organization very chaotic. I receive single digit number of new messages everyday.

Problem 1. Searching of relevant messages to follow-up

There are only avatars instead of usernames and search feature doesn’t allow searching for usernames. So unless I know some keyword that was used in that message I’m forced to scroll down and search for it manually. Many times without success because users change avatars time to time.

Problem 2. Removing PMs

I know that there is Archive feature. But unless I’d archive 99% of received messages and kept only those valuable I don’t think it helps me with organizing PMs better. I’d prefer to have ability to delete message (to get rid of all clutter) and use Archive only for messages that I’ve dealt with and will need them for further reference (or followup).

I think that custom folders for PMs would help massively (at least to organize templates or important need-to-follow-up messages)

What is your opinion or your work flow?


#2

It is on our roadmap to add tags to PMs which will mean you’ll be able to sort them like you can with labels in gmail. That should help with your organisation.


(Tobias Eigen) #3

Tagging PMs will be a huge boon so I hope this is coming soon.

But it’s not pressing since it’s only really an issue for moderators/staff, not regular members, luckily.

In terms of my workflow. I recently went through the whole backlog of staff messages - it took me a few hours a day for a week but I succeeded and felt good afterwards. :rocket: Now I try to stay on top of them on a daily basis and use the ARCHIVE link liberally to get out of sight those messages that have no reply from a member or don’t need handling. I prioritize those messages that have been replied to by members.

I also make liberal use of the ASSIGN feature to assign messages to colleagues or to myself that I don’t want to deal with right now and then hit ARCHIVE.

And finally, I use the TIMER feature so I can be reminded later about messages that I want to make sure I follow up on.

Oh, I almost forgot. As part of this cleanup I invited the @moderators group to all staff messages and make sure moderators are included in future. This helps separate my personal messages from staff messages, which often need special handling, because when a group I’m in is included in a message it does not show up in my own messages inbox/archive. It’s only in the group inbox/archive.

Also, I rename personal messages all the time to add member specific details to them or to add statuses (e.g. UNDERWAY or DONE), and then search for those keywords.


(OG) #4

Great… Thanks for replies…

One more idea: what about allowing to Bookmark PMs… That would really help me to quickly find answers to FAQ.

BTW is there any reason not to allow deleting of PMs? On our site they used probably more than public topics. I mean that could be some burden on the database. I’d really like to prune old PMs after say 3 years.


#5

Paper trails.

There isn’t really anything stopping you from deleting them from the database.


(Kane York) #6

Deleting a PM deletes it for all participants - you’re deleting the record that the requester has of the conversation.


(Tobias Eigen) #7

Bookmarking PMs is allowed. It’s the first exercise in the discobot new user tutorial.

That said, it’s not possible to distinguish between bookmarked topics and messages, so it’s probably not useful for organizing messages.

To be honest, I don’t find bookmarking of topics that useful to me… I never go back to my bookmarks list. Maybe I could repurpose it as a list of messages I need to keep an eye on. But in any case tagging messages will be much better.


(Sam Saffron) #8

This is on the roadmap, we will get there, not slotted to a release yet.


(Jay Pfaffman) #9

Unless you have hundreds of thousands of them, they are likely not a burden on the database.