Approval workflow: превращаем email-цепочки в понятные статусы

Почему согласования по email перестают работать

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

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

Дальше ломается ответственность. В хорошем approval process один человек отвечает за текущий шаг, и все видят, кто действует следующим. В email это обычно превращается в угадайку. Менеджер думает, что финансы уже посмотрели. Финансы считают, что руководитель команды уже дал добро. Автор запроса ждет, а потом пишет сразу пятерым. Больше сообщений не создают ясности. Они только скрывают пропавшего владельца.

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

У растущих компаний один и тот же сценарий повторяется снова и снова. Сначала команда опирается на здравый смысл и добрую волю. Потом растет объем. Десять запросов превращаются в пятьдесят. Люди придумывают обходные правила, лишь бы процесс не останавливался. Если Сара поставила реакцию в Slack, считаем это одобрением. Если до пятницы никто не возразил, значит можно идти дальше. Срочные вопросы шлите мне на личную почту.

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

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

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

Как выглядят понятные статусы

Хороший approval flow дает каждому запросу один ярлык в каждый момент времени. Не два ярлыка, не заметку в Slack и еще одну в email. Один текущий статус говорит всем одно и то же, и люди перестают спрашивать: «Где это сейчас?»

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

Большинству команд нужен совсем небольшой набор статусов:

• Draft
• Ready for review
• Waiting for approval
• Approved
• Rejected

Названия скучные, и это плюс. Скучные названия делают approval process лучше, потому что никто не тратит время на расшифровку.

У каждого статуса должен быть человек или хотя бы роль, которая может двинуть его дальше. Если запрос завис в «Waiting for approval», команда должна понимать, кто действует следующим. Это может быть менеджер по бюджету, finance для оплаты или legal для условий договора. Когда следующий шаг никому не принадлежит, запрос просто висит.

Один запрос не должен жить сразу в нескольких местах. Заявка на покупку не может одновременно быть и «waiting for finance», и «approved» только потому, что кто-то написал «looks good» в email-цепочке. Истина — в записи системы. Комментарии могут добавлять контекст, но текущий статус должен быть один.

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

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

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

Сначала назовите статусы, потом выбирайте инструмент

Хороший approval workflow начинается на бумаге, а не в софте. Если пропустить этот шаг, инструмент просто красиво упакует старые email-привычки.

Первую версию лучше сделать маленькой. Большинство команд могут начать с пяти статусов: «Draft», «Review», «Approved», «Rejected» и «Done». Этого достаточно, чтобы видеть, где находится работа, кто за нее отвечает и что будет дальше.

У каждого статуса должен быть понятный смысл. Draft означает, что автор еще редактирует запрос и может свободно его менять. Review означает, что запрос готов для проверки кем-то еще. Approved означает, что проверяющий сказал «да», и команда может действовать. Rejected означает, что проверяющий сказал «нет», и запрос останавливается, если кто-то не перепишет его. Done означает, что одобренная работа завершена и больше никому не нужно к ней возвращаться.

Это звучит просто, потому что так и есть. Здесь простота лучше изящества. Если людям нужен рисунок, чтобы понять разницу между «pending validation», «under assessment» и «ready for execution», к пятнице они снова вернутся в email.

Добавляйте только те статусы, которыми команда пользуется каждую неделю. Статус для редкого исключения обычно создает больше путаницы, чем пользы. Если finance просит «waiting for budget» два раза в год, лучше оставить это в деталях запроса, чем превращать в постоянный статус.

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

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

Небольшой пример хорошо показывает логику. Менеджер по маркетингу просит новый договор с подрядчиком. Она создает его в Draft, переводит в Review, когда заполнены цена и условия, legal либо отправляет его назад с комментариями, либо ставит «Approved», а procurement помечает его «Done» после отправки договора. Без догадок. Без поисков по почтовым цепочкам.

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

Постройте один путь шаг за шагом

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

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

Затем выстройте путь в несколько понятных шагов:

1. Выберите один тип запроса и задайте ему понятную точку старта.
2. Запишите, кто его создает, кто проверяет и кто дает финальное да или нет.
3. Добавьте срок на каждый переход.
4. Держите запрос, комментарии, файлы и финальное решение в одном месте.
5. Прогоните один реальный запрос через процесс и посмотрите, где люди начинают сомневаться.

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

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

