Как создать веб‑приложение для учета часов и прибыли агентства

Цели продукта и ключевые сценарии агентства

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

Кому и зачем это нужно

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

Аккаунт-менеджеру — объяснять клиенту статус работ и обосновывать счета: что сделано, сколько времени списано, что осталось в рамках договоренностей.

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

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

Бухгалтерии/финансам — получать основу для инвойсинга и сверок без ручных таблиц.

Какие ответы дает продукт

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

• сколько часов продано и сколько уже списано (billable hours vs фактические);
• где начался перерасход: по задаче, этапу, роли или человеку;
• какая маржа по проекту/клиенту и за счет чего она меняется;
• какова загрузка команды и есть ли риск сорвать сроки.

Ключевые сценарии (сквозной поток)

1. Исполнитель запускает таймер или добавляет запись в табель.

2. Проджект проверяет корректность и согласует время за период.

3. Аккаунт формирует данные для счета и отправляет клиенту (или выгружает в интеграцию).

4. Руководитель смотрит дашборды: прибыльность проектов и тренды.

Границы продукта: что не цель

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

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

Роли пользователей и модель доступа

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

Базовые роли

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

Менеджер — ведет проекты, распределяет людей, контролирует заполнение тайм‑логов и готовит отчеты для клиента. Ему важно видеть план/факт по часам и отклонения, но не всегда нужно видеть внутреннюю себестоимость.

Сотрудник — ведет свои тайм‑логи, видит свои задачи, статусы согласования и историю правок. Доступ к финансовым показателям — по умолчанию закрыт.

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

Финансы (опционально) — отвечает за ставки, биллинг, инвойсы и контроль прибыльности. Должен видеть «продажную» ставку, себестоимость, маржу и сводные отчеты.

Кто видит ставки, себестоимость и прибыль

Рекомендуем разделить как минимум три уровня данных:

• Ставки биллинга (что выставляем клиенту): менеджер проекта + финансы.
• Себестоимость/внутренние ставки: финансы (и ограниченно — руководство).
• Прибыль/маржинальность: финансы и руководство; менеджерам — по правилам агентства (часто достаточно маржи без детализации зарплат).

Доступ по проектам, командам и клиентам

Удобная схема — матрица «пользователь ↔ проекты» с ролью на проекте (например, участник/менеджер/наблюдатель). Дополнительно можно вводить ограничения по:

• отделам (например, дизайн не видит проекты разработки),
• клиентам (менеджер ведет только свои аккаунты),
• портфелям проектов (группа проектов крупного клиента).

Аудит действий и контроль изменений

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

Минимальный набор: журнал аудита с фильтрами (пользователь/проект/период), хранение «до/после» и запрет редактирования после закрытия периода без специального права (например, «Разблокировать период»).

Модель данных: от тайм‑логов до финансов

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

Базовые сущности и связи

Минимальный набор объектов обычно выглядит так:

• Клиент → имеет проекты.
• Проект → делится на этапы/задачи (или направления работ).
• Сотрудник → заводит тайм‑логи.
• Тайм‑лог → попадает в табель (timesheet) за период.
• Ставка → определяет стоимость часа (для клиента) и/или себестоимость (для агентства).
• Расход → дополнительные затраты проекта (подрядчики, лицензии, командировки).

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

Тайм‑лог: обязательные поля и признаки

У тайм‑лога стоит зафиксировать обязательные поля:

• Дата выполнения работы
• Длительность (в минутах) или начало/конец
• Описание (что сделано)
• Метки (например, «дизайн», «правки», «встреча», «срочно»)
• Признак billable/non‑billable (оплачиваемое/неоплачиваемое)

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

Табель и статусы согласования

Чтобы управлять процессом, введите статусы для тайм‑лога или табеля:

черновик → отправлено → утверждено → заблокировано для правок.

На практике удобнее утверждать табель за период (неделя/месяц), а тайм‑логи наследуют состояние периода. Это упрощает «закрытие месяца» и снижает число спорных правок.

История изменений и округление

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

Правила округления задайте на уровне проекта или клиента: например, до 5/10/15 минут. Важно хранить сырое время и округленное время отдельно: так вы не потеряете точность для аналитики, но сможете корректно выставлять счета по договору.

Учет времени: таймер, ручной ввод и контроль

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

Таймер: старт/пауза/стоп и автосохранение

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

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

