Отдел поддержки бизнеса это

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

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

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

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

Фонд поддержки бизнеса — как это работает | Через край

Кто-то расширяет штат и под задачи техсаппорта нанимает новых специалистов. Но тут тоже не без подводных камней: нередки ситуации, квалифицированные сотрудники занимаются простыми проблемами, или наоборот, со сложными задачами один на один остаются люди, которым просто не хватает компетенций для их решения.

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

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

3 линии

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

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

Первая линия

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

Меры поддержки бизнеса в апреле 2022: полный обзор!

• первичная обработка и/или маршрутизация всех вопросов, возникающих у заказчиков, со всех каналов взаимодействия (чаты, почта, телефония): мы гарантируем, что ни одна задача не будет потеряна, а также будут соблюдены условия SLA по времени реакции на запрос.
• оповещение об инцидентах не только в чат, но и по звонку, в том числе, по сложным правилам эскалации, а ещё ребята могут сообщить краткие характеристики инцидента, основываясь на показателях мониторинга.
• формирование задач на основе запросов и комментирование статусов задач заказчику, дополнение задач согласно новой информации, полученной от заказчика, ведение календаря запланированных работ.

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

Вторая линия

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

• разрешение базовых инцидентов — кончилось место на диске, истёк срок действия SSL-сертификата и т.п.
• консультация клиентов по вопросам работы мониторинга;
• решение типовых задач.

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

Третья линия

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

• расследования, решение и анализ сложных инцидентов;
• решение сложных комплексных задач;
• формирование инструкций и пополнение базы знаний.

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

Инструменты

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

База знаний

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

• шаблонизировать всё, что можно шаблонизировать, и сделать общую структуру максимально прозрачной;
• сделать доступ к базе быстрым, а поиск — простым и предсказуемым;
• формализовать процесс внесения знаний в базу и их актуализации.

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

Процесс внесения новой информации в базу, а также актуализация текущих статей должен быть прозрачен и поделен на зоны ответственности, например:

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

Мониторинг

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

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

Бэкапы

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

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

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

Тикетная система

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

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

Сейчас на выбор есть большое количество как платных, так и опенсорсных тикетных систем; многие из них позволяют шаблонизировать задачи и процессы, строить различные диаграммы (всем известного Ганта, например) и использовать разнообразные метрики для формирования аналитики по процессам решения задач.

Каналы взаимодействия

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

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

Менеджмент задач

Не всегда техподдержка 24/7 — это только реакция на аварии. Наши сотрудники обеспечивают полный цикл жизни задач по сопровождению системы:

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

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

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

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

Менеджмент инцидентов

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

• Оповещение об алерте согласно порядку эскалации.
• Оценку алерта — т.е важно понять, указывает ли алерт на действительно произошедший инцидент. Бесполезные алерты, к сожалению, довольно частые спутники процессов технической поддержки. О том, как с ними бороться, расскажем в следующих сериях.
• Сбор информации об инциденте.
• Решение инцидента.
• Анализ инцидента, который должен привести как к разработке или дополнению инструкций по решению, так и к формированию мер для предотвращения инцидента в дальнейшем.

Также хорошей практикой является на регулярной основе анализировать статистику срабатывания алертов и на основе этого вносить корректировки в систему мониторинга.

Вместо вывода: 50 оттенков и 100 нюансов.

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

На него можно вступить самостоятельно, получая зачастую сомнительное удовольствие от встречи с этими граблями и на собственном опыте разбираясь во всех оттенках и нюансах процесса организации службы техподдержки. Или можно довериться тем, кто уже разведал дорогу. У нас на поддержке находится более 400 разнообразных проектов, и мы всегда готовы принять к себе еще. Если же вы решили справиться собственными силами, мы всегда поддержим морально и проконсультируем по каждому шагу и этапу!

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

Источник: www.itsumma.ru

Служба поддержки: какому бизнесу нужна и как настроить ее работу

Быстрая и качественная служба поддержки — залог хорошего обслуживания клиентов в любом бизнесе. Она помогает компаниям развиваться и продавать больше: покупатели рассказывают о слабых местах фирмы, чувствуют свою важность и возвращаются за новыми покупками. В статье расскажем, что такое служба поддержки, какую пользу несет для компании и как построить работу службы с нуля.

Что такое служба поддержки

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

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

Пример. 14 тысяч пользователей каждый день пишут в «Одноклассники», что потеряли доступ к аккаунту. Специалисты компании подключаются за 10 секунд и восстанавливают 35% профилей.

Вот сферы, в которых можно встретить клиентскую поддержку. Разработчики приложений изучают обратную связь в Google Play и App Store и вносят коррективы в продукты. Онлайн-школы решают проблемы с доступом к контенту, а производители узнают больше о качестве товара

Цели службы поддержки

Есть три основные бизнес-задачи, которые решает служба поддержки:

1. Увеличивать лояльность клиентов. Гарвардская школа бизнеса провела исследование в 2018 году и выяснила: пользователи, которые контактировали со службой поддержки, готовы платить за товары бренда больше.
2. Получать больше прибыли. Консалтинговая компания Invesp утверждает, что удержание каждых 5% покупателей увеличивает прибыль на 25–95% в зависимости от сферы. Если поддержка решает проблемы, клиенты уходят реже. Сохранить клиента дешевле, чем привлечь.
3. Совершенствовать продукт и сервис. Найденные проблемы — точки роста компании. Благодаря пользователям можно понять, где есть слабые места и в какой приоритетности над ними нужно работать.

