Настройка OneDesk для поддержки нескольких продуктов или услуг

Это часть текущей серии статей, в которой я рассмотрю основные конфигурации учетных записей для различных типов бизнеса.

Есть много разных типов компаний, которые используют OneDesk для поддержки своих клиентов или конечных пользователей. Для каждой бизнес-модели есть несколько различных изменений конфигурации, которые вы захотите внести в свою учетную запись OneDesk. В этой статье рассматривается настройка, при которой вы хотите поддерживать несколько продуктов или услуг с помощью одной службы поддержки.

Если у вашей компании есть несколько различных продуктов / услуг, для которых вам необходимо предложить разную поддержку, вы захотите применить эту конфигурацию к своей учетной записи OneDesk.

В приведенном ниже примере я буду ссылаться на «ProductA» и «ProductB», но это также могут быть службы.

1. Создание разных типов билетов.

Важное решение №1.
Нужны ли мне билеты разных типов на разные продукты?

Предполагая, что вы хотите обрабатывать билеты для своих продуктов по-разному, вам может потребоваться включить разные типы билетов. Вы можете сделать это под
Администрация> Билеты> Типы билетов .
Включите «Показать скрытые типы», переключите некоторые типы на «видимые» и переименуйте их. У вас может быть до 10.

Однако, возможно, вам не потребуется иметь разные типы билетов для каждого продукта. Вместо этого вы можете добавить в билет настраиваемое свойство, чтобы определить, какой билет принадлежит какому продукту. У каждого подхода есть свои плюсы и минусы, читайте дальше, чтобы решить, какой подход лучше всего подходит для вашей ситуации.

2. Применяйте разные рабочие процессы к билетам для разных продуктов.

В той же таблице под Администрация> Билеты> Типы билетов щелкните ссылку «Управление статусами» рядом с каждым типом заявки, который вы сделали видимым. В появившемся всплывающем окне вы можете изменить различные статусы рабочего процесса, через которые может проходить каждый тип заявки.

Важно отметить, что если вы используете несколько типов заявок, каждый статус рабочего процесса не зависит от типа. (Другими словами, «открыто» для TicketType1 не совпадает со статусом «открыто» для TicketType2). Поэтому, если вы планируете использовать один и тот же рабочий процесс для всех ваших билетов, просто создайте один тип.

3. Добавление пользовательских свойств к вашим билетам.

3а. Если вы решили использовать только один тип билета для всех своих продуктов, вам понадобится настраиваемое поле, чтобы определить, к какому продукту относится билет.
Под Администрация> Билеты> Настраиваемые поля нажмите «Создать настраиваемое поле». Заполните форму следующим образом и нажмите «Создать».

Это создаст для ваших билетов настраиваемое свойство («Продукт»), которое позволит вам выбрать «ПродуктA» или «ПродуктB».

3b. Вы можете добавить в свои билеты другие настраиваемые поля в зависимости от ваших потребностей. Убедитесь, что «билеты» выбраны для типа элемента, на котором они должны отображаться, и убедитесь, что для проектов, в которых они должны отображаться, выбраны «все проекты».

4. Создайте разные формы клиентов для разных продуктов.

При отображении в OneDesk все ваши билеты будут отображать одни и те же свойства и иметь одинаковую форму создания. Но на клиентском портале (который вы размещаете на своем веб-сайте) вы можете иметь разные формы для каждого типа. Это полезно, если вы хотите задать разные вопросы по разным продуктам.

Под Администрация> Портал для клиентов> Формы выберите и нажмите «Создать форму» для каждого типа элемента, для которого вы хотите создать форму. По умолчанию уже создана базовая форма заявки. Вы можете удалить его или изменить по своему усмотрению. Любая созданная вами веб-форма будет доступна вашим клиентам.

Затем для каждой формы вы будете расширять ее и изменять в соответствии со своими потребностями. Все довольно просто, но вот некоторые детали, которые вы, возможно, захотите узнать.

  • Вы можете добавить в форму настраиваемые поля, но не забудьте сначала создать их.
  • Вы можете пометить как “обязательное” любое свойство, для которого нет значения по умолчанию. Если установлен значение по умолчанию, то это поле нельзя пометить как обязательное, поскольку оно всегда будет иметь значение. Поэтому удалите значения по умолчанию для настраиваемых полей, которые вам нужны.
  • Если вы добавите свойство «Проект» в форму, это позволит вашему клиенту указать, в какой проект отправить заявку. Появится подопция, позволяющая указать, в какие проекты они могут отправлять.

5. Автоматическое направление входящих заявок в нужную очередь / команду / проект.