Ручной ввод: быстро, предсказуемо, без лишних полей

Ручной ввод нужен всегда: ретро‑внесение, работа «вне ноутбука», корректировки по просьбе менеджера. Ускоряют процесс:

• быстрые формы с клавиатурной навигацией (дата → время → проект → описание);
• копирование прошлых записей (например, «повторить вчера»);
• шаблоны описаний для типовых работ (бриф, QA, поддержка), чтобы не писать одно и то же.

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

Оффлайн и мобайл‑веб: чтобы данные не терялись

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

Пользователь должен видеть, какие записи еще не отправлены, и иметь возможность принудительно синхронизировать.

Контроль качества: описания, пересечения и аномалии

Чтобы данные годились для биллинга, добавьте мягкие, но заметные проверки:

• обязательное описание для billable‑записей (или минимум N символов);
• предупреждения о пересечениях по времени (две записи на один интервал);
• подсветка аномалий: слишком длинная смена, необычно много «небиллабла», резкий рост часов по проекту.

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

Ставки и модели биллинга (T&M, фикс, ретейнер)

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

Две ставки: клиентская и внутренняя

Практичный минимум:

• Billable rate: ставка, применяемая к тайм‑логам при выставлении клиенту.
• Cost rate: ставка себестоимости для прибыльности (зарплата + налоги/накладные — как вы решите считать внутри).

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

Модели биллинга

Time & Materials (T&M) — самая прямая модель: подтвержденные часы × ставка. В продукте она хорошо ложится на правило «каждый тайм‑лог знает, billable он или нет», а ставка подтягивается по выбранной матрице.

Фиксированная стоимость — счет не зависит от часов, но часы нужны для контроля перерасхода и реальной маржинальности. Минимально достаточно: фикс‑бюджет проекта + внутренний учет фактических часов.

Ретейнер — регулярная сумма за период (месяц/квартал) с включенными часами или без них. Полезные опции: «включено N часов», «перенос остатков» (можно отложить на более поздний релиз) и учет сверхлимита по отдельной ставке.

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

Правила ставок: где чаще всего ошибаются

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

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

Валюта и налоги: минимальный объем

Достаточно хранить:

• валюту ставки и проекта (например, EUR/ USD/ RUB);
• курс (ввод вручную или фикс на дату счета);
• суммы «без налога» и «с налогом» как отдельные поля.

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

Расчёт прибыльности: маржа, загрузка и перерасход

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

Выручка: как считать корректно

Базовый принцип: выручка считается только по утверждённым (approved) billable‑часам. Это защищает от «надувания» отчётов и расхождений с клиентом.

• T&M (Time & Materials): утверждённые billable часы × ставка клиента.
• Фикс‑проект: выручка не обязана следовать часам. Чаще нужен механизм распределения бюджета (по этапам или пропорционально времени — настраивается).

Удобно хранить выручку в разрезе проекта, этапа/вехи и периода (неделя/месяц), чтобы отчёты сходились с закрытием периодов.

Revenue_T&M = ApprovedBillableHours × ClientRate

Себестоимость: что включать

Минимальная модель себестоимости строится на внутренних ставках:

Cost = TrackedHours × InternalRate + DirectExpenses

Где DirectExpenses — прямые расходы при необходимости (подрядчики, платные сервисы, комиссии). Важно разделять:

• часы сотрудников (внутренняя ставка/стоимость часа),
• часы подрядчиков (ставка подрядчика + накладные, если учитываются),
• разовые расходы (как отдельные статьи, с привязкой к проекту/этапу).

Метрики, которые должны быть «в одном клике»

Маржа и маржинальность — основной индикатор качества проекта:

• Маржа = Выручка − Себестоимость
• Маржинальность % = Маржа / Выручка × 100%

Для управления командой нужны также:

• Загрузка (capacity / load): сколько часов доступно и сколько запланировано/учтено.
• Utilization: доля billable‑часов в общем времени (часто смотрят по людям и по ролям).
• Перерасход к бюджету: сравнение фактических часов/стоимости с планом.

Правила для фикс‑проектов: без них цифры будут спорными

В фикс‑контрактах ключевое — договориться, как «распознаётся» выручка:

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

Лучше сделать это настройкой проекта, иначе разные менеджеры будут считать прибыльность по‑разному — и сравнивать проекты станет невозможно.

Отчеты и дашборды для разных ролей

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

