Ich habe eine dezentrale Organisation, in der jede Abteilung die volle Befugnis hat, Partnerschaften mit anderen Organisationen einzugehen. Wir benötigen jedoch eine Möglichkeit, Informationen über unsere Beziehungen zu Partnern abteilungsübergreifend zu teilen, um sicherzustellen, dass unser Umgang mit jedem einzelnen Partner – selbst wenn dieser mit mehreren Abteilungen zusammenarbeitet – konsistent ist.
Normalerweise nutzt eine Organisation ein CRM und schult die Mitarbeiter, Anrufe und Nachrichten mit jedem Organisationspartner stets zu protokollieren. Ich möchte jedoch die Anzahl der zu verwendenden Systeme so weit wie möglich begrenzen. Hat jemand Discourse bereits als leichtgewichtiges CRM für Organisationspartner angepasst? Und wenn ja, wie?
Meine aktuelle Idee besteht darin, eine Kategorie „Partner
Das entspricht ungefähr meiner Vorstellung. Die Lehrabteilung könnte ihre Themen mit dem entsprechenden Abteilungs-Tag versehen, sodass man danach suchen könnte. Discourse könnte vorschreiben, dass ein Tag ausgewählt wird.
Es ist etwas umständlich, aber die CRM-Systeme, die ich (sozusagen) gesehen habe, scheinen alle noch schlimmer zu sein (sagt derjenige, der seinen Lebensunterhalt mit Discourse verdient).
Wie stellt ihr sicher, dass die Informationen aktuell gehalten werden? Gibt es Praktiken, die alle einhalten? Und welche Informationen sollen im Thema enthalten sein und welche nicht?
Ich habe diese Option in Betracht gezogen, aber jede Abteilung hat bereits ihre eigene Kategorie, daher bin ich sehr zögerlich, dieselben Namen auch als Tags zu verwenden. Ich frage mich, ob es eine Möglichkeit gibt, die Namen der Abteilungskategorien innerhalb der Partnerkategorie zu durchsuchen und eine Liste von Themen zu generieren. Übertreibe ich es da vielleicht nur?
Kannst du „Partner“ als Tag und nicht als Kategorie einrichten? In diesem Fall könnte der Hauptunterschied zwischen beiden darin bestehen, dass du bei Tags weniger Kontrolle über das Landing-/Browsing-Erlebnis auf der Kategorie-/Tag-Seite und in den Listen der Kategorien/Tags hast. In deinem Fall spielt das wahrscheinlich jedoch keine Rolle.
So war es schon immer, und daher weiß jeder, dass er nach dem Thema mit Informationen zu jedem Kunden suchen und dieses bei Bedarf auch aktualisieren muss. Hinzu kommt der Ärger, an mehreren Stellen suchen zu müssen, um etwas zu erfahren; das Vermeiden dieses Ärgers dient als Anreiz.
Darüber hinaus sind einige Teammitglieder für die Kundenbeziehungen zuständig. Als Community-Manager helfen sie dabei, Beiträge in der Community an den richtigen Ort zu verschieben, und sie erledigen dasselbe.
Im Grunde ist es eine bereits etablierte Gewohnheit, die sich daher leicht aufrechterhalten lässt.
Welche Tags verwendet ihr? Mir fällt es am schwersten, mich mit der Idee von Abteilungs-Tags abzufinden, da wir bereits Abteilungs-Kategorien haben. Ich erwäge zudem, unsere Projektstatus-Tags zu verwenden, um Partner von der Ideenphase über die Verständnisphase usw. zu begleiten.
Gute Idee. Welche speziellen Richtlinien setzt ihr durch?
Vielleicht ist das der Punkt, an dem wir Kompromisse eingehen müssen. Wenn du diese in eine Tag-Gruppe einordnest, könntest du sie vielleicht außerhalb der Kategorie „Partner
Wir verwenden einen allgemeinen Tag, um Kundenprojekte zu kennzeichnen, und alles befindet sich in einer übergeordneten Geschäftskategorie.
Wir erzwingen oder durchsetzen im eigentlichen Sinne nichts. Wir haben das Glück, ein Team zu sein, in dem wir alle ähnliche Werte wie eine angemessene Kommunikation und eine gute Informationsstruktur teilen. Daher funktioniert alles einfach.
Ich glaube, das liegt daran, dass jeder im Team bereits Erfahrung mit Communities gesammelt hat und daher versteht, wie wichtig es ist, alles ordentlich sortiert und strukturiert zu halten.
Oder erstellen Sie einfach Tags, die nicht verwechselt werden können, wie crm-<client-name>, die auf die CRM-Kategorie beschränkt und dort erforderlich sind.
Ich weiß nicht, ob das hilft, aber wir haben eine Ontologie erstellt, die Wahrscheinlichkeiten für einen gegebenen Satz spezifischer Bedürfnisse oder Ergebnisse gewichtet hat. Dies ermöglichte uns die Verwendung eines Metadaten-Tagging-Systems, wie von @JonathanShaw und @pfaffman diskutiert.