Держите все вместе. Когда файл лежит в одном инструменте, комментарии — в email, а одобрение приходит в чате, команда начинает спорить о последней версии вместо принятия решения. В одной записи должны быть запрос, текущий статус, комментарии и прикрепленный файл. Уже это делает approval process спокойнее.

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

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

Простой пример из растущей компании

Компании из 30 человек нужен новый инструмент поддержки клиентов. Руководитель поддержки хочет отвечать быстрее, поэтому просит общий inbox с чатом и историей тикетов. В старой схеме она бы отправила письмо в finance, копию в security и стала ждать. Кто-то потерял бы цепочку, менеджер одобрил бы не тот тариф, и команда купила бы инструмент до того, как кто-то проверил бы, к каким данным он получает доступ.

Понятный approval flow превращает этот хаос в несколько ясных статусов:

• Requested
• Budget checked
• Security review
• CTO review if needed
• Approved for purchase

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

Если finance говорит «нет», запрос останавливается на этом этапе. Автор получает понятную причину, например: «не заложено в бюджет этого квартала» или «пока используйте текущий инструмент». Ответ может не нравиться, но процессу доверяют больше, когда он закрывается чисто, а не растворяется в тишине.

Если finance одобряет, security проверяет реальные риски. Хранит ли инструмент данные клиентов? Нужен ли ему доступ к email, CRM или внутренним файлам? Можно ли подключить single sign-on, или сотрудники будут создавать слабые пароли и забывать их через полгода? Security не нужен длинный отчет для каждой покупки. Для большинства случаев достаточно короткого чек-листа.

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

Когда решение принято, цикл закрывается. Автор запроса видит финальный статус, finance знает, можно ли выделять деньги, а IT или operations могут купить инструмент и зафиксировать, кто за него отвечает. Никому не нужно искать ответ в пяти почтовых ящиках, чтобы потом ответить на простой вопрос: «Кто это одобрил и почему?»

Ошибки, из-за которых люди игнорируют процесс

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

Первая ошибка — слишком много статусов. Четыре понятных статуса часто лучше, чем десять умных. Если запрос может лежать в «pending review», «manager review», «director review», «finance review» и «final confirmation», большинство людей просто не поймут, что меняется на каждом шаге. Они увидят только задержку.

Полезное правило простое: каждый статус должен отвечать на свой вопрос. Готово ли? Кто проверяет? Одобрено ли? Завершено ли? Если два статуса означают почти одно и то же, объедините их.

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

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

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

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

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

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

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

Быстрая проверка перед запуском

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

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

Затем проверьте ответственность. У каждого статуса должен быть один очевидный ответ на вопрос: кто двигает это дальше сейчас? Если запрос завис в review, а три человека думают, что это должен сделать кто-то другой, очередь застопорится. Один статус должен указывать на одного владельца и одно следующее действие.

Обычно хватает нескольких сухих прогонов:

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

Отклонения требуют отдельного внимания. Само по себе «Rejected» вызывает споры. Короткая причина вроде «нет бюджета» или «нет согласования менеджера» экономит время и снижает повторную работу. Людям гораздо легче принять отказ, когда они видят, почему он произошел и что нужно исправить.

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

Еще один тест ловит больше проблем, чем кажется. Возьмите пять активных запросов и спросите, где находится каждый из них прямо сейчас. Если ответы приходят из email, таблицы и памяти, система еще не готова. У latest status должно быть одно место, иначе approval process распадается на два.

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

Что делать дальше

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

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

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

• время ожидания от запроса до решения
• как часто работу возвращают на доработку
• сколько согласований люди пропускают вне системы
• как часто кто-то спрашивает: «Кто отвечает за это сейчас?»

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

После первых двух недель переименуйте все, что кажется размытым. «Pending» часто слишком неопределенный. «Needs finance review» или «Waiting for legal» понять гораздо легче. С ответственностью нужно сделать то же самое. Команда не может владеть шагом на практике. Им должен владеть один человек или одна роль.

Межкомандные согласования требуют особой аккуратности. Sales, finance, legal и engineering часто используют разные инструменты и разные слова для одного и того же статуса. Вот здесь внешняя помощь может сэкономить массу времени. Oleg Sotnikov через oleg.is работает со стартапами и небольшими компаниями именно над такой настройкой: наводит порядок в статусах workflow, сокращает зоопарк инструментов и добавляет автоматизацию только там, где она действительно помогает.

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