Виды службы поддержки

Служба поддержки бывает техническая и клиентская. Чаще разделение условно, поскольку тот же банк может одновременно получать вопросы о неработающем приложении и тарифах карты. Расскажем подробнее об этих службах.

Техническая

Чтобы развивать онлайн-сервисы и следить за работоспособностью оборудования, нужна техническая служба поддержки.

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

Экосистема продуктов для бизнеса «Сбис» позволяет клиентам общаться с разработчиками и голосовать за важные доработки в программах

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

Техническую службу поддержки можно разделить на два вида:

1. Внешняя — решает вопросы клиентов. Например, компания владеет небольшой CRM-системой по ежемесячной подписке, а у покупателей периодически возникают вопросы по интерфейсу или проблемы в работе. В таком случае бизнес нанимает специалистов поддержки, которые помогут клиентам разобраться с продуктом.
2. Внутренняя — решает вопросы сотрудников. Такие специалисты помогают сотрудникам компании разбираться с техническими проблемами. Например, не работает принтер, нужно загрузить корректные ценники в 1С или подключить стационарные телефоны. Поддержка может быть в штате компании или на аутсорсе.

Клиентская

Чтобы выстроить долгосрочные отношения с покупателями, нужна клиентская служба.

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

Страховая компания «Ингосстрах» отвечает на вопросы по услугам и продуктам по телефону, в онлайн-чате и через мессенджеры

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

Сотрудники клиентской поддержки отвечают на вопросы:

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

Пример. Раньше в Ozon был чат только с представителями маркетплейса, а теперь поставщики могут общаться с клиентами напрямую.

Совмещенная

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

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

Сбербанк сделал виртуального ассистента: он разгружает сотрудников службы, предоставляет ответы на частые вопросы и озвучивает свои сообщения

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

Как построить работу службы поддержки

Чтобы создать службу поддержки, достаточно восьми шагов.

Шаг № 1. Обозначьте цель

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

Чтобы выбрать тип службы, исходите из цели:

• развитие сложных продуктов — техническая;
• улучшение сервиса, качества товаров и услуг — клиентская.

Шаг № 2. Соберите информацию о клиентах

Отдел поддержки: ожидание vs реальность

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

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

Подробности под катом.

Специально не отвлекался на вакансии трансформеры, когда компании нужен “и спец, и жнец, и на дуде игрец”(это когда человек должен и платы паять и 1С-конфигурации писать) я терпеливо ждал хорошего предложения. Через 2 месяца на меня вышел зам.начальника управления, с предложением, на которое трудно было не согласится.

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

Первоначальные цели:

1. Поддержка на первой и второй линии.
2. Создание базы знаний
3. Создание документации пользователей
4. Вникнуть в бизнес-процесс для осуществления “бизнес консультаций”
5. Подготовить регламент взаимодействий подразделений в рамках методологии ITIL Service Desk(планировал взять оттуда только процесс прохождения заявок и инцидентов + написание SLA, потому как знаю, что в тупую внедрять полностью формализованный процесс никто не даст, да и это не заработает)
6. Нанять сотрудников поддержки.

Создание документации

Что хотелось: Так как поддерживать предстояло купленную информационную систему, а я раньше больше имел дело с аппаратной инфраструктурой, я решил входить в курс дела постепенно и с той стороны, какая была для меня самой очевидной – я попросил регламенты процессов, автоматизируемых системой, и документацию к ней. И столкнулся с первым сюрпризом – документации у купленной за “деньги” системы не было.

Были набросанные компанией-разработчиком на коленке слайды, как определённые роли участвуют в процессе и на этом всё. У компании было ещё 4 месяца поддержки по договору, когда к ним можно было обращаться с вопросами по работе системы. Внутреннего проекта по внедрению системы не было, сроки устанавливались соглашением и excel-документом, в котором были указаны сроки внедрения определённых доработок. Да, после моего найма система дописывалась ещё 5 месяцев.

Что получилось: С грехом пополам, описаны несколько процессов в виде схем Visio. Частично описаны модули системы. Из-за срыва сроков коммуникация с разработчиками купленной системы стала ещё хуже. Насколько я понял, обязательность документации при покупке не оговаривалась.

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

Создание базы знаний

Что хотелось: Поддержка на первой линии предполагала набрать определённый пул вопросов от пользователей, предполагалось, что этот пул уже есть у менеджеров, хотя бы частично. Но после переговоров с начальником отдела продаж стало ясно, что пула нет и процесс будет выглядеть следующим образом: пользователь звонит, если это связано с технической частью, то помогаем, если с бизнес-частью, то перезваниваем. Так как бизнес-части ответов не было совсем, то первым пользователям должно было не очень повезти. Опять же, при разговоре я понял, что бизнес не очень то и дорожит новыми пользователями и готов пойти на эти риски.
Чтобы внести ясность, с такими исходниками картина представлялась довольно туманной, но я воспринимал это как вызов.

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

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

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

Подбор персонала

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

Таблица компетенций первой линии: