Расчет качества службы поддержки

Теория и практика мотивации персонала Service Desk, или Как стимулировать и оценить работу аналитика первой линии технической поддержки...

Теория и практика мотивации персонала Service Desk, или Как стимулировать и оценить работу аналитика первой линии технической поддержки

Основной целью Service Desk — центральной службы технической поддержки — является предотвращение сбоев в работе ИТ-инфраструктуры предприятия, выявление предпосылок возникновения проблем и принятие упреждающих мер, направленных на предотвращение сбоя или хотя бы минимизацию его отрицательных последствий.

Любому современному предприятию, которое использует информационные технологии, необходима центральная служба технической поддержки (ЦСТП). В настоящее время чаще всего ее роль играет системный администратор, которого все дергают по делу и без дела. В результате он становится мальчиком для битья, эффективность его работы снижается: с одной стороны, его «бьют» пользователи, а с другой — руководители, причем все вместе требуют результатов.

Если же работа ЦСТП организована правильно, среди остальных сотрудников распространяется убежденность, что в ЦСТП работают очень квалифицированные, разноплановые, разносторонние люди, и к ним имеет смысл обращаться по самым разным вопросам, не ограничиваясь только информационными технологиями. Центральная служба технической поддержки становится «единым окном» для обращения пользователей по всем вопросам, связанным с информационными технологиями (и не только с ними).

Рис. 1. Структура ЦСТП

Структура ЦСТП напоминает луковицу (рис. 1). Ее сердцевина — программно-аппаратный комплекс, называемый центром обработки вызовов, который обеспечивает грамотное распределение заявок. Например, для этих целей может применяться решение IP Contact Center компании Cisco Systems. Вокруг него строится так называемый Help Desk. Это не ошибка: Help Desk отличается от Service Desk тем, что участвует только в одном процессе — в управлении инцидентами. Соответственно, задачи Help Desk — зарегистрировать инцидент и как можно быстрее восстановить нормальную работу сервиса самостоятельно либо привлечь группу специалистов второго уровня для полного устранения причины инцидента.

Но мы должны не только «тушить пожары», но и предупреждать их. Мы должны оказывать бизнесу дополнительные услуги. Именно этим и занимается ЦСТП (Service Desk) как структурное подразделение.

Кадры решают все

Как найти нужных людей для работы в ЦСТП, какими они должны быть? Как совершенствовать тех, кто приходит в отдел кадров? И самое главное: как удержать созданные кадры?

«Входные» требования очень простые. Это должен быть достаточно молодой человек, который хочет развиваться, очень желательно, чтобы он имел высшее образование. Наиболее важным фактором являются высокие коммуникативные навыки кандидата. Я скорее возьму открытого, радостного пятикурсника, нежели угрюмого ИТ-специалиста, уже получившего диплом.

Для аналитика ЦСТП необходимейшее качество — способность работать в условиях постоянного стресса, умение «держать удар», конструктивно подходить к решению задачи, корректно отвечать на претензии и обвинения фразой «Я понимаю, что вам сейчас тяжело, что у вас сейчас большая проблема, помогите мне, чтобы я смог помочь вам...». Это то, что называется ассертивностью — уверенная настойчивость, способность из всего потока «негатива» выделить полезную информацию, использовать ее, не принимая негатив близко к сердцу (чего многие люди делать не умеют). Для наших аналитиков мы проводим курсы, которые позволяют развить такое умение. Ведь от того, какую часть подобных заявок ЦСТП сможет принять, отфильтровать и не пропустить на второй уровень, существенно зависит эффективность работы этой службы.

Второе необходимое качество — это умение работать в команде. Нужны не «звезды», а люди, которые могли бы работать вместе. Бывали случаи, когда приходивший человек говорил: «Я — хороший специалист». Да, он выполнял огромное количество заявок, но... Спустя некоторое время выяснялось, что его работа команде была не нужна, так как он выбирал самые легкие заявки и быстро их закрывал, а остальные сотрудники по несколько часов решали наиболее сложные задачи. В команде возникало естественное недовольство.

Третьим из важнейших личных качеств является дисциплинированность, чтобы у всех, кто связан с человеком по работе, была уверенность в том, что он придет в нужное время и займется своим делом. Или хотя бы заранее предупредит, что не сможет придти (все мы иногда болеем, у нас может быть неисправен водопровод в доме и т. д.). Но если сотрудник не предупредил об этом за час-два до начала работы, чтобы его можно было заменить, то возникает «провал» в обслуживании. Такова уж специфика первого уровня.

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