Дашборд руководителя

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

• Прибыль по клиентам и проектам: выручка, себестоимость (по ставкам), маржа и динамика за период.
• Топ перерасходов: проекты, где фактические часы уже превысили план, с указанием причины (например, задачи без оценки или частые правки).
• Тренды: загрузка команды, доля billable hours, изменение маржинальности по месяцам.

Полезная деталь: «светофор» по проектам (зеленый/желтый/красный) на основе правил, которые можно настроить — например, перерасход > 10% или маржа ниже порога.

Отчеты менеджера

Менеджеру нужен инструмент ежедневного контроля. Минимальный набор:

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

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

Отчеты сотрудника

Сотруднику нужен понятный табель и напоминания:

• Табель за неделю/месяц с разбивкой по проектам и комментариями.
• Подсветка незаполненных дней и уведомления (в приложении или на почту) до закрытия периода.

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

Экспорт и обмен данными

Заранее заложите форматы:

• CSV/XLSX для бухгалтерии и сверок.
• Печатный отчет для клиента (аккуратный PDF/страница) с фильтрами по периоду и работам.
• API‑выгрузка для интеграций и витрин данных — хотя бы базовые сущности: проекты, пользователи, тайм‑логи, ставки, инвойсы.

Если планируете расширение, добавьте страницу /reports с сохраненными шаблонами отчетов и правами доступа: один и тот же отчет должен выглядеть по‑разному для разных ролей.

Согласование времени и закрытие периодов

Даже лучший тайм‑трекер теряет смысл, если данные «плавают»: кто-то забывает заполнить дни, кто-то правит прошлый месяц после выставления счета, а руководитель проекта не понимает, чему верить. Поэтому в продукте нужен понятный процесс согласования (approval) и жесткие правила закрытия периодов.

Воронка утверждения табеля

Сделайте простую, но управляемую цепочку статусов для записей времени и табелей (например, неделя/месяц):

• Черновик — сотрудник заполняет и редактирует.
• Отправлено на согласование — табель «замораживается» для автора, но доступен для комментариев.
• Частично принято — менеджер утверждает корректные строки, а спорные возвращает на доработку (важно, чтобы не приходилось «отклонять всё»).
• Возвращено на доработку — с обязательным комментарием: что исправить (проект, тип работ, описание, ставка/активность).
• Утверждено — готово к инвойсингу и отчетам.

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

Правила блокировок и закрытие периода

Закрытие периода — это момент, когда числа становятся «официальными». Введите блокировки:

• запрет редактирования строк, попавших в инвойс;
• запрет изменений после закрытия месяца/спринта (с возможностью открыть период только пользователю с правами финконтроля);
• отдельное правило для «исправлений задним числом»: только через запрос с причиной.

Напоминания и контроль дисциплины

Автоматические напоминания заметно повышают качество данных:

• недозаполненные дни (например, < 8 часов или 0 billable);
• просроченные табели (не отправлены до дедлайна);
• превышение бюджета по проекту/ретейнеру (по часам или сумме).

История согласования (аудит)

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

Инвойсинг и интеграции (что подключать в первую очередь)

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

Как формировать инвойсы из времени

Базовый поток выглядит так:

• выбрать период (неделя/месяц) и клиента;
• подтянуть утвержденные записи времени;
• сгруппировать строки по проектам и этапам (или по задачам — если клиент это любит);
• применить ставки и налоги/НДС согласно настройкам клиента;
• зафиксировать версию инвойса (чтобы последующие правки тайм‑логов не меняли уже выставленный счет).

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

Клиентский отчет: насколько подробно показывать

Не всем клиентам нужна детализация до минуты. В интерфейсе стоит поддержать два режима:

• Агрегированный отчет: по проекту/этапу, с итогами часов и суммы.
• Детализированный отчет: по задачам и сотрудникам, с датами и комментариями.

Критично уметь скрывать внутренние пометки и служебные теги (например, «обучение», «внутренний созвон»), оставляя клиенту только то, что согласовано.

Хорошая практика — иметь поле «Комментарий для клиента» отдельно от внутреннего.

Интеграции: что подключать первым

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

1. Таск‑трекер: подтягивать проект/задачу в тайм‑лог, чтобы меньше ошибок в назначениях.
2. Календарь: автоподсказки по встречам (с возможностью быстро превратить встречу в запись времени).
3. Платежи/бухучет: экспорт инвойсов и статусов оплат через API и вебхуки (создан, отправлен, оплачен, просрочен). Это помогает дашбордам показывать реальную дебиторку.

