Что должно быть в системе учёта, если вы работаете с клиентами

Большинство подрядчиков уже работает в какой-то системе задач. Вопрос не «есть ли система», а отвечает ли она на то, что спрашивает клиент: её строили для внутренней работы, а не для разговора с тем, кто платит. Это список требований, а не функций. Значительная часть есть почти в любом инструменте, и здесь прямо сказано, где именно.

1. Час привязан к задаче, а не к свободной строке

Требование: нельзя записать час «просто так». Каждый час принадлежит задаче, у задачи есть описание.

Почему первым: «почему это столько стоило» это единственный вопрос, который повторяется у всех клиентов, и без связки час-задача на него нет ответа, есть только объяснение.

Это есть почти везде: Jira, Asana, monday, Clockify. Если у вас не требуется, это решение в настройках, а не нехватка инструмента.

2. Ставка хранится на часе, а не считается задним числом

Требование: когда час записан, вместе с ним сохраняется ставка, действовавшая в тот день.

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

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

3. Дата последнего движения, которая говорит правду

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

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

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

4. Одно место для клиента, с отдельным правом

Требование: у клиента свой вход, и это не «наша система с меньшим числом кнопок».

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

Здесь разброс между инструментами большой. Портал клиента есть у monday и Zoho; в Jira это плагин; в части инструментов его нет вовсе, и решением становится отправка PDF.

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

5. Деньги как право, отдельное от отчётов

Требование: «видит отчёт» и «видит суммы» это два разных права.

Почему: сводить часы можно поручить сотруднику; видеть, по какой ставке компания продаёт клиенту, уже не обязательно. Если это одно право, придётся выбирать между «у него нет отчётов» и «он знает маржу».

Есть в корпоративных инструментах, почти отсутствует в небольших.

6. Журнал того, что вынесли наружу

Требование: когда сформирован отчёт, кто скачал файл, что отправлено клиенту, записывается.

Почему: это не бюрократия, а защита. «Вы мне не присылали» и «мы присылали» это утверждения, которые без записи не разрешаются, и тот, у кого журнала нет, проигрывает спор даже будучи правым.

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

7. Что провисло, без вопроса

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

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

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

8. Переписка, связанная с работой

Требование: письмо можно привязать к задаче, и оно читается рядом с её историей.

Почему: «я просил это письмом» это самый частый спор об объёме, и решается он одной ссылкой.

Есть в Zendesk и инструментах поддержки; в системах управления проектами редко.

9. Выгрузка, которую можно отдать клиенту без доработки

Требование: Excel и PDF по кнопке, в виде, который можно отправить как есть.

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

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

10. Несколько клиентов в одном инструменте, без утечки

Требование: разделение клиентов держится в одном месте, а не в каждом запросе отдельно.

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

Что проверить у себя сегодня: возьмите экран, написанный недавно, и посмотрите, не написан ли фильтр в нём руками. Если да, это вопрос не «если», а «когда».

11. Пять вопросов на демонстрации

Продавцы показывают всегда одни и те же три экрана. Вот вопросы, которые показывают остальное:

1. «Покажите час, записанный полгода назад, после того как вы меняли ставку.» Здесь выясняется пункт 2.
2. «Покажите, что именно видит клиент, из его учётной записи.» Не экран, который это изображает.
3. «Покажите задачу, которую никто не трогал два месяца.» Что стоит в поле движения.
4. «Покажите, кто скачал вот этот отчёт и когда.»
5. «Как я увижу, что провисло, не открывая фильтр?»

Вопрос, который продавцу не нравится, сам по себе не плохой знак. Плохой знак это ответ «это можно построить».

12. Одно, чего требовать не стоит

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

У нас, например, есть база знаний со смысловым поиском, и она пустая: ноль статей на живом проекте. Механизм написан и работает; не хватает того, чтобы кто-то написал первую статью. Это не провал инструмента и другим инструментом не лечится.

Как пользоваться этим списком

Пройдите по нему с тем, что у вас есть. Большая часть пунктов, скорее всего, уже отмечена. Те, что нет (2, 4, 5, 6, 7), и порождают большинство разговоров-недоразумений с клиентами, и именно их стоит проверить, прежде чем что-то менять.

Как каждый из них выглядит в одной системе, видно на страницах ниже.