У меня есть децентрализованная организация, в которой каждое подразделение имеет полную власть заключать партнёрства с другими организациями. Однако нам нужен способ обмениваться информацией о наших отношениях с партнёрами между разными подразделениями, чтобы обеспечить последовательный подход к любому партнёру, даже если он взаимодействует с несколькими подразделениями.
Обычно организации используют CRM и обучают сотрудников всегда фиксировать звонки и сообщения с любыми партнёрами. Однако я хочу максимально сократить количество используемых систем. Кто-нибудь кастомизировал Discourse, чтобы он служил лёгкой CRM для учёта партнёров организации? И если да, то как?
Моя текущая идея — создать категорию «Партнёры», где каждому партнёру выделяется одна тема. В этой категории будет шаблон темы, запрашивающий информацию о каждом партнёре, включая то, с какими подразделениями он связан. Затем сотрудники будут сначала искать потенциального партнёра в этой категории, изучать нашу историю взаимодействия с ним, прежде чем выходить на связь, если они заинтересованы в установлении новых отношений.
Однако я затрудняюсь понять, как сделать такое поведение бесшовным, и задаюсь вопросом, не упустил ли я другие возможные решения. Наше текущее решение — это Google-таблица, которая позволяет отслеживать статус каждого партнёра в процессе партнёрства и быстро проходить по списку, чтобы убедиться, что мы контролируем всех. Мы также можем фильтровать по подразделению, и я не уверен, что сможем это сделать, если перейдём на новую систему.
Это примерно то, о чём я думал. Вы могли бы попросить отдел преподавателей помечать свои темы соответствующими тегами отдела, чтобы можно было искать по ним. Вы можете настроить Discourse так, чтобы он требовал выбора тега.
Это немного неудобно, но CRM-системы, которые я (в какой-то мере) видел, кажутся ещё хуже (говорит человек, который зарабатывает на жизнь с помощью Discourse).
Как вы систематизируете процесс обновления информации людьми? Существуют ли практики, которым все следуют? И какая информация ожидается в теме, а какая — нет?
Я рассматривал это как вариант, но у каждого отдела уже есть своя категория, поэтому мне не очень хочется дублировать те же самые названия в виде тегов. Мне интересно, можно ли как-то искать названия категорий отделов внутри категории «Партнёры» и генерировать на их основе список тем. Не слишком ли я усложняю задачу?
Можете сделать «Партнёр» тегом вместо категории? В таком случае основное различие между ними может заключаться в том, что с тегами у вас меньше контроля над опытом на странице категории/тега и в списках категорий/тегов, но в вашем случае это, вероятно, не имеет значения.
Так всегда и было, поэтому все знают, где искать тему с информацией о каждом клиенте, и при необходимости обновляют её. Кроме того, боль от необходимости искать информацию в разных местах служит стимулом её избежать.
Помимо этого, некоторые члены команды отвечают за взаимодействие с клиентами, поэтому, как менеджер сообщества, вы можете помочь переместить посты в сообществе в нужное место; они тоже это делают.
По сути, это уже устоявшаяся привычка, поэтому её легко поддерживать.
Для нас это не сработает, так как тема партнёра тогда должна была бы находиться в одной из наших категорий отделов, хотя суть в том, что один партнёр может одновременно работать с несколькими отделами. Я считаю, что наиболее логичным решением будет создание отдельной категории «Партнёры».
Какие теги вы используете? Больше всего у меня возникают трудности с идеей создания тегов для отделов, когда у нас уже есть категории отделов. Также я рассматриваю возможность использования наших тегов статуса проекта для отслеживания партнёров от стадии идеи до этапа понимания и так далее.
Отличная идея. Какие конкретные правила вы соблюдаете?
Дэбора, прочитав вашу идею, которая кажется мне хорошей, я предлагаю сделать первое сообщение «вики-сообщением». На мой взгляд, имеет больше смысла размещать в первом сообщении всю актуальную информацию, необходимую всем, вместо того чтобы заставлять читать всю тему (которая со временем может стать очень длинной). Оставляйте тему для обсуждения и/или добавления деталей, а всё важное переносите в первое сообщение. Вам «всего лишь» нужно внедрить правильные процедуры для этого.
Примечание: Именно так работает команда Discourse здесь на meta с некоторыми темами. Это кажется хорошим подходом.
Хм, я думаю, что по сути, да! Это называется… поиск Разве нет?
(Ищите название нужного отдела, ограничив этот поиск категорией «партнёры»)
Возможно, здесь нужно пойти на уступки. Если вы поместите их в группу тегов, возможно, вы сможете сделать их недоступными за пределами категории «Партнёры».
Мы используем один общий тег для обозначения проектов клиентов, и всё это находится в более широкой бизнес-категории.
Мы не навязываем и не требуем ничего в обычном понимании. Нам повезло работать в команде, где у всех схожие ценности, такие как грамотная коммуникация и структурирование информации. Поэтому всё работает само собой.
Я считаю, что это связано с тем, что каждый в команде имеет опыт работы с сообществами, поэтому понимает необходимость поддерживать всё в порядке и структуре.
Не знаю, поможет ли это, но мы создали онтологию, которая взвешивала вероятности для заданного набора конкретных потребностей или результатов, что позволило нам использовать систему мета-тегирования, как обсуждалось @JonathanShaw@pfaffman
Разве нет?