Таким образом, штат службы составляют молодые специалисты, которые еще не имеют узкой специализации.

Карьера

Подразделение системных решений департамента информационных технологий «Крок» занимается решениями на базе программного обеспечения. Последние двенадцать лет оно существовало в виде группы системных инженеров. Основным требованием к отбору в эту группу было наличие сертификата Microsoft Certified Systems Engineer (MCSE). Однако, как показал опыт, такая политика пользы не приносит: часто приходят высоко квалифицированные, очень толковые специалисты, но без соответствующего статуса. Возможно, они просто не могли заплатить за экзамен. Но ведь компании нужен не диплом, а квалифицированный сотрудник!

В созданной несколько позже группе инженеров технической поддержки входным уровнем стал сертификат Microsoft Certified Professional (MCP) — самый низкий, базовый статус Microsoft. Если у соискателя такого статуса нет, ему предлагается во время испытательного срока сдать соответствующий экзамен, подготовившись к нему самостоятельно.

Развиваться дальше в направлении технической поддержки сотрудник может в ЦСТП, аналогичных службах заказчиков, рабочих группах управления рабочими местами или станциями (Desktop Management), выделенных группах поддержки ИТ-услуг.

Если сотрудник группы инженеров технической поддержки дорос до статуса MCSE, то дальше держать его в ЦСТП нельзя — интерес к работе будет потерян. Пройдя «школу» первого уровня, сотрудник четко понимает, как организована служба, какие бывают ИТ-услуги, как решаются инциденты, как строятся и как работают группы технической поддержки. В дальнейшем его более целесообразно использовать как технического менеджера, технического консультанта либо менеджера проекта.

Обучение

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

Если же в проекте аналитику требуются какие-то специальные знания (например, о работе с продуктом HP OpenView Service Desk), ему будет предоставлено дополнительное обучение.

Анализируя информацию, полученную от 47 человек, я, как руководитель направления технической поддержки и аутсорсинга, принимаю решение, стоит ли указанному человеку, учитывая его историю развития, планировать данный курс или экзамен. (Кстати, если экзамен не был сдан с первого раза, то в следующий раз сотрудник оплатит его самостоятельно — это стимулирует его тщательнее готовиться к сдаче.) После того, как приняты принципиальные решения, план уточняется с учетом предполагаемого распределения ресурсов по проектам и затем направляется руководителю департамента ИТ для того, чтобы тот оценил, может ли компания потратить средства на развитие отдельных направлений навыков и знаний специалистов поддержки.

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

Критерии оценки

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

Субъективные

К субъективным критериям относятся персональная отдача от данного сотрудника и его активность, инициатива, энтузиазм. Нужно понимать, что субъективизм в оценке — это не очень правильно, и для того чтобы его избежать, существует вторая группа критериев.

Объективные

Первый из таких объективных критериев — стоимость сотрудника на рынке труда. Я уверен, что достаточно хорошо знаю, сколько сегодня стоит специалист определенной направленности. В этом мне помогает департамент управления персоналом, сотрудники которого хорошо знают, что происходит на рынке. Контролировать ситуацию можно, анализируя среднее время, которое приходится потратить, чтобы подобрать на работу в нашу компанию специалистов по открывшимся вакансиям. Если оно увеличивается, то нужно определить причину, почему люди не идут в компанию, что их не устраивает (условия работы, зарплата, социальный пакет или что-то иное).

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

Третий объективный критерий — наличие сертификатов и статусов. Стараниями департамента управления персоналом я всегда имею информацию о том, сколько на рынке труда стоят специалисты, имеющие различные статусы, и могу предложить им соответствующий компенсационный пакет, чтобы они не оглядывались по сторонам и при этом развивались в нужной нам области.

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

Измерение по ITIL

Наша центральная служба технической поддержки построена на основе процессов и рекомендаций ITIL/ITSM. В рамках ITSM и процесса управления уровнем услуг (Service Level Management, SLM), важно понять, насколько уровень, предоставляемый ЦСТП, соответствует оговоренному в соглашении об уровне услуг (Service Level Agreement, SLA). У нас заключены такие соглашения не только с внутренними пользователями, но и с внешними заказчиками (на обслуживании у нас находится более 3 тыс. их подразделений).

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

Количественные показатели

