Поскольку к настоящему времени я помог создать сотни учетных записей OneDesk, клиенты и другие члены нашей команды часто спрашивают меня, какие «передовые практики» следует соблюдать для обеспечения успеха клиентов. Так как я всегда рад поделиться своей мудростью 🙂 Я подумал, что было бы полезно написать сообщение в блоге, в котором будут освещены некоторые извлеченные уроки.
1) Импорт списка клиентов часто не нужен
OneDesk поддерживает возможность импорта списка клиентов, а также существующих билетов. Если вы хотите сделать это, действуйте, но вот два соображения.
– OneDesk будет автоматически создавать для вас записи о клиентах всякий раз, когда он получает электронное письмо с нового адреса электронной почты. Это означает, что вы можете просто позволить клиентским записям накапливаться по мере того, как ваши клиенты отправляют билеты.
– Если вы планируете импортировать существующие билеты, убедитесь, что вы в первую очередь импортируете своих клиентов. Это связано с тем, что, когда процесс импорта создает билет, он может связать его с существующей записью клиента (до тех пор, пока адрес электронной почты запрашивающего находится в столбце в файле билета).
2) Не ставьте задачу, когда достаточно статуса рабочего процесса
Эта рекомендация зависит от ситуации, но если у вас есть ряд шагов, которые должна пройти задача, и эти шаги исключают друг друга, тогда статус – это лучший способ. Иногда возникает соблазн создать список задач, который вместо этого можно было бы представить как одну задачу с разными статусами. Есть над чем подумать.
3) Предоставьте пользователям максимально возможный уровень разрешений для проекта.
OneDesk предоставляет вам довольно мощные средства управления разрешениями как на уровне организации, так и на уровне проекта. Это потому, что пользователю может быть разрешено делать определенные вещи в одном проекте, но не в другом. Тем не менее, я рекомендую, чтобы для разрешений на уровне проекта вы предоставили каждому наивысший уровень, который вам удобен (это означает «руководитель проекта» или «руководитель проекта»). Если вы этого не сделаете, будьте готовы отвечать на вопросы пользователей о том, почему они не могут что-то сделать, и тратить время на изменение отдельных разрешений в отдельных проектах.
5) Используйте типы с умом
Когда пользователи открывают для себя нашу удивительную систему типов, они часто сходят с ума и создают типы предметов и проектов для всех своих случаев. Наверное, это не лучший подход.
– Вам следует создавать новый тип элемента только тогда, когда вам требуется другой рабочий процесс. Например, если «проблема» проходит через несколько этапов, отличных от «задачи», тогда непременно создайте новый тип элемента. Однако, если оба выполняют одни и те же шаги, вы добавляете сложность только для того, чтобы иметь другой значок.
– Наличие разных типов проектов – это обычно ненужный. Наличие разных типов портфелей почти всегда ненужный. Вышеупомянутое правило для элементов применимо также к проектам и портфелям, но с добавлением дополнительных моментов, у проектов еще меньше шансов иметь разные рабочие процессы, а портфели даже не имеют возможностей рабочего процесса.