План создания веб‑приложения для агентства: требования, роли, модель данных, таймеры и табели, расчёт маржи, отчёты, интеграции и безопасность.
Это приложение нужно не «для учета часов вообще», а чтобы агентство быстрее принимало управленческие решения на основе фактов: сколько времени реально уходит на проекты, что можно выставить клиенту, и где прибыль «утекает».
Владельцу агентства — видеть маржинальность по проектам и общий прогноз: какие проекты кормят команду, а какие незаметно съедают ресурсы.
Аккаунт-менеджеру — объяснять клиенту статус работ и обосновывать счета: что сделано, сколько времени списано, что осталось в рамках договоренностей.
Проджект-менеджеру — управлять перерасходом: замечать отклонения по этапам и ролям до того, как проект уйдет в минус.
Исполнителям — удобно фиксировать время без лишней бюрократии, чтобы не вспоминать в конце недели «куда делся день».
Бухгалтерии/финансам — получать основу для инвойсинга и сверок без ручных таблиц.
Продукт должен регулярно отвечать на простые, но критичные вопросы:
Исполнитель запускает таймер или добавляет запись в табель.
Проджект проверяет корректность и согласует время за период.
Аккаунт формирует данные для счета и отправляет клиенту (или выгружает в интеграцию).
Руководитель смотрит дашборды: прибыльность проектов и тренды.
Важно сразу зафиксировать рамки. Это не полноценная CRM и не бухгалтерия: здесь не нужно строить воронку продаж, вести склад документов или делать регламентированный учет.
Фокус — учет рабочего времени, управленческая прибыльность и удобный путь от табеля до инвойса.
Правильная модель ролей — это не «формальность», а способ избежать конфликтов в команде и утечек чувствительных данных. В приложении для учета рабочего времени ставки, себестоимость и прибыльность должны быть видны только тем, кому они реально нужны для работы.
Админ — настраивает систему: структуру агентства, справочники, ставки, правила согласования, интеграции. Обычно имеет полный доступ, но даже ему полезно разделять «администрирование» и «финансы», чтобы не раздавать лишние права.
Менеджер — ведет проекты, распределяет людей, контролирует заполнение тайм‑логов и готовит отчеты для клиента. Ему важно видеть план/факт по часам и отклонения, но не всегда нужно видеть внутреннюю себестоимость.
Сотрудник — ведет свои тайм‑логи, видит свои задачи, статусы согласования и историю правок. Доступ к финансовым показателям — по умолчанию закрыт.
Клиент (опционально) — видит только согласованные часы и отчеты по своему проекту, без внутренних ставок и маржинальности.
Финансы (опционально) — отвечает за ставки, биллинг, инвойсы и контроль прибыльности. Должен видеть «продажную» ставку, себестоимость, маржу и сводные отчеты.
Рекомендуем разделить как минимум три уровня данных:
Удобная схема — матрица «пользователь ↔ проекты» с ролью на проекте (например, участник/менеджер/наблюдатель). Дополнительно можно вводить ограничения по:
Любые правки, влияющие на деньги и отчетность, должны логироваться: кто изменил часы, дату, проект, ставку, статус утверждения, а также причину изменения.
Минимальный набор: журнал аудита с фильтрами (пользователь/проект/период), хранение «до/после» и запрет редактирования после закрытия периода без специального права (например, «Разблокировать период»).
Чтобы учет времени действительно превращался в понятные деньги и маржинальность, модель данных должна быть сквозной: от записи о работе до счета клиенту и управленческой прибыли.
Минимальный набор объектов обычно выглядит так:
Ключевой принцип: тайм‑лог всегда связан минимум с проектом и сотрудником, а лучше — ещё и с этапом/задачей. Тогда отчеты не превращаются в ручную сводку в таблице.
У тайм‑лога стоит зафиксировать обязательные поля:
Отдельно полезно хранить «расчетные» поля (их можно вычислять, но удобнее кэшировать): ставка клиента, себестоимость часа, сумма к выставлению, себестоимость тайм‑лога.
Чтобы управлять процессом, введите статусы для тайм‑лога или табеля:
черновик → отправлено → утверждено → заблокировано для правок.
На практике удобнее утверждать табель за период (неделя/месяц), а тайм‑логи наследуют состояние периода. Это упрощает «закрытие месяца» и снижает число спорных правок.
Если в системе есть деньги, нужна история изменений: кто, когда и что поменял (длительность, billable, проект, описание). Это помогает разбирать споры с клиентом и внутри команды.
Правила округления задайте на уровне проекта или клиента: например, до 5/10/15 минут. Важно хранить сырое время и округленное время отдельно: так вы не потеряете точность для аналитики, но сможете корректно выставлять счета по договору.
Учет времени — это «точка правды» для billable hours, себестоимости и последующей прибыльности проектов. Поэтому важны не только отчеты, но и то, насколько легко людям фиксировать работу без раздражения и потерь данных.
Таймер должен запускаться в два клика: выбор проекта и (опционально) задачи, затем старт. Дальше — пауза и стоп, а при остановке система предлагает добавить описание и теги (например, «созвоны», «правки», «подготовка»).
Критично автосохранение: если вкладка закрылась, пропал интернет или браузер перезагрузился, текущий прогресс не должен исчезать. Практика: сохранять «черновик таймера» локально и периодически синхронизировать с сервером, показывая пользователю статус («сохранено», «ждет отправки»).
Ручной ввод нужен всегда: ретро‑внесение, работа «вне ноутбука», корректировки по просьбе менеджера. Ускоряют процесс:
Важно, чтобы ручной ввод и таймер создавали одинаковые записи в одной модели данных — это упрощает валидации и отчеты.
На мобайл‑веб чаще всего фиксируют «черновые» записи: быстро запустить таймер, поставить паузу, добавить короткий комментарий. Минимальный оффлайн‑режим: создание/редактирование записей и очередь синхронизации при появлении сети.
Пользователь должен видеть, какие записи еще не отправлены, и иметь возможность принудительно синхронизировать.
Чтобы данные годились для биллинга, добавьте мягкие, но заметные проверки:
Проверки лучше делать в момент ввода (чтобы исправить сразу), но оставлять возможность сохранить черновик и вернуться позже — это снижает сопротивление команды.
Ставки — это «переводчик» между временем команды и деньгами. В продукте почти всегда нужны две сущности: клиентская ставка (сколько вы выставляете) и внутренняя себестоимость (во что вам обходится час конкретного сотрудника или роли). Они живут рядом, но служат разным задачам: первая — для счета и выручки, вторая — для расчета маржи.
Практичный минимум:
Важно разделять «по умолчанию» и «переопределения»: ставка может браться из профиля роли, но переписываться на уровне проекта или конкретного клиента.
Time & Materials (T&M) — самая прямая модель: подтвержденные часы × ставка. В продукте она хорошо ложится на правило «каждый тайм‑лог знает, billable он или нет», а ставка подтягивается по выбранной матрице.
Фиксированная стоимость — счет не зависит от часов, но часы нужны для контроля перерасхода и реальной маржинальности. Минимально достаточно: фикс‑бюджет проекта + внутренний учет фактических часов.
Ретейнер — регулярная сумма за период (месяц/квартал) с включенными часами или без них. Полезные опции: «включено N часов», «перенос остатков» (можно отложить на более поздний релиз) и учет сверхлимита по отдельной ставке.
Пакет часов — предоплаченные часы, которые «сгорают» по мере логирования. Нужны правила списания: по роли, по типу работ, по проекту.
Поддержите несколько осей переопределения: роль (дизайнер/аккаунт/разработчик), тип работ (консалтинг/поддержка/срочно), период (изменение ставок с даты) и проект/клиент.
При конфликте правил задайте прозрачный приоритет, чтобы пользователю было понятно, «почему получилась такая сумма».
Достаточно хранить:
Налоги на старте лучше не «высчитывать магически»: дайте настройку процента/режима и возможность ручной корректировки в счете — так вы избежите споров из‑за разных юрисдикций и округлений.
Чтобы приложение было полезно руководителю агентства, оно должно отвечать на простой вопрос: «Мы зарабатываем на этом проекте или сжигаем время команды?». Для этого в системе нужна прозрачная формула выручки и себестоимости, а также метрики, которые подсвечивают риски заранее.
Базовый принцип: выручка считается только по утверждённым (approved) billable‑часам. Это защищает от «надувания» отчётов и расхождений с клиентом.
Удобно хранить выручку в разрезе проекта, этапа/вехи и периода (неделя/месяц), чтобы отчёты сходились с закрытием периодов.
Revenue_T&M = ApprovedBillableHours × ClientRate
Минимальная модель себестоимости строится на внутренних ставках:
Cost = TrackedHours × InternalRate + DirectExpenses
Где DirectExpenses — прямые расходы при необходимости (подрядчики, платные сервисы, комиссии). Важно разделять:
Маржа и маржинальность — основной индикатор качества проекта:
Для управления командой нужны также:
В фикс‑контрактах ключевое — договориться, как «распознаётся» выручка:
Лучше сделать это настройкой проекта, иначе разные менеджеры будут считать прибыльность по‑разному — и сравнивать проекты станет невозможно.
Отчеты — это место, где учет времени превращается в управленческие решения. Чтобы ими действительно пользовались, разделите интерфейс по ролям: руководителю нужен обзор и сигналы риска, менеджеру — контроль бюджета и прогноз, сотруднику — простой табель и подсказки.
Руководителю важна прибыльность в разрезах, а не «сколько часов нащелкали». На первом экране стоит показать:
Полезная деталь: «светофор» по проектам (зеленый/желтый/красный) на основе правил, которые можно настроить — например, перерасход > 10% или маржа ниже порога.
Менеджеру нужен инструмент ежедневного контроля. Минимальный набор:
Сделайте проваливание из цифры в детали: к задачам, людям и конкретным тайм‑логам — чтобы менеджер мог быстро найти источник перерасхода.
Сотруднику нужен понятный табель и напоминания:
Важно: не превращайте табель в контроль ради контроля — покажите, что корректные записи помогают команде защищать бюджет и избегать авралов.
Заранее заложите форматы:
Если планируете расширение, добавьте страницу /reports с сохраненными шаблонами отчетов и правами доступа: один и тот же отчет должен выглядеть по‑разному для разных ролей.
Даже лучший тайм‑трекер теряет смысл, если данные «плавают»: кто-то забывает заполнить дни, кто-то правит прошлый месяц после выставления счета, а руководитель проекта не понимает, чему верить. Поэтому в продукте нужен понятный процесс согласования (approval) и жесткие правила закрытия периодов.
Сделайте простую, но управляемую цепочку статусов для записей времени и табелей (например, неделя/месяц):
Практика: разрешите менеджеру в одном экране видеть отклонения от плана (например, «слишком много небиллимых часов» или «работы не из списка»), чтобы комментарии были предметными.
Закрытие периода — это момент, когда числа становятся «официальными». Введите блокировки:
Автоматические напоминания заметно повышают качество данных:
Сохраняйте неизменяемый журнал: кто и когда отправил табель, кто утвердил, что именно было отклонено, какие причины указаны. Эта история снимает споры, помогает разбирать перерасход и упрощает внутренние проверки.
Инвойсинг — это место, где тайм‑логи превращаются в деньги. Ошибка здесь стоит дороже всего: клиент спорит, менеджер переделывает, финансы сходятся вручную. Поэтому правило №1: инвойс формируется только из утвержденных часов (и утвержденных фикс‑позиций), а не «как есть».
Базовый поток выглядит так:
Важно предусмотреть «корректировки» отдельной строкой: скидка, округление, компенсации, дополнительные расходы. Тогда инвойс остается прозрачным, а не превращается в набор непонятных правок.
Не всем клиентам нужна детализация до минуты. В интерфейсе стоит поддержать два режима:
Критично уметь скрывать внутренние пометки и служебные теги (например, «обучение», «внутренний созвон»), оставляя клиенту только то, что согласовано.
Хорошая практика — иметь поле «Комментарий для клиента» отдельно от внутреннего.
Приоритизируйте интеграции, которые сокращают ручной ввод и ускоряют оплату:
На старте почти всегда нужен импорт: сотрудники, клиенты, проекты, ставки, а иногда и исторические тайм‑логи. Сделайте простой мастер импорта (CSV + проверка ошибок) и маппинг полей.
Чем быстрее команда увидит знакомые данные в системе, тем легче пройдет внедрение.
Учет рабочего времени и финансов быстро превращается в «систему истины» для агентства: в ней есть персональные данные, внутренние ставки, бюджеты и история проектов. Поэтому безопасность нужно проектировать сразу, а не «добавлять потом».
Базовый вариант — логин по почте с подтверждением и опционально SSO (Google/Microsoft) для корпоративных команд. Для администраторов и пользователей с доступом к ставкам/финансам включайте 2FA как минимум по TOTP.
Политика паролей должна быть понятной и выполнимой: минимальная длина, проверка на утечки (например, по спискам скомпрометированных паролей), ограничение числа попыток входа и «мягкая» блокировка. Сессии — с ротацией токенов и возможностью принудительного выхода со всех устройств.
Если в одном аккаунте ведутся несколько клиентов, важно исключить случайную утечку данных «между проектами». Минимальный набор:
На уровне хранения данных применяйте строгую изоляцию по tenant/организации, а для экспорта (CSV/PDF) — маркируйте, кто и когда выгружал данные.
Нужны два вида журналов: технические (ошибки, производительность) и аудит‑логи (входы, изменения ставок, прав, закрытие периодов). Аудит‑логи должны быть неизменяемыми и с понятным фильтром.
Добавьте мониторинг подозрительных действий: массовые экспорты, частые неуспешные входы, резкие скачки API‑запросов. Для API — лимиты (rate limiting) и ключи с ограничением прав.
Определите, какие персональные данные вы храните и зачем: обычно достаточно имени, почты и привязки к организации. Зафиксируйте сроки хранения тайм‑логов и финансовых документов, политику удаления и выгрузки данных по запросу клиента.
Для РФ важно учесть требования 152‑ФЗ (персональные данные), а также хранение бэкапов и логов: где они размещены, как шифруются и как быстро удаляются.
Надежность — это не только аптайм, но и восстановление после ошибок. Минимум: регулярные резервные копии, проверка восстановления (не реже раза в квартал), план RPO/RTO и прозрачная коммуникация через /status.
Чтобы продукт действительно начал приносить пользу агентству, MVP должен закрывать ежедневную рутину: фиксацию времени, контроль перерасходов и базовую финансовую картину по проектам. Всё остальное — «приятные дополнения», которые легко построить позже.
Если вам важно быстро проверить гипотезу и показать команде работающий прототип, такой MVP удобно собирать на TakProsto.AI: это vibe‑coding платформа, где веб‑приложение можно собрать в формате «чата» и получить базовую архитектуру (React на фронтенде, Go + PostgreSQL на бэкенде), а затем — экспортировать исходники, развернуть и поддерживать уже как обычный продукт. Для агентств в РФ отдельно полезна локализация и то, что данные и инфраструктура остаются в России.
Минимальный набор функций:
Главный принцип: каждое поле и экран должны отвечать на вопрос «что агентство сделает завтра иначе?».
Внутренний запуск в агентстве: один процесс (например, закрытие недели), один набор ролей, один источник правды по ставкам.
Стабилизация и автоматизация: напоминания о табелях, согласование времени, закрытие периодов, более точные отчёты.
Клиентский портал — только если нужен: доступ клиента к отчётам/инвойсам и прозрачность по прогрессу. Не делайте это первым релизом: внешний интерфейс часто удваивает требования к правам, поддержке и качеству данных.
На этапе 2–3 полезно заложить «безопасные изменения» продукта: снапшоты и откат конфигурации (например, правил ставок и округления) сильно снижают риск, когда вы меняете финансовую логику в живой системе.
Полезно заранее определить, какие отчёты попадут в тарифы (см. /pricing) и свериться с практиками учёта времени: /blog/uchet-vremeni-v-agentstve.
Начните с «точек решений» агентства: сколько часов продано/списано, где перерасход, какая маржа и загрузка команды.
Практичный MVP:
Чтобы быстро принимать управленческие решения на фактах:
Минимальный набор ролей:
Опционально:
Рекомендуем разделить минимум на 3 уровня:
Так вы снижаете риски утечек зарплатных данных и конфликтов в команде.
Чтобы отчеты сходились без ручных сводок, тайм‑лог должен иметь связи минимум с:
Обязательные поля:
Лучше вводить статусы для периода (неделя/месяц), чтобы «закрытие» было управляемым:
Практика:
Поддержите оба способа и приводите их к одной модели данных:
Контроль качества без раздражения:
В продукте обычно нужны две ставки:
И важно поддержать переопределения по:
При конфликтах задайте прозрачный приоритет, чтобы было понятно, почему получилась сумма.
Базовые формулы:
Для фикс‑проектов заранее задайте правило признания выручки:
Инвойс должен формироваться только из утвержденных данных и фиксироваться версионно.
Рекомендуемый поток:
Полезно хранить отдельное поле «комментарий для клиента», чтобы скрывать внутренние пометки.