Искания със задачи и одобрение

„Постъпва нов колега“ не е една заявка. Това са лаптоп, два профила, телефонен вътрешен номер и може би достъп отвън. Всяка част принадлежи на различен екип, а вие пак искате един случай, който ви казва докъде са нещата.

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

Искането не е второ нещо за поддържане. То живее върху шаблон за заявка: под „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“.

Всеки ред показва името на задачата, номера на нейната заявка, екипа и изпълнителя, а името е връзка към тази заявка.

„Готово“ идва от статуса на заявката, а не от отделна отметка. Каквото се брои за затворено в списъка със заявки, се брои за готово и тук — два начина за броене на едно и също рано или късно биха се разминали.

Блокът се появява само в искане. Обикновена заявка не го показва.

Когато специализиран екип затвори своята заявка, неговият „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“ и се появява само докато искането е открито.

Само администратор може да прави това. Оператор, който би могъл да преразпределя, би могъл да преразпредели към себе си и после да реши.

Преразпределянето създава нова връзка, а старата умира веднага — дори ако някой я е препратил.

Самото преместване се появява в същия списък: кой го е преместил, кога, от кого към кого.

Никой не може да реши от чуждо име. Връзката е единственият път, а кой я е получил, е записано при случая.