Первый показатель — это выполнение SLA по времени реакции. Выполнение этого соглашения ложится на конкретного сотрудника ЦСТП. Количественно оценить, насколько качественно сотрудник это соглашение выполняет, можно, зафиксировав промежуток времени между регистрацией инцидента и назначением ответственного лица, которое будет заниматься выполнением данной заявки.

Если оператор не может выполнить заявку на своем уровне, он обязан передать (эскалировать) ее на второй уровень. Для этого он использует схему эскалации заявок по данной услуге, которая существует на портале в электронном виде. Если он выполняет ее самостоятельно, то заявка назначается на него самого, аналитика ЦСТП, и время реакции в этом случае минимально. Но если аналитик считает, что он плохо представляет, о чем идет речь (например, если это новый сервис Citrix, о котором ему пока ничего неизвестно), он вынужден эскалировать эту заявку на второй уровень.

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

Этот показатель рассчитывается как для группы в целом, так и для каждого аналитика в отдельности. Если групповой показатель не удовлетворяет требованиям SLA, то в этом случае и персональный считается невыполненным. Это и есть работа в команде.

Второй показатель — выполнение SLA по времени решения. Как и в случае со временем реакции, для заявок по конкретной услуге задается максимальное время выполнения (например, 48, 24, 12, 8, 4 и 1 час для заявки, имеющей наибольший приоритет).

ЦСТП отвечает за время выполнения заявок на первом уровне. Например, если заявку невозможно выполнить на первом уровне в течение пятнадцати минут, то сколько бы времени ни требовалось для завершения процесса — пять минут, десять, двадцать, — аналитик обязан эскалировать ее на второй уровень, потому что иначе ЦСТП станет недоступной.

Третий критерий — доступность ЦСТП. Доступность рассчитывается, исходя из статистики, получаемой из центра обработки обращений. Например, мы для себя можем сделать вывод, что больше трех гудков человек ждать не будет. По информации из центра обработки обращений всегда можно проследить, какой процент телефонных звонков был принят в течение первых трех гудков. Существует несколько десятков показателей доступности, но основным у нас является следующий: доля людей, которые звонили к нам и дозвонились до ЦСТП. По каким причинам они не дозвонились, сколько времени ждали свободного оператора, как мы эскалировали их заявки — это все вторично.

Наконец, четвертый критерий — число разрешений при первом обращении (First Contact Resolution, FCR), когда заявки выполняются на первом уровне технической поддержки. В соответствии с приоритетом, который руководство выставляет по определенным видам услуг, мы стараемся повышать этот показатель по каждой из услуг.

К сожалению, разработчики нечасто заботятся о том, чтобы обучить аналитиков ЦСТП. Возникающий в этом случае поток заявок проходит через службу, где все заявки регистрируются, классифицируются, но при этом работать все равно приходится инженерам рабочих групп второй линии.

С другой стороны, есть услуги, по которым невыгодно повышать FCR. Например, поддержка системы Documentum обходится очень дорого. Этим могут заняться специалисты второй линии: заявок там не очень много, и я вполне согласен жить с 5% FCR по Documentum.

Командный зачет и коэффициент индивидуального участия

Каким же образом можно оценить качество работы отдельного сотрудника в группе?

Каждый человек обладает определенной «дистанцией зрения» (насколько далеко он может видеть поставленную цель). Зрелый человек способен ставить себе задачу на один-два года вперед. («Я хочу заниматься тем-то, я готов потратить несколько лет, например, на получение второго высшего образования, потому что это позволит мне...» и т. д.) Это уровень стратегического мышления. В возрасте 25-30 лет человек способен видеть цель на расстоянии от нескольких месяцев до года. В ЦСТП работают очень молодые люди — в среднем от 20 до 25, и, соответственно, уровень стратегического мышления у большинства из них пока очень низок.

Менеджер проекта может получать премию в конце года по итогам работы за год. Технический менеджер — каждые три-четыре месяца в соответствии с контрольными точками. Для аналитиков ЦСТП, учитывая их возраст, опыт и уровень стратегического мышления, необходимо понизить эту периодичность до одного месяца. Но критерии всегда остаются неизменными: время реакции, время решения, FCR и доступность службы.

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

Рассмотрим, например, работу аналитика ЦСТП (Service Desk Analyst 1, SDA1) . Этот оператор в течение месяца зарегистрировал 353 заявки, из них выполнил 287. Показатель FCR в данном случае составил 81,30%. Пусть выполнение аналитиком SLA по времени реакции составляет 96,21%, по времени решения — 98,79%, а персональная доступность аналитика SDA1 — 92,36%.