Когда билеты приходят по электронной почте, через веб-форму или по любому другому каналу, OneDesk позволяет вам создавать правила для обработки этих входящих билетов. Эти правила обработки (часто называемые «помещением вещей в очереди») позволяют автоматически отвечать клиенту, запускать рабочий процесс, назначать команду или пользователя, помещать заявку в общий проект и отправлять уведомления.

Продолжая наш пример, мы создадим правила обработки либо для билетов типа ProductA, либо для билетов с настраиваемым полем «Продукт», установленным на ProductA. Под Администрация> Билеты> Автоматизация рабочего процесса вы найдете набор правил по умолчанию, которые выполняют различные действия с билетами. Я рекомендую вам убедиться, что вы правильно их понимаете, прежде чем отключать их (но их не так сложно понять). Следующие правила охватывают обработку новых заявок по умолчанию:

  • Опубликуйте их на портале для клиентов (оставьте это, пока не поймете публикацию)
  • Назначьте новые заявки на «образец SLA» (отключите это, пока не создадите свои собственные политики SLA)
  • Автоматический ответ на новые заявки (оставьте это, но при желании измените текст ответа)

Не трогайте других, пока не освоитесь с рабочим процессом.

Вот пример исчерпывающего правила обработки входящих билетов. Это не правило по умолчанию, а просто пример, показывающий вам, что возможно.

Это правило работает с билетами любого типа, в которых в настраиваемом поле «Продукт» установлено значение ProductA. Когда этот тикет будет создан, OneDesk создаст автоматический ответ от бота, поместит его в проект «Новые тикеты для ProductA» и назначит его команде «Поддержка клиентов».

 

6. Создание разумной структуры проекта.

Проекты в OneDesk – это контейнеры, в которых хранятся ваши заявки, задачи или другие элементы. Это также уровень, на котором вы делитесь своей командой. Когда вы создаете структуру своего проекта, первый вопрос, который вам нужно задать себе, заключается в следующем:

Важное решение # 2
Есть ли задачи или тикеты, которыми вы не хотите делиться со своей командой?
Если это так, то разделение того, что видит член команды, должно происходить на уровне проекта.

Другими словами…

  • Если вы хотите, чтобы Джилл видела задачу, а Боб не видел ее, тогда эта задача должна быть в проекте, к которому у Боба нет доступа.
  • Если Боб и Джилл работают над одним и тем же продуктом, то это нормально, если они могут получить доступ к одним и тем же тикетам и задачам. Затем вы можете сохранить элементы в одном проекте или поместить их в несколько проектов, которые доступны как Джилл, так и Бобу.

Приняв это решение, вы создаете свои проекты с учетом этого, а затем добавляете слои выше (портфолио) или ниже (папки), чтобы добавить больше структуры в вашу иерархию.

  • Портфолио похожи на папки, в которых хранятся проекты. Используйте их для группировки связанных проектов, например, по продукту / услуге, к которым они относятся, по клиенту, для которого они предназначены, или по отделу, к которому они относятся. Проект может находиться в нескольких портфелях одновременно, и вы можете вкладывать портфели так глубоко, как захотите.
  • Папки находятся внутри проектов и содержат предметы. Используйте их, чтобы группировать задачи, составлять связанные заявки в службу поддержки или что-то еще, что вы хотите организовать. Папки также могут быть вложены сколь угодно глубоко.

Итак, для моего примера мы могли бы получить такую структуру:

Вот у меня портфолио для ProductA. Inside создали проект по перехвату входящих заявок и еще одно портфолио, в котором хранятся проекты для каждого выпуска ProductA. Затем некоторые задачи группируются в папку внутри одного из выпусков.

 

7. Подключение всего этого к управлению проектами и задачами.

Последний кусок головоломки – человеческий аспект рабочего процесса. Вам нужно будет принять некоторые из следующих оперативных решений:

  • Кто занимается входящими билетами. Им может потребоваться ответить, назначить, расставить приоритеты и переместить их в разные проекты.
  • При каких обстоятельствах билет должен преобразоваться в задачу?
  • Кто планирует проекты и какие критерии используются?
  • Вы учитываете часы, отработанные над тикетами и задачами?
  • Какие взгляды нужны различным пользователям в компании для эффективного выполнения своей работы?
  • Гораздо больше…

По моему опыту, ответы на эти вопросы не являются критическими сразу, и их можно проработать и оптимизировать в течение первых нескольких дней и недель использования. Мы тоже здесь, чтобы помочь, так что свяжитесь с нами!

 

Scroll to Top