Запросы с задачами и согласованием

«Выходит новый сотрудник» — это не одна заявка. Это ноутбук, две учётные записи, телефонный номер и, возможно, доступ снаружи. Каждая часть принадлежит другой команде, и при этом вы всё равно хотите одно дело, которое говорит, как обстоят дела.

Для этого и есть запрос. Это заявка, которая создаёт свои задачи в момент подачи, и каждая задача становится отдельной заявкой в той команде, которая ей занимается.

Запрос — это не вторая вещь, которую нужно вести. Он живёт на шаблоне заявки: в разделе «Settings → Request workflows» вы находите каждый шаблон заявки и привязываете задачи к одному из них.

Для каждой задачи вы заполняете несколько полей. «Task» — это название, которое читает заявитель, «Handled by» — это команда, которая её получает, а «Ticket title» и «What the team has to do» заполняют заявку, которая из неё выходит.

Несколько задач могут указывать на одну и ту же команду. Эта команда получит тогда несколько заявок, а не одну заявку со списком внутри.

Задача без команды не предлагается вовсе. Поле само об этом говорит: «Not assigned yet — this task is not offered». Так вы можете сохранить план, который ещё не закончен.

Над задачами стоит предложение, которое подводит итог всему плану: что создаётся как заводская настройка, сколько может изменить заявитель и кто это согласовывает. Измените настройку, и предложение перепишется само.

Перед «Ticket title» стоит постоянный текст «Parent ticket title -». Новая заявка начинается с заголовка запроса, за ним следует ваш заголовок, например «New colleague in accounting - Set up notebook and docking station». Так профильная команда видит, к какому запросу относится задача. Если вы оставите поле пустым, вместо него следует название задачи.

«Main category» и «Subcategory» заранее заполняют категорию новой заявки. Вы получаете только категории команды из «Handled by», потому что заявка создаётся именно там. Если вы смените команду, оба поля очищаются. Вы задаёте оба поля или ни одного, и если они остаются пустыми, заявка создаётся без категории.

Название запроса стоит над задачами. Карандашом рядом с ним вы его переименовываете. Название принадлежит шаблону заявки, поэтому оно меняется и в разделе «Settings → Templates», и в форме новой заявки.

Когда кто-то выбирает шаблон в форме новой заявки, появляется блок «What is needed?» с одной строкой для отметки на каждую задачу.

Видов три, и задаются они для каждой задачи. «Selectable, off by default» начинается пустым, «Selectable, on by default» начинается отмеченным и может быть снят, а «Always — cannot be deselected» выполняется всегда.

Задача, которая выполняется всегда, всё равно показывается, с пометкой «(always included)». Заявитель должен видеть, что происходит в любом случае.

Под блоком вы читаете, что из этого выйдет: «Each selected item becomes its own ticket for the team that handles it.»

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

Клиент видит тогда только свой запрос. Заявки в профильных командах остаются от него скрытыми, хотя его запрос их и создал: в этих заявках стоят учётные данные и внутренние заметки. Их внутренние заметки не появляются и в истории запроса. Когда профильная команда закрывает свою заявку, её вложения копируются в запрос со значком «Internal», и клиент их не видит и не скачивает.

Если запрос приходит по электронной почте, он становится обычной заявкой. Рабочий процесс вы тогда запускаете позже. Для этого служит кнопка «Start workflow» в шапке заявки.

В диалоге вы выбираете подходящий шаблон в поле «Template». Под ним появляется тот же блок «What is needed?», что и в форме новой заявки. Отметьте то, о чём просит запрос.

В поле «Title» вы правите заголовок заявки. С него начинаются заголовки задач. Ниже находятся дополнительные поля шаблона. Внесите туда данные из запроса. Обязательные поля отмечены звёздочкой.

После «Start» задачи создаются так же, как для запроса из формы. Если шаблону нужно согласование, заявка и её задачи остаются заблокированными, пока его не дадут.

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

На самом запросе задачи перечислены под заголовком «Workflow tasks», а рядом стоит счётчик, например «1 of 4 done».

Каждая строка показывает название задачи, номер её заявки, команду и исполнителя, а название является ссылкой в эту заявку.

«Done» берётся из статуса заявки, а не из отдельной отметки. Что считается закрытым в списке заявок, считается сделанным и здесь: два способа считать одно и то же рано или поздно разошлись бы.

Блок появляется только на запросе. Обычная заявка его не показывает.

Когда профильная команда закрывает свою заявку, её «Closing comment» приходит в запрос. Там он стоит как внутренняя заметка, а её первая строка называет номер и название задачи. Клиент эту заметку не видит.