На основании статистики, полученной за месяц работы ЦСТП, строится сводная таблица показателей работы группы (см. табл.) и определяются кандидаты на премирование. При расчете необходимо учитывать условие, что премирование, причем только первой тройки, возможно лишь в случае, если значения четырех основных метрик для группы в целом не будут ниже значений, согласованных в SLA.

Коэффициент персонального участия (Pn) рассчитывается следующим образом:

Pn = (Xn/X0 + Yn/Y0) * R0 * D0,

где

Xn — количество заявок, принятых аналитиком SDAn;

X0 — общее количество заявок, принятых группой;

Yn — количество заявок, выполненных аналитиком SDAn;

Y0 — общее количество заявок, выполненных группой;

R0 — процент выполнения SLA по времени реакции в среднем по группе;

D0 — процент выполнения SLA по времени решения в среднем по группе.

Таким образом, коэффициент персонального участия для аналитика SDA1 составит

P1 = (X1/X0 + Y1/Y0) * R0 * D0 = = (353/2943 + 287/2161) * 0,9539 * * 0,9658 = 0,2328.

Пусть в SLA согласованы следующие критерии:

FCR0 > 65% — процент выполнения SLA по FCR в среднем по группе;

R0 > 95% — процент выполнения SLA по времени реакции в среднем по группе;

D0 > 95% — процент выполнения SLA по времени решения в среднем по группе;

A0 > 90% — процент выполнения SLA по доступности в среднем по группе.

Рисунок 2. Диаграмма отношений персональных коэффициентов

Значение средней доступности по группе используется только в качестве порогового значения (например, если A0 < 90%, то считаем контрольную точку не пройденной, и никто из проектной команды премии не получает). Пороговое значение каждого критерия, заложенного в SLA, должно быть согласовано с руководством. Данная формула не претендует на академичность, она была разработана совместно с операторами ЦСТП нашей компании.

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

Эффект

Взяв в расчет количество времени, которое потратила ЦСТП и сэкономила вторая линия технической поддержки (и тем более третья, которая стоит еще дороже), а также стоимость специалистов, можем определить эффективность работы ЦСТП.

Вкладывая средства в мотивацию специалистов первой линии, мы повышаем эффективность работы ЦСТП, выполняем условия по внешним контрактам, экономим время специалистов второй и третьей линий. Мы оперируем двумя суммами, которые показываем руководству: размерами инвестиций и достигнутой экономией. Конечно, служба технической поддержки сама непосредственно денег не зарабатывает, не заключает контракты. Тем не менее деньги, которые были здесь сэкономлены, могут идти на мотивацию аналитиков и на функциональное развитие службы.

Александр Сапронов — руководитель направления технической поддержки и аутсорсинга компании «Крок», ASapronov@hotmail.com

Уровни эскалаций

Техническая поддержка как процесс может иметь несколько уровней, но обычно их три.

Первый уровень — это сама центральная служба технической поддержки, она же Service Desk. Сюда со своими проблемами обращаются все пользователи, и попытки обратиться напрямую к инженерам пресекаются. Это нужно, чтобы получать статистику, которая позволяет спрогнозировать возникновение проблем и устранить их предпосылки еще до того, как они окажут воздействие на бизнес.

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

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

Переход инцидента на очередной уровень технической поддержки означает увеличение времени и стоимости его разрешения. Разумеется, следует стремиться к тому, чтобы больше инцидентов решать уже на первом уровне, где специалисты хотя и квалифицированные, но все-таки значительно более дешевые, чем, например, специалисты группы поддержки из компании Cisco Systems.

Одним из количественных показателей деятельности ЦСТП является объем разрешений инцидентов при первом обращении. Если, например, этот показатель в отношении технической поддержки продуктов компании N в этом месяце составил 60%, это значит, что 60% заявок было выполнено специалистами первого уровня и только 40% ушло на второй. Возможно, что затем 1— 3% было передано в саму компанию N.

Можно выделить два вида эскалаций — функциональную и иерархическую. Функциональная эскалация — это передача инцидента из ЦСТП на вторую линию поддержки при невозможности устранения инцидента на первой. При функциональной эскалации растет количество, а иногда и качество вовлекаемых ресурсов.

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

FCR на практике

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

