← Все работыCRM для IT-компании · Заказная разработка

CRM, в которой договор не может разойтись с актом

Своя CRM студии разработки: договор, ТЗ, счёт и акт собираются в PDF из одной карточки проекта, клиент принимает этапы в своём кабинете по пунктам ТЗ, а каждое его замечание сразу становится задачей в GitHub. Это CRM для IT-компании, которой мы пользуемся сами.

Что на самом деле сложно, когда строишь «CRM для IT-компании»

В заказной разработке проект живёт сразу в нескольких местах: деньги и сроки — в таблице, договор — в текстовом редакторе, замечания клиента — в переписке, задачи — в трекере. Каждое из этих мест по отдельности в порядке. Беда начинается на стыках: сдвинули срок этапа, а календарный план в договоре остался прежним; поменяли сумму, а счёт на предоплату выставили по старой; клиент написал «на телефоне кнопка не работает», а в трекер это дошло без сборки, устройства и шагов. Готовые CRM здесь помогают слабо: они построены вокруг сделки и воронки, а у студии единица работы — проект с этапами, ТЗ и приёмкой. Сделка закрывается один раз. Проект закрывается этап за этапом, и у каждого этапа свои деньги, свой акт и свой список того, что клиент должен проверить. Нам нужна была система, где всё это считается из одного места, — и где клиент участвует в приёмке сам, а не через пересказ менеджера.

Где в этом продукте прячется работа

Документы из одного источника

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

Этап — это сразу деньги, срок и приёмка

В заказной разработке этап не описать строкой «сделано / не сделано». У него есть срок, стоимость, предоплата и постоплата, акт, который его закрывает, и список того, что клиент должен проверить. Если хоть что-то из этого живёт отдельно, оно отстаёт. В карточке проекта этап держит всё сразу, и календарный план в договоре — это те же этапы, выведенные в документ, а не их пересказ.

Приёмка по пунктам ТЗ, а не «в целом»

«Посмотрите, всё ли нормально» — худший способ принять этап: клиент смотрит на то, что заметно, и пропускает то, что важно. Здесь клиент идёт по чек-листу из пунктов ТЗ, и каждый пункт либо принят, либо у него есть проблема. Найденная проблема сразу становится задачей в GitHub, и в ней уже есть всё, что разработчику обычно приходится выспрашивать: этап, пункт ТЗ, сборка, устройство, шаги, ожидаемое и фактическое. Между словами клиента и задачей разработчика не стоит пересказ менеджера — значит, по дороге ничего не теряется.

Кабинет без логина

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

Рабочая группа в Telegram появляется сама

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

Тесты там, где ошибка стоит подписи

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

Как это выглядит

Снимки того же стенда, что открывается выше: данные вымышленные, шаги — те, что подсказывает сам стенд.

Календарный план к договору собран из той же карточки проекта — с новой суммой этапа.
Клиент принимает этап по пунктам ТЗ, и замечание сразу стало задачей со сборкой, устройством и шагами.

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

Опорой системы стали документы. Если календарный план, суммы и сроки живут в карточке проекта, а договор, ТЗ, счёт и акт из неё только выводятся, ручная сверка исчезает, а всё, что осталось от работы с документами, становится проверяемым.

Приёмку мы строили от ТЗ, а не от интерфейса. Пункты ТЗ становятся чек-листом этапа, и проблемный пункт сразу превращается в задачу с теми полями, которые нужны разработчику, чтобы воспроизвести проблему. Клиент работает в кабинете без логина: ссылку открыть проще, чем вспомнить пароль, а приёмка, которую откладывают, — это постоплата, которая не приходит.

Всё, что нельзя ломать, закрыто тестами: на документы, печатные формы, кабинет и приёмку их 561. Рядом работает бот приёма багов из рабочего чата — о нём отдельный раздел этой страницы, — и он заканчивает цепочку так же: задачей в GitHub. Замечание из кабинета и баг из чата сходятся в одном трекере.

И мы пользуемся этим сами: договоры, акты и приёмка этапов наших проектов идут через эту систему. Свой продукт — самая строгая проверка: неудобный экран мы видим раньше, чем его увидит клиент.

561

тест на документы, печатные формы, кабинет клиента и приёмку этапов

4 вида

документов собираются в PDF из карточки проекта: договор, ТЗ, счёт, акт

Без входа

клиент открывает кабинет и принимает этап по одной секретной ссылке

Express 5Prisma 7PostgreSQLReact 19VitezustandTelegram Bot APIGitHub REST API

Бот приёма багов: из рабочего чата сразу в GitHub