Импорт данных без боли

На старте почти всегда нужен импорт: сотрудники, клиенты, проекты, ставки, а иногда и исторические тайм‑логи. Сделайте простой мастер импорта (CSV + проверка ошибок) и маппинг полей.

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

Безопасность, приватность и надежность

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

Аутентификация и вход

Базовый вариант — логин по почте с подтверждением и опционально SSO (Google/Microsoft) для корпоративных команд. Для администраторов и пользователей с доступом к ставкам/финансам включайте 2FA как минимум по TOTP.

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

Разделение данных клиентов и права доступа

Если в одном аккаунте ведутся несколько клиентов, важно исключить случайную утечку данных «между проектами». Минимальный набор:

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

На уровне хранения данных применяйте строгую изоляцию по tenant/организации, а для экспорта (CSV/PDF) — маркируйте, кто и когда выгружал данные.

Логи, мониторинг и защита от злоупотреблений

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

Добавьте мониторинг подозрительных действий: массовые экспорты, частые неуспешные входы, резкие скачки API‑запросов. Для API — лимиты (rate limiting) и ключи с ограничением прав.

Соответствие требованиям и сроки хранения

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

Для РФ важно учесть требования 152‑ФЗ (персональные данные), а также хранение бэкапов и логов: где они размещены, как шифруются и как быстро удаляются.

Надежность: бэкапы и восстановление

Надежность — это не только аптайм, но и восстановление после ошибок. Минимум: регулярные резервные копии, проверка восстановления (не реже раза в квартал), план RPO/RTO и прозрачная коммуникация через /status.

MVP, план релизов и критерии успеха

Чтобы продукт действительно начал приносить пользу агентству, MVP должен закрывать ежедневную рутину: фиксацию времени, контроль перерасходов и базовую финансовую картину по проектам. Всё остальное — «приятные дополнения», которые легко построить позже.

Если вам важно быстро проверить гипотезу и показать команде работающий прототип, такой MVP удобно собирать на TakProsto.AI: это vibe‑coding платформа, где веб‑приложение можно собрать в формате «чата» и получить базовую архитектуру (React на фронтенде, Go + PostgreSQL на бэкенде), а затем — экспортировать исходники, развернуть и поддерживать уже как обычный продукт. Для агентств в РФ отдельно полезна локализация и то, что данные и инфраструктура остаются в России.

Что включить в MVP (без чего нельзя)

Минимальный набор функций:

• Тайм‑логи: таймер и ручной ввод, комментарий, привязка к проекту/задаче, billable/non‑billable.
• Табель (timesheet): недельный/месячный вид, подсветка недозаполненных дней, быстрые правки.
• Ставки: хотя бы уровень «сотрудник/роль + проект», с датой начала действия ставки.
• Базовая прибыльность: выручка (по ставкам или фикс‑сумме) vs себестоимость (по внутренним ставкам) + маржа.
• 3–5 ключевых отчётов: по проектам (план/факт часов), по людям (billable hours и загрузка), по клиентам, по периодам (месяц/неделя), список «перерасходов».

Главный принцип: каждое поле и экран должны отвечать на вопрос «что агентство сделает завтра иначе?».

План релизов: от внутреннего использования к внешнему

1. Внутренний запуск в агентстве: один процесс (например, закрытие недели), один набор ролей, один источник правды по ставкам.

2. Стабилизация и автоматизация: напоминания о табелях, согласование времени, закрытие периодов, более точные отчёты.

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

На этапе 2–3 полезно заложить «безопасные изменения» продукта: снапшоты и откат конфигурации (например, правил ставок и округления) сильно снижают риск, когда вы меняете финансовую логику в живой системе.

Критерии успеха: что измерять

• Доля заполненных табелей: например, 90% сотрудников заполняют неделю полностью к понедельнику.
• Точность прогнозов: разница между планом и фактом по часам/стоимости снижается из месяца в месяц.
• Снижение перерасходов: меньше проектов, где часы выходят за лимит без раннего сигнала.

Полезно заранее определить, какие отчёты попадут в тарифы (см. /pricing) и свериться с практиками учёта времени: /blog/uchet-vremeni-v-agentstve.