В 1999 году я участвовал в проекте создания ЦСТП на площадке нашего заказчика. В качестве операторов первой линии были использованы девушки, которые прекрасно говорили по-английски, обладали приятными голосами, а потому общаться с ними было одно удовольствие. Однако в информационных технологиях девушки ничего не понимали.

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

После неприятного разговора с представителем заказчика девушек с первой линии заменили специалистами, имеющими как минимум сертификат MCP.

Как управляют FCR

Рассмотрим пример поддержки новой ИТ-услуги в течение года, с января по декабрь (см. рисунок). В самом начале FCR может иметь значение от 0 до 15%, так как опыта его поддержки в ЦСТП еще нет. Получается, что на первых порах задействованы в основном специалисты второй линии, инженеры, разрабатывавшие услугу, а это всегда медленнее (они больше заняты) и дороже (с учетом стоимости их рабочего времени).

Рисунок. Изменение FCR

С марта по май показатель FCR прекратил свой рост. В этот момент менеджер ЦСТП обязан проанализировать заявки, которые были отданы на второй уровень, на предмет того, почему они не были решены на первом, и составить список причин. Например:

• у аналитиков не было прав администратора системы, и они не могли сами создать учетную запись нового пользователя, а 15% заявок были как раз по созданию новых пользователей; следовательно, нужно согласовать с менеджером этого проекта возможность выдачи необходимых и достаточных прав аналитикам ЦСТП;
• требовалось записать определенное количество компакт-дисков с новой версией ПО (10% заявок), а привод CD-RW отсутствовал, следовательно, необходимо согласовать с руководством приобретение такого привода;
• специалисты ЦСТП просто плохо знают систему, в результате чего 10% заявок были переданы на второй уровень в связи с нехваткой у аналитиков необходимых знаний, поэтому требуется обучение.

Далее менеджер ЦСТП подсчитывает затраты. Выдать права — это десять минут работы администратора системы, что при стоимости 30 долл. в час его работы составляет примерно пять долларов; пишущий привод стоит 50 долл.; для обучения требуется два часа работы специалиста второго уровня с оплатой 25 долл. в час, который придет в ЦСТП в день с низкой загрузкой либо вечером. В итоге, суммарная стоимость всех этих улучшений составит 105 долл. Представим результаты в виде таблицы.

Разница в стоимости решения заявок на первом и втором уровнях составила 5250 долл.! Специалисты второй линии значительно дороже, потому что они заняты внедрением новых услуг, гораздо выгоднее их для этого использовать и дальше, не отвлекая на поддержку. Затратив всего 105 долл., указанную выше сумму можно сберечь.

Итак, передав аналитику права администратора на систему, купив пишущий привод и обучив людей, можно через некоторое время поднять показатель FCR до 50%. Таким образом, у менеджера ЦСТП есть возможность динамически влиять на FCR, используя статистику по заявкам, решенным на второй линии.

Честная игра

Полученный файл с помесячной детализацией открыто рассылается всем аналитикам ЦСТП для проверки и анализа. В случае ошибки в расчете или в построении формулы я всегда готов выслушать и понять, почему это произошло, ведь каждый сотрудник должен четко понимать методику оценки его работы, она должна быть максимально прозрачна.

Конечно, это может привести к попыткам «подстроиться» под правила игры. Требуется количество заявок? «Набьем». FCR? Будем назначать на себя, не отдавать на вторую линию. Время решения? Будем закрывать, не спрашивая заказчика. Мы боремся с этим лукавством, у нас есть все инструменты для этого, мы знаем почти все лазейки. Например, действует правило, по которому ни одна заявка не может быть закрыта до тех пор, пока заказчик устно или письменно не подтвердил возможность ее закрытия. Это правило очень четко выполняется службой. Более того, аналитик ЦСТП не видит в списке статусов заявки статус «Закрыто». Последним в списке он может видеть статус «Ожидание разрешения на закрытие». В момент, когда заявка переводится в этот статус, автору заявки отсылается письмо примерно следующего содержания: «Номер заявки такой-то, решение вот такое, просим вас дать разрешение на закрытие заявки. Если вы согласны с предложенным решением, пожалуйста, нажмите вот сюда (дальше идет URL), если не согласны, пожалуйста, нажмите сюда (после чего отсылается письмо с нужными кодами, и система закрывает заявку автоматически)». Аналитик не имеет возможности закрыть заявку самостоятельно. Ее либо закрывает сам автор заявки, либо она закроется автоматически в течение 24 часов.