Тестировщики и заказчики пишут о багах в рабочий чат проекта — и там баги теряются: сообщение уезжает вверх, скриншот приходит отдельно от описания, а потом никто не помнит, исправили ли. Поэтому рядом с CRM работает наш бот приёма багов. Он по шагам собирает баг — где он, заголовок, описание текстом или скриншотом, — показывает сводку и заводит задачу в GitHub в нужный репозиторий. В задаче сразу есть кто сообщил, область со слов тестировщика, описание, скриншот и метка «не разобрано».

Дальше бот работает в обратную сторону. Когда задачу закрыли, он пишет в чат «Баг исправлен» с резолюцией, а вопросы разработчика пересылает тестировщику: разговор о баге идёт там, где баг заметили. По команде бот показывает статистику проекта — сколько багов всего, сколько исправлено, сколько признано вне объёма работ, сколько критичных, по областям и за неделю.

Сам бот — один скрипт на стандартной библиотеке Python, без лишних зависимостей, запущенный как служба. У него 158 тестов в собственном наборе, а связку бота с CRM — маршруты, поля, набор меток и роли того, кто сообщил, — держат ещё 39 контрактных тестов на стороне CRM. Пользуемся им в своих проектах с 2026 года. Так приёмка в кабинете и баги из чата сходятся в одной точке — в задаче в GitHub, откуда бы замечание ни пришло.

Python (стандартная библиотека)Telegram Bot APIGitHub REST APIsystemd

Из чего он собран

Из каких услуг он собран и сколько это стоит

Разбору верят охотнее, чем странице услуги, а купить по нему сложнее. Ниже — услуги, из которых этот продукт собран на самом деле, у каждой своя страница с ценой и объёмом.

от 900 000 ₽

Начинается от

десять недель до первой рабочей версии

Первая рабочая версия

Это первая версия CRM, в которой команда работает каждый день: проекты по этапам, деньги и сроки в карточке и документы, которые из неё собираются. Кабинет клиента с приёмкой по пунктам ТЗ можно заказать и отдельно — от 500 000 ₽ за восемь недель. Цену двигают не экраны, а интеграции и перенос истории из старых таблиц: каждая интеграция — отдельный кусок работы, и мы называем его до старта.

Что спрашивают про такие продукты

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

Та, что считает проект, а не сделку. У IT-компании, которая работает на заказ, единица работы — проект с этапами, ТЗ и приёмкой, и у каждого этапа свои деньги и свой акт. Коробка хорошо ведёт воронку продаж; проект с этапами, документами и приёмкой — то, что к ней приходится достраивать. Мы собрали свою CRM, где документы считаются из карточки проекта, а приёмка идёт по пунктам ТЗ.

Да, и ради этого свою систему стоит строить в первую очередь. Здесь договор, ТЗ, счёт и акт собираются в PDF из карточки проекта: календарный план, предоплата, постоплата и сроки берутся из одних данных, поэтому документы не расходятся между собой. В вашей системе это будут ваши шаблоны и ваши реквизиты — логика та же.

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

Первая версия, в которой команда работает каждый день, — от 900 000 ₽ за десять недель. Если нужен только кабинет клиента с приёмкой — от 500 000 ₽ за восемь недель. Оплата по этапам: сумма этапа не растёт, пока не меняется объём. Цену двигают перенос истории и интеграции — здесь это GitHub и Telegram, — а не количество экранов.

Через бота в рабочем чате проекта. Тестировщик пишет /bug, бот по шагам собирает область, заголовок и описание — текстом или скриншотом — и заводит задачу в GitHub с меткой «не разобрано». Когда задачу закрывают, бот сам пишет в чат «Баг исправлен». Подробнее — в разделе про бота приёма багов.

Глубже по теме

Интеграция CRM с 1С: какие данные куда идут и кто за них отвечает
Обмен между CRM и 1С ломается не на программировании, а на вопросе, чья запись главная. Разбираем по объектам: контрагенты, счета, оплаты и отгрузки — что куда идёт и кто за это отвечает.
Как внедрить CRM: десять недель по этапам и что в них делаете вы
Внедрение CRM проваливается не на программировании, а на решениях, которые никто не принял вовремя. Десять недель по порядку: что делает подрядчик, что решаете вы и что остаётся у вас после каждого этапа.
Замена CRM-системы: как перенести базу и не потерять полезную половину
При замене CRM-системы перенос проходит в смете одной строкой, а на деле оказывается одной из самых больших частей работы. Хорошая новость: это единственный перерасход, который виден заранее.
Чем своя CRM лучше Битрикс24 и amoCRM, и когда она хуже
Большинству компаний выгоднее коробка, и мы говорим это до того, как взять деньги. Вот тест, который показывает, на какой вы стороне.

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

Расскажите, что нужно сделать

Расчёт придёт за 12 часов: цена от и до, из чего она сложилась и что её двигает. Не хватит данных — вопросы придут в те же 12 часов.