Веб-приложение для учёта корпоративных подарков помогает вести справочник получателей, кампании отправок, статусы доставки и контроль бюджета без хаоса в таблицах.
Учёт корпоративных подарков почти всегда начинается с таблицы: кому, куда, что отправили, сколько стоило. Пока получателей десять, это работает. Когда появляются несколько офисов, подрядчик по доставке и бухгалтерские правила, таблица быстро превращается в источник ошибок и споров.
Чаще всего «плывут» данные, которые нужны каждый день: актуальные адреса и телефоны, предпочтительный способ доставки, трек-номер, статус (собрано, отправлено, в пути, вручено), а также подтверждения и чеки. В итоге HR отвечает на одно и то же по кругу, офис-менеджер ищет «последнюю версию», а бухгалтерия пытается понять, какие расходы закрыты документами.
Excel ломается по предсказуемым причинам. Файлы начинают жить в копиях, правки не видны всем сразу, формулы случайно стирают. Ручной ввод даёт разные форматы адресов и сумм. Даже если настроить доступы, остаются человеческие ошибки: кто-то забывает обновить статус, кто-то меняет стоимость «на глаз», кто-то удаляет строку вместо того, чтобы отменить отправку.
Обычно в процессе участвуют разные роли, и у каждой своя зона ответственности:
Важно контролировать не только «отправили или нет». Нужны дедлайны (успеть к дате), бюджетные лимиты (по человеку, по отделу, по кампании) и подтверждение получения. Типичная ситуация: к празднику отправили 120 подарков, 15 адресов поменялись, по 8 доставкам нет статуса, а бюджет внезапно «перелетел» из-за срочной замены позиций. В этот момент становится понятно, зачем нужно веб-приложение для учёта корпоративных подарков: всё хранится в одном месте и обновляется по правилам, а не по настроению автора таблицы.
Чтобы учёт не превратился в хаос из таблиц и чатов, заранее договоритесь о базовых сущностях. Тогда система будет отвечать на простые вопросы: кому отправили, где посылка, сколько потратили, что осталось в бюджете.
Справочник - основа. Делайте его единым, чтобы не плодить дубликаты и не править адреса в десяти местах.
Минимальный набор:
Связи лучше продумать сразу, иначе статусы и деньги начнут расходиться.
Обычно работает такая логика:
Пример: к Новому году вы создали кампанию на 200 000 руб., добавили 120 получателей и запланировали доставку курьером. По мере отправок статусы меняются, трек-номера фиксируются, а фактические траты растут: стоимость подарка, доставка, иногда пересылка. Если посылка вернулась, запись не «перетирают». Добавляют событие возврата и создают новую отправку - тогда бюджет посчитается правильно.
Главный источник путаницы - когда статус меняют «на словах», а потом никто не помнит, что именно произошло и почему. Для каждой отправки нужен простой статус, понятный всем, и история изменений: кто поменял, когда и с каким комментарием.
Минимального набора обычно хватает, если он отражает реальный процесс: подготовка, отправка, доставка, финал (успешно или проблема). Не стоит плодить десятки статусов «для красоты», иначе люди начнут выбирать наугад.
Задайте правило: статус меняет только тот, кто получил подтверждение. Например, «Отправлено» ставит сотрудник, который оформил заказ, а «Доставлено» - тот, кто увидел подтверждение от курьера или получателя. При нестандартных ситуациях (задержка, отказ, неверный адрес) нужен комментарий.
Полезный минимум для истории:
Помимо истории, заведите отдельные даты: создание отправки, дата отправки, предполагаемая доставка, фактическая доставка, закрытие кейса (включая возвраты). Тогда отчёты не будут зависеть от того, «когда вспомнили проставить статус».
Подтверждения лучше хранить прямо в карточке: трек-номер, номер заказа у поставщика, примечания и, при необходимости, файл (скан накладной или скрин подтверждения). Если подарок вернулся из-за ошибки в индексе, вы быстро увидите, когда адрес проверяли и кто добавил исправление.
Бюджет в таких задачах обычно «течёт» не из-за цены подарка, а из-за мелочей вокруг него. Правила лучше закрепить прямо в системе: лимит на кампанию (общий потолок) и лимит на одного получателя (чтобы случайно не отправить VIP-набор всем подряд).
Практичный подход - хранить два числа: плановый лимит и «жёсткий» лимит. Плановый помогает следить за план-фактом, а жёсткий блокирует действия без согласования.
Что включать в стоимость, чтобы контроль был честным:
В карточке отправки удобно держать раздельные поля по статьям и итог «всего». Тогда видно, почему две одинаковые коробки вдруг стоят по-разному.
Если выходит перерасход, не делайте это «невидимым». Лучше заложить простой сценарий: система показывает предупреждение, просит выбрать причину и добавить комментарий, а затем переводит запись в статус «ожидает согласования». Исключения должны быть явными: кто согласовал, когда и на какую сумму.
Пример: на 8 марта вы поставили лимит кампании 300 000 ₽ и по 3 000 ₽ на человека. Для одного получателя доставка в удалённый город добавила 1 200 ₽, и итог превысил лимит. Система блокирует отправку, вы добавляете комментарий «срочная доставка, адрес подтверждён», руководитель отмечает «согласовано», и перерасход попадает в отчёт.
Для бухгалтерии важно быстро выгрузить понятный план-факт и собрать «хвосты» по документам. Обычно хватает четырёх отчётов: план vs факт по кампании и подразделениям, реестр отправок с суммами и статьями расходов, список недостающих документов и журнал согласований перерасхода.
Хороший интерфейс держится на одном принципе: за 30 секунд понятно, что нужно сделать сегодня. Для этого нужны рабочие экраны, а не «универсальная таблица на всё».
Обычно хватает трёх списков: по кампании (что отправляем и когда), по статусу (что застряло), по ответственному (у кого какие задачи). В списках показывайте только важное: получатель, адрес, подарок, статус, дедлайн, стоимость, комментарий.
Полезны сохранённые представления: «К отправке сегодня», «Ожидаем трек-номер», «Вернулось на склад», «Нужна проверка адреса». Тогда меньше ручной сортировки.
Поиск должен работать «как в почте»: ввели часть ФИО, города или подразделения - сразу увидели совпадения. Фильтры держите короткими и прикладными: кампания, статус, ответственный, город, подразделение, наличие трек-номера, диапазон дат, диапазон суммы.
Карточка получателя по клику должна показывать историю: когда обновляли адрес, кто менял статус, какие были попытки доставки. Это помогает решать спорные ситуации без звонков «по кругу».
Для рутины важны пакетные действия: массовое обновление статусов, импорт адресов с понятной проверкой ошибок, массовое назначение ответственного и дедлайна, выгрузка отчёта по кампании.
Уведомления должны приходить не всем подряд, а тем, кто реально может решить проблему. Например: ответственному - если статус не менялся 3 дня; руководителю - если просрочено больше N отправок; финансовому контролёру - если кампания приближается к лимиту бюджета.
Пример: менеджер запускает кампанию «8 Марта», импортирует 120 адресов, фильтрует «без квартиры», массово ставит статус «нужна уточняющая информация» и назначает ответственную HR. Через день HR закрывает карточки, а система напоминает логисту, что 15 отправок всё ещё без трек-номера.
Если делать веб-приложение через AI-кодинг, сначала опишите правила словами, а уже потом думайте про «красоту интерфейса». Когда правила зафиксированы, экраны и проверки получаются заметно точнее.
Запишите, как будто объясняете коллеге: кто получатели, что такое кампания, что считается отправкой, какие суммы можно вводить. Пример формулировок:
Дальше уточните связи и ограничения: один получатель участвует в нескольких кампаниях, у кампании много отправок. Отдельно проговорите уникальность (например, один и тот же получатель не должен появляться в кампании дважды).
Чаще всего хватает четырёх экранов: список получателей, карточка получателя, создание кампании, отчёт по бюджету. Добавьте фильтры по кампании и статусу и быстрый поиск по имени или телефону.
Валидации ловят большую часть проблем до того, как они превращаются в возвраты и перерасход:
Перед запуском заведите 10-20 получателей и проверьте реальные действия:
После этого уже имеет смысл добавлять роли доступа и более сложные отчёты.
В таком приложении почти всегда хранятся персональные данные: ФИО, адрес доставки, телефон, иногда комментарии курьера. Это чувствительная часть проекта. Проще сразу заложить понятные правила, чем потом разбирать последствия.
Разделите доступ по ролям. Логистике нужны адреса и статусы, но не внутренние бюджеты. Финансам важны суммы и лимиты, но адреса можно скрыть или показывать частично. Руководителю обычно достаточно сводных отчётов.
Практичный минимум:
Каждое лишнее поле увеличивает риск. Если для доставки хватает ФИО, города и пункта выдачи, не собирайте домашний адрес. Если телефон нужен только на этапе отправки, продумайте срок хранения или возможность очистки после закрытия кампании.
Чтобы было видно, кто и когда менял данные, включите логи действий. В журнале достаточно хранить: кто сделал изменение, что изменилось, когда, к чему относится (получатель, отправка, кампания) и почему (короткий комментарий, если он обязателен).
И ещё одно: защита от потерь. Перед крупными изменениями схемы или правил подсчёта бюджета делайте резервную копию. Снапшоты и быстрый откат особенно выручают, когда процесс уже идёт и нельзя «падать» на пару дней.
Самая частая причина хаоса - смешивание разных кампаний в одной таблице. Сегодня вы отправляете наборы к 8 марта, завтра мерч для новичков, а через месяц подарки партнёрам. Если у строки нет явного идентификатора кампании, отчёты начинают врать: непонятно, что закрыто, что переносится и где перерасход.
Вторая ловушка - отсутствие единого справочника получателей. Когда адреса хранятся «как получилось» в каждой кампании, появляются дубли: один и тот же человек записан дважды, а адреса чуть разные. В итоге вы платите за повторную доставку или отправляете подарок не туда. Лучше один профиль получателя и несколько актуальных адресов с пометкой «основной» и датой обновления.
Со статусами тоже легко испортить картину. Когда статусы меняют задним числом без причины, доверие к данным исчезает. Попросили курьера - поменяли на «доставлено», а потом выяснилось, что получатель не на месте. Без комментария и истории изменений вы не поймёте, где был сбой.
Ещё одна неприятность - бюджет считают только по стоимости подарка и забывают доставку, упаковку, открытки, брендирование и комиссию. На небольших партиях это незаметно, а на сотнях отправок превращается в серьёзную сумму.
Набор правил, который ловит большинство ошибок:
На практике это выглядит так: менеджер добавляет ещё 20 отправок, а система сразу показывает, что с доставкой бюджет уже превышен на 12%. Это лучше, чем узнавать об этом после выставленного счёта.
Перед тем как отдавать приложение в работу, пройдитесь по короткой проверке. Это занимает 15-20 минут, но экономит дни на исправлениях после первой же рассылки.
Сначала убедитесь, что данные можно однозначно сопоставлять и нельзя «потерять» человека из-за дубля. Для получателей важны постоянный идентификатор (например, табельный номер или внутренний ID) и актуальный адрес доставки. Если поле критично для отправки, оно должно быть обязательным и проходить простую проверку формата.
Дальше проверьте кампании: у каждой должны быть владелец, сроки и бюджет с понятными правилами. Зафиксируйте, что входит в лимит (подарок, доставка, упаковка) и в какой момент сумма считается фактической.
Короткий контроль перед стартом:
Представим новогоднюю кампанию на 120 сотрудников в 15 городах. Цель простая: всем отправить подарки вовремя, не потерять адреса и не выйти за бюджет, даже если доставка в регионы окажется дороже.
Сначала заводите справочник получателей. Обычно список приходит от HR в таблице: ФИО, город, адрес, телефон, подразделение, комментарии (например, «только курьер после 18:00»). Загружаете список в систему и сразу делите людей на группы по смыслу: «Москва и область», «Регионы», «Удалёнка» и отдельная группа «Адрес уточняется». Так проще находить проблемные записи.
Дальше создаёте кампанию «Новый год 2026» и добавляете в неё получателей. На этом шаге удобно зафиксировать план: тип подарка, плановую стоимость, плановую доставку и общий лимит. Например, 3 000 руб на подарок и 700 руб на доставку, лимит кампании 444 000 руб.
Потом начинается операционная часть. Подарки уходят партиями. После первой недели в трекере видно картину: отправили 40, в пути 60, возврат 5, ещё 15 не готовы из-за неверных адресов. Важно вести не только текущий статус, но и причину, если что-то пошло не так: «не дозвонились», «адрес неполный», «отказ получателя». Это экономит часы переписок.
С бюджетом обычно всплывает сюрприз: часть доставок в регионы выходит дороже плана. Вы отмечаете фактическую стоимость доставки и сразу видите, где превышение. Если лимит поджимает, решение принимается быстрее: сменить службу доставки для части городов, заменить подарок на более дешёвый для группы или согласовать допбюджет.
К закрытию кампании подготовьте короткие отчёты: покрытие (сколько получили и сколько осталось), проблемные случаи (возвраты, уточнение адреса, повторные отправки), бюджет (план против факта по подаркам и доставке), сроки (среднее время от «создано» до «доставлено»), остатки на складе.
Пилот проще запускать не «на всём сразу», а на одной понятной кампании. Цель - проверить, что система реально экономит время: меньше ручных таблиц, меньше потерь адресов, понятнее статусы и остаток бюджета.
Обычно хватает такого плана:
Дальше двигайтесь короткими итерациями: выпустили первую версию, неделю поработали, собрали обратную связь, поправили поля и статусы. Часто выясняется, что важнее не «красивые отчёты», а пара быстрых фильтров, поле «комментарий» и нормальная история изменений.
Если хотите собрать такой трекер через vibe-coding без классической разработки, это можно сделать в TakProsto (takprosto.ai): сначала описать сущности и правила в planning-режиме, затем быстро получить рабочие формы и проверки, а изменения фиксировать снапшотами с возможностью отката.
Когда пилот прошёл и структура данных устоялась, имеет смысл подключать экспорт исходников, деплой/хостинг и свой домен, а затем переходить к интеграциям: выгрузка адресов подрядчику доставки, загрузка трек-номеров обратно, напоминания ответственным, если статус не менялся 3-5 дней или бюджет близок к лимиту.
Обычно таблица начинает «разъезжаться» сразу, как появляется несколько ролей и параллельные правки. Копии файла, разные форматы адресов и сумм, случайно стёртые формулы и забытые статусы быстро превращают учёт в спор «у кого версия правильнее».
Сделайте единый профиль получателя и храните в нём актуальные контакты и адреса, а не копируйте их в каждую кампанию. Тогда вы исправляете телефон или индекс один раз, и это влияет на все будущие отправки, без поиска по десяткам строк.
Заведите сущности «Кампания» и «Отправка» и связывайте каждую отправку с одной кампанией и одним получателем. Это сразу отвечает на вопросы «кому отправили», «где посылка» и «сколько уже потратили» без смешивания разных праздников и поводов в одной куче.
Держите короткую цепочку статусов, которая повторяет реальный процесс: подготовили, отправили, в пути, доставили, закрыли проблему. Параллельно сохраняйте историю изменений с автором, временем и комментарием, чтобы потом было видно, почему статус поменяли и на основании чего.
По умолчанию статус меняет тот, кто получил подтверждение: «Отправлено» ставит тот, кто оформил отправку, а «Доставлено» — тот, кто увидел подтверждение вручения. Если статус правят задним числом или из-за нестандартной ситуации, требуйте короткий комментарий, иначе данные быстро перестают быть надёжными.
Считайте полную себестоимость: сам подарок, упаковку, доставку, комиссии и повторные отправки или возвраты. Тогда план-факт честный, и перерасход виден сразу, а не после счёта от подрядчика.
Самый понятный вариант — предупреждать заранее и блокировать действие при «жёстком» лимите без согласования. В карточке фиксируйте причину и кто согласовал перерасход, чтобы он попал в отчёты и не превращался в «невидимую» дыру в бюджете.
Должно быть видно, что делать сегодня: список по кампании, список «что застряло по статусам» и список по ответственному. Если за 30 секунд можно найти отправки без трек-номера, просроченные дедлайны и записи с проблемным адресом, операционная работа становится спокойнее.
Разделите доступ по ролям: логистике нужны адреса и статусы, финансам — суммы и документы, а наблюдателям — только сводки. Храните минимум персональных данных, который реально нужен для доставки, и включите журнал действий, чтобы было видно, кто и что менял.
Начните с описания сущностей и правил простыми словами, затем соберите минимальные экраны и валидации, и прогоните сценарии на 10–20 получателях. В TakProsto удобно делать это через planning-режим, а перед крупными правками сохранять снапшоты, чтобы быстро откатиться, если что-то пошло не так.
