Могу вспомнить несколько причин:

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

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

3. Закончилась проектная работа. Проект завершили и пока нет возможности нам продолжить работу. Остаёмся на связи с клиентом.

4. Отказались от клиента сами. Видим нечестную работу, вред компании клиента или неадекватное поведение клиента. Но тут скорее мы отказались, а не клиент.

Как-то так. :)

У нас remote-frst команда. Remote-first — это когда офис/коворкинг по желанию, а изначально мы ориентируем, что работа будет удаленной. Remote-first держится на ответственности и сдерживании обещаний.

Про ответственность я уже много раз писал (и буду писать), сегодня хочу поговорить про дедлайны. У нас сотрудники самостоятельно выбирают дедлайны для задач. Потому что именно они обещают клиенту сделать определенные задачи к какому-либо времени. И срыв дедлайнов крайне редкое событие в компании. Сейчас расскажу каким правилам мы придерживаемся, чтоб не срывать дедлайны.

1. Всегда можно передоговориться. Иногда что-то случается, и становится понятно, что дедлайн не будет соблюдён. В таком случае мы стараемся как можно раньше передоговориться с клиентов. Если времени до дедлайна останется немного, то можем ограничить функционал задачи или её объем. К примеру, делаем анализ конкурентов, и первой итерацией только 3-5 основных конкурентов, а второй всех остальных. Это важно, потому что наш ЛПР тоже мог кому-то пообещать показать нашу работу.

2. Создаем внутренние дедлайны. Чтоб не делать всё в последний день, мы создаем внутренние дедлайны. Дизайнеры готовят креативы к такому числу, мы готовим посадочные к такому числу. А в такой то день согласовываем с клиентом. В идеале если после всего этого еще остается 2 дня, если что-то пойдет не так.

3. Создаем буфер. Это от 2 до 6 часов в неделю, которые отводятся для срочных задач или если что-то пойдет не так. Если срочных задач нет, то делаем что-то сверху.

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

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

А вы что делаете, чтоб не срывать дедлайны?

Я уже писал, что стараюсь разделять информационное поле. Всё что связано с задачами, я веду в планировщике Singularity App. Все что нужно прочитать или узнать что-то новое, я складываю в Omnivore. Все собственные записи делаю в Obsidian.

Но телеграм-каналы не приспособлены, чтоб их читать в Omnivore. У них нет RSS-лент.

Для этого я нашел сервис RSSHub. Это бесплатная утилита, которая создает из телеграм-канала RSS ленту.

Разберём на примере моего канала. Ссылка на него такая:

https://t.me/rozhkovmarketing

Чтоб сделать RSS ленту в RSSHub: берём последнюю часть ссылки

rozhkovmarketing

и добавляем к

https://rsshub.app/telegram/channel/

Должно получится:

https://rsshub.app/telegram/channel/rozhkovmarketing

Все, готово, добавляем этот Atom XML лист в Omnivore или другую RSS читалку, и новые посты будут добавляться в сервис.