Определите, что должен показывать реестр
Реестр заказов отвечает на вопросы: что обещано, что делать дальше, кто ждёт ответа и чем подтверждена передача. Он не заменяет бухгалтерский учёт и юридические документы. Финансовые обязательства и правила хранения данных проверяются отдельно под вашу ситуацию.
Учебный пример: фотограф Антон получает запросы из почты и мессенджера. Одну съёмку он подтвердил, второй клиент только спросил дату, третий уже получил фотографии. Единый статус «клиент» скрывает три разных состояния.
Одна строка — один конкретный заказ
Дайте заказу короткий идентификатор. Повторный заказ того же клиента получает новую строку, связанную с прежней историей. Название «Мария» неудобно: через месяц непонятно, о какой съёмке речь. Лучше «F-014, предметная съёмка, октябрь».
Не копируйте в общедоступную таблицу персональные сведения и закрытые материалы. Храните минимально нужное имя или обозначение, рабочую ссылку с подходящими доступами и условие связи. Доступность таблицы должна соответствовать содержимому.
| ID | Этап | Следующее действие | Проверка |
|---|---|---|---|
| F-014 | Ждём материалы | Клиент присылает список | Завтра |
| F-015 | Исполнение | Антон отбирает кадры | Пятница |
| F-016 | Передано | Клиент проверяет файлы | Понедельник |
Выберите поля для следующего решения
Минимум: идентификатор, предмет заказа, этап, ближайшее действие, ответственный за него, дата следующей проверки, согласованный срок передачи и ссылка на условия. Дополнительные поля добавляйте только ради решения. «Вероятность успеха» без основания может создавать ложную точность.
Антон видит по F-014: ждёт список предметов от клиента, проверка завтра, съёмка назначена условно. По F-015: материалы готовы, следующая задача — отбор кадров до пятницы. Разница сразу меняет рабочий день.
Чтобы после заполнения реестра распределить заказы по окнам, используйте Как вести несколько заказов: очередь передач и ограничение обещаний.
Отделите заявку от подтверждённого обязательства
Запрос даты ещё не равен заказу. Укажите, что именно переводит заявку в подтверждённую работу: согласованы состав, дата, материалы и необходимые условия. Не устанавливайте одинаковое правило для всех видов услуг без учёта их специфики.
Если заявка зависла, нужен следующий контакт или дата закрытия. Иначе в реестре растёт мёртвый список, который ошибочно принимают за загрузку. В истории сохраните причину закрытия, чтобы не тратить время на повторное восстановление переписки.
- Заявка
Уточнить состав
- Подтверждение
Зафиксировать обязательство
- Исполнение
Видеть следующий шаг
- Приёмка
Сохранить подтверждение результата
Храните историю изменений отдельно от текущего состояния
В основной строке должен быть актуальный срок. В журнале — прежняя дата, причина переноса, кто подтвердил решение и когда. Не держите пять дат через запятую в одной ячейке. Текущий обзор и история выполняют разные задачи.
Передача файлов также не означает приёмку. Зафиксируйте дату отправки, состав переданного и ответ клиента. Если результат возвращён на исправление, ссылка на конкретные замечания полезнее нового расплывчатого статуса «в работе».
Настройте обзор ожидающих действий
Фильтр «следующая проверка сегодня или раньше» помогает увидеть забытые обещания. Отдельно показывайте принятые заказы без следующего шага: это возможный пробел, который нужно разобрать. Не превращайте таблицу в бесконечное напоминание без ответственного.
Антон проверяет реестр перед началом недели и перед подтверждением нового заказа. В пятницу он закрывает принятые результаты и переносит только действительно ожидающие вопросы. Таблица остаётся рабочим инструментом, а не архивом всех сообщений.
| Событие | Сохраняем | Не предполагаем |
|---|---|---|
| Запрос | Предмет и следующий контакт | Заказ подтверждён |
| Передача | Состав и ссылку | Результат принят |
| Приёмка | Ответ по условиям | Любые другие обязательства закрыты |
Чтобы связать доработку с конкретной версией, откройте Как учесть правки клиента: единый список, версии и граница изменения.
Проверьте таблицу на трёх реальных случаях
Внесите заявку, исполняемый заказ и завершённую передачу. Попробуйте ответить: свободна ли дата, кого нужно спросить и где подтверждён итог? Если ответы требуют поиска по перепискам, добавьте нужную связь. Не добавляйте поля, которые никто не будет обновлять.
Ошибка — отслеживать только деньги и забывать результат. Обратная ошибка — считать факт передачи доказательством закрытия всех условий. В реестре организационные и расчётные события должны быть различимы, без правовых выводов из одного статуса.
Когда нужен сервис вместо файла
Таблица подходит одному человеку с небольшим потоком. Если появляется несколько исполнителей, разграничение доступа, автоматические сообщения или сложная история, рассмотрите подходящий сервис. Переносите сначала проверенную структуру, иначе автоматизация закрепит путаницу.
Для отдельных следующих действий можно использовать задачник. Не обещайте клиенту автоматическое создание всей базы из переписки, если такого процесса нет. Начните с одного заказа, по которому прямо сейчас неизвестно следующее действие.
Как три записи проходят через одну неделю
В понедельник F-014 остаётся заявкой: клиент не подтвердил состав предметов. Антон записывает следующий контакт во вторник и не считает съёмку безусловно занятой датой. F-015 находится в исполнении: список кадров согласован, отбор назначен на среду. F-016 передан клиенту в пятницу, ответ ожидается во вторник. У каждой строки есть одно актуальное следующее действие и тот, от кого оно зависит.
Во вторник F-014 подтверждается после получения списка и согласования условий. В истории появляется событие, а в текущей строке — новая задача подготовки. По F-016 клиент присылает два замечания. Заказ возвращается в доработку со ссылкой на пакет, а не заводится как новый заказ и не остаётся закрытым. По F-015 переносов нет, поэтому повторный контакт ради самого обновления таблицы не нужен.
В четверг F-016 передаётся исправленной версией. Антон указывает, какие два пункта изменены и где лежат файлы. В пятницу получает подтверждение результата и фиксирует приёмку. Финансовые события, если он их отслеживает в этом же файле, имеют отдельные поля и не выводятся автоматически из приёмки фотографий.
Проверка реестра перед началом новой недели
Отфильтруйте четыре ситуации: дата проверки прошла; у активного заказа нет следующего действия; срок передачи раньше ожидаемого входа; заказ закрыт без основания закрытия. Разберите каждую строку по факту. Просроченная проверка может означать забытый контакт или просто не обновлённую запись; сначала выясните причину.
Шаблон журнала: «Дата __. Заказ __. Событие __. Предыдущее состояние __. Новое состояние __. Основание __. Следующий шаг __. Ответственный __». Событие «клиент прислал материалы» не равнозначно «материалы пригодны»: при необходимости добавьте проверку полноты.
Не стремитесь автоматически закрывать записи по истечении срока. Для архивирования определите организационное правило и правила хранения. Перед удалением убедитесь, что это не уничтожит нужную историю обязательств. Сам реестр не предоставляет разрешения на удаление данных или документов.
Материалы для следующего шага
Для следующего действия используйте Бриф: что это и как заполнить его перед началом проекта: заполните входные сведения до обещания объёма и даты заказа.
Что ещё стоит уточнить
Можно ли вести клиентов и заказы вместе?
Можно связать два списка. Один клиент может иметь несколько разных заказов.
Сколько полей нужно?
Столько, чтобы видеть обязательство, следующий шаг и подтверждение результата. Начните с минимального набора.
Что делать с отменёнными заявками?
Закрыть с причиной и сохранить необходимую историю в рамках правил хранения.
Это заменяет финансовый учёт?
Нет. Здесь описан операционный контроль исполнения; обязательный учёт решается отдельно.
Помогло разобраться?
Оцените статью и расскажите, чего не хватило. Отзыв увидит редакция Sinqly — он не появится на сайте.
Источники и примечания
- The Kanban Guide, May 2025
- Предлагаемый порядок — редакционная практика, а не обещание одинакового результата для всех.