Учётные данные и всё, что оператор запроса должен передать дальше, относятся в закрывающий комментарий. Все остальные комментарии профильной команды остаются в её собственной заявке. Если команда закрывает заявку без комментария, заметка не создаётся.

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

Настраивают это в разделе «Approvals» того же плана, а предложение над ним называет правило: «One approval covers the whole request. Add a second stage only when single tasks need their own release.» У каждой ступени пять полей: «Name» — название ступени, «Covers» говорит, к чему она относится, «Decided by» говорит, откуда берётся согласующий, «Approver» держит человека, а «Remind after (hours)» задаёт напоминание.

Согласующему учётная запись в системе заявок не нужна: вы вводите адрес электронной почты, и он решает по ссылке. Руководитель, который согласовывает дважды в квартал, поэтому не стоит места оператора.

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

Заголовком страницы служит название ступени. Она показывает номер и заголовок запроса, заявителя и под заголовком «This decision covers» те задачи, о которых идёт решение, а ниже поле комментария и две кнопки.

Ссылка не вечна, и страница называет срок: «Please decide by …». Она действует 14 дней. После этого страница говорит только, что ссылка недействительна или истекла, и администратор снова отправляет запрос кнопкой «Reassign».

Решение нельзя взять назад, и потом страница так и говорит: «A decision cannot be changed.»

Некоторым задачам нужно своё согласование. Доступ снаружи — это не то же самое, что ноутбук.

Для этого вы добавляете вторую ступень и выбираете её на задаче в поле «Extra approval». Пока там стоит «None — the request approval is enough», хватает согласования запроса. Обе ступени спрашивают одновременно, а не одну за другой. Ступень спрашивают, только если её касается одна из выбранных задач. Ступень для всего запроса спрашивают всегда.

Задача согласована, когда согласилась каждая касающаяся её ступень. Задача без собственной ступени начинается сразу, если только ступень для всего запроса ещё не ждёт. Тогда она начинается, как только запрос согласован.

До тех пор задача заблокирована. Её заявка стоит на «Waiting for approval», исполнителя нет. Вместо кнопок статуса на карточке написано «This ticket is waiting for approval and cannot be worked on yet.» Никакой путь не даёт ей исполнителя раньше этого.

Блокировка держится и для массовых действий в списке заявок. Выберите там такую заявку, и вы прочитаете причину: «This ticket is waiting for approval and cannot be worked on yet.»

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

Для каждой ступени можно задать напоминание, в часах.

Если ответа нет, через это время уходит то же письмо ещё раз, с той же ссылкой, что и первое. Кто сохранил первое письмо, может пользоваться и им.

Без напоминания запрос просто ждёт и не спрашивает снова.

Чего нет, так это согласования по истечении срока. Под полем это написано прямым текстом: «A request is never approved automatically. If nobody reacts, it keeps waiting.» Срок, который соглашается сам, был бы не согласованием, а формальностью.

Для отказа нужна причина. Без текста страница отказ не принимает.

Поле говорит, куда идёт текст: «Comment (required when you reject — the requester will see it)». Внутренняя заметка сюда не относится.

Заявитель получает письмо с причиной, и ему не приходится спрашивать, почему ничего не движется.

Для согласия причина не нужна. Это ожидаемый исход.

Если отказывает только вторая ступень, отказ касается только задач этой ступени. Остальной запрос идёт дальше.

Отклонённая задача получает статус «Rejected» и считается завершённой, поэтому запрос не висит вечно на том, что уже никогда не придёт.

Как только запрос отклонён, остальные согласующие больше не получают писем. Их ссылка тогда показывает «This request has already been rejected. Your decision is no longer needed.» В списке на заявке их ступень показывает «No longer needed: the request was rejected.»

На запросе раздел «Approvals» показывает по строке на ступень с согласующим, состоянием и, для открытого запроса, тем, как долго он уже ждёт.

После решения строка показывает, когда оно принято и с каким комментарием. Это и есть след для аудита, и он остаётся при деле.

Если согласующий в отпуске, администратор переводит запрос на другой адрес. Кнопка называется «Reassign» и появляется, только пока запрос открыт.

Делать это может только администратор. Оператор, который мог бы переназначать, мог бы переназначить на себя и потом решить.

Переназначение создаёт новую ссылку, а старая сразу умирает, даже если её кто-то переслал.

Сам перевод появляется в том же списке: кто перевёл, когда, от кого кому.

Никто не может решить от чужого имени. Ссылка — единственный путь, и то, кто её получил, записано при деле.