I have a decentralized organization where each department has full authority to enter into partnerships with other organizations. We need a way to share information about our relationships with partners across different departments though, in order to make sure our approach to any one partner, even if that partner engages with multiple departments, is consistent.
Usually an organization uses a CRM and trains people to always log calls and messages with any organizational partner. However, I want to limit as much as possible the number of systems we need to use. Has anyone customized Discourse to serve as a lightweight CRM for organizational partners? And if so, how?
My current idea is to create a partners category where each partner is given one topic. The category will have a topic template that asks for information on each partner including which departments each partner is connected with. We then have people always search for a potential partner in that category first and read up on our history with that partner before reaching out if they’re interested in establishing a new relationship.
I’m struggling with how to make this behavior seamless though, and I’m wondering if there are other potential solutions that I haven’t considered, yet. Our current solution is also a google sheet that allows us to track each partner’s status in our partnership process and that allows us to go down the list quickly to make sure we’re keeping track of every one. We can also filter by department, which I’m not sure we can do if we move to this system.
That’s about what I was thinking. You could have teach department tag their topics with their department tag, so you could search by those. You can have discourse enforce that they choose a tag.
It’s a bit clunky, but the CRM systems I’ve (sort of seen) all seem worse (says the guy who makes his living with Discourse).
How do you systematize people keeping the information updated? Are there practices that everyone follows? And, what information is expected to be in the topic versus what isn’t?
I was considering this as an option, but each department already has its own category so I’m very reluctant to have the same exact names be tags as well. I’m wondering if there’s a way to somehow search the department category names within the partners category and have it generate a list of topics. Am I just over thinking it?
Can you make “partner” a tag rather than a category? In this case the main difference between the two might be that with tags you have less control of the landing/browsing experience on the category/tag page and in lists of categories/tags, but in your case this probably doesn’t matter.
This is always how it has been, so everyone knows to look for the topic with info on each customer and to also update that topic when necessary. There is also the pain of having to search multiple places to learn something, wanting to avoid that pain serves as incentive.
In addition to the above, some team members are in charge of customer relationship so as a community manager would help to rearranging posts in the community to the right place, they also do the same.
Basically, it is a habit that is already established so it is easy to keep it going.
This wouldn’t work for us because then the partner topic would have to live in one of our department categories when the whole point is that one partner could work with multiple departments at the same time. I think it definitely makes the most sense to have a separate partners category.
What tags do you use? I’m struggling most with the idea of having department tags when we have department categories. I’m also considering using our project status tags to track partners through idea stage to understanding phase, etc.
Good idea. What are the particular guidelines you enforce?
Deborah, reading your idea, which seems good, leads to me to suggest making the first post a “Wiki post”. To me, it would make more sense to have all the informations everyone needs, up-to-date in the first post, rather to have to read the topic (which can become lengthy after a while). You keep the topic for discussion and/or the adding of details, and report everything important in the first post.You “just” have to implement the right procedures for this to work.
Note: This is quite the way Discourse Team works here on meta with some topics. This seems a good way of doing it.
Humm, I guess that basically, Yes! That would be called … a search Isn’t it?
(Search the name of the department you want by restricting this search to the partners category)
We use one general tag to mark customer projects, and it all sits in a broader business category.
We don’t force or enforce anything in the normal sense. We are lucky to be a team where we all share similar values like proper communication and information arrangement. So it all just works.
I believe this is because everyone in the team has had some experience with communities, so they understand the need to keep everything properly sorted and structured.
I don’t know if this helps, but we made an ontology that weighted probabilities for a given set of specific needs or outcomes that allowed us to use a metadata tagging system as discussed by @JonathanShaw@pfaffman
Isn’t it?