Сложный калькулятор из форм Tilda
Дизайн Вёрстка Кастомизация JS
Как мы превратили форму Tilda в калькулятор стоимости IT-аутсорсинга для Selecty
21.09.2026
Как мы превратили форму Tilda в калькулятор стоимости IT-аутсорсинга для Selecty
На первый взгляд задача выглядела довольно просто: пользователь выбирает уровень специалиста, указывает количество сотрудников и срок работы — калькулятор показывает примерную стоимость.
Но когда такой калькулятор должен не просто красиво считать цифры на странице, а ещё корректно работать внутри Tilda, собирать данные из нескольких визуальных частей интерфейса и передавать всё это одной заявкой в CRM, начинается самое интересное.
Именно такую задачу мы решали для Selecty.
В результате обычная форма превратилась в небольшой веб-инструмент, который одновременно работает как калькулятор, интерфейс выбора услуги и полноценная форма захвата лида.
Что нужно было сделать
Пользователь должен был самостоятельно собрать конфигурацию команды для аутсорсинга:
- выбрать грейд специалиста;
- указать количество специалистов;
- выбрать период работы;
- сразу увидеть рассчитанную стоимость;
- оставить контактные данные;
- отправить вместе с заявкой все выбранные параметры.
То есть калькулятор должен был работать не только визуально.
Если человек выбрал Senior, 3 специалистов и определённый период, эта информация должна была попасть в CRM вместе с телефоном и другими данными формы.
А это уже сильно отличается от простого JavaScript-калькулятора, который меняет число в <div>.
Проблема 1. Визуально калькулятор состоял из нескольких форм
В Tilda удобно собирать интерфейс отдельными блоками.
Проблема появляется позже.
Для пользователя это может выглядеть как единый калькулятор:
Грейд → Количество → Период → Контакты → Отправить
Но технически внутри страницы эти элементы могут находиться в разных формах.
А Tilda воспринимает каждую форму отдельно.
Получается странная ситуация: визуально у нас один интерфейс, а внутри страницы — несколько независимых форм со своими полями и своей логикой отправки.
Для обычного лендинга это не проблема.
Для калькулятора — проблема.
Потому что в CRM должна уходить одна заявка, а не три отдельных набора данных.
Что мы сделали
Использовали объединение форм через:
forms.init("#rec2576428001")
После этого несколько визуально разделённых частей калькулятора стали работать как единая форма.
Пользователь этого вообще не замечает.
Для него интерфейс остаётся разбитым на понятные смысловые блоки, а для Tilda CRM это одна полноценная заявка.
Это хороший пример того, почему при разработке на Tilda не обязательно выбирать между удобством дизайна и корректной технической логикой.
Иногда можно оставить и то, и другое.
Проблема 2. Выбор грейда должен был влиять на расчёт
Следующий элемент — выбор уровня специалиста.
В калькуляторе использовались четыре грейда:
- Junior — 150 000 ₽;
- Middle — 250 000 ₽;
- Senior — 400 000 ₽;
- Lead — 600 000 ₽.
Но обычные кнопки здесь не подходили.
Нам нужно было, чтобы каждая кнопка одновременно:
- выглядела как часть интерфейса;
- имела активное состояние;
- записывала выбранный грейд;
- меняла базовую стоимость;
- запускала перерасчёт итоговой суммы;
- передавала значение в CRM.
Поэтому за интерфейсом выбора появилась отдельная логика.
В коде выбранный грейд хранится в переменной g.
Например:
g = senior
Одновременно калькулятор получает соответствующую стоимость специалиста.
При переключении на другой грейд значение меняется, активный класс переезжает на новую кнопку, а итоговая стоимость пересчитывается.
То есть кнопка здесь — уже не просто элемент дизайна.
Это полноценный контрол состояния калькулятора.
Проблема 3. Количество специалистов хотелось выбирать ползунком
Обычный <input type="number"> отлично работает.
И примерно настолько же отлично выглядит как форма из 2007 года.
Поэтому количество специалистов решили выбирать через кастомный range-слайдер.
Но здесь появилась дополнительная задача.
Ползунок должен быть связан с числовым значением.
Если пользователь двигает slider — меняется число.
Если каким-то способом меняется число — положение ползунка тоже должно соответствовать ему.
И всё это должно сразу влиять на стоимость.
Внутри калькулятора количество специалистов хранится в переменной:
q
Получается простая модель:
грейд × количество специалистов × период
Но интерфейс вокруг этой формулы уже значительно сложнее.
Каждое изменение q должно:
- обновить отображаемое количество;
- изменить положение slider;
- пересчитать стоимость;
- сохранить значение для последующей передачи в CRM.
Сам расчёт занимает несколько строк.
Большая часть работы — сделать так, чтобы все элементы интерфейса вокруг него постоянно оставались синхронизированными.
Проблема 4. Период работы — кастомные radio-кнопки
Для выбора периода использовались радиокнопки.
Технически можно было оставить стандартный HTML radio.
Но задача была частью кастомного дизайна Selecty, поэтому стандартные браузерные переключатели сюда не подходили.
Мы оставили механику radio, но полностью переоформили их внешний вид.
В итоге пользователь получает привычную логику:
выбрать можно только один вариант.
А визуально элементы выглядят как часть общего интерфейса калькулятора.
Выбранный период сохраняется в переменной:
p
После каждого изменения калькулятор снова пересчитывает стоимость.
Получилась довольно понятная структура состояния:
g — grade
q — quantity
p — period
Эти три параметра стали основой всего калькулятора.
Проблема 5. Красивое число и правильное число — не одно и то же
Допустим, калькулятор получил:
1500000
Для JavaScript это отличное число.
Для пользователя — не очень.
Гораздо понятнее:
1 500 000 руб.
Можно было сразу записывать отформатированное значение в поле.
Но дальше начинаются потенциальные проблемы.
CRM, аналитика или дополнительные скрипты обычно предпочитают получать чистые данные:
1500000
а не:
1 500 000 руб.
Поэтому мы разделили данные и отображение.
Внутри калькулятора
Хранится машинное значение:
1500000
На странице
Пользователь видит:
1 500 000 руб.
Это небольшая архитектурная деталь, но она делает калькулятор намного надёжнее.
Интерфейс можно форматировать как угодно, не ломая исходные данные.
Такой подход особенно полезен, если в будущем значение понадобится отправлять:
- в CRM;
- в webhook;
- в n8n;
- в аналитику;
- в рекламные системы;
- в собственный backend.
Проблема 6. Посчитать стоимость недостаточно — нужно отправить конфигурацию в CRM
Это одна из самых распространённых ошибок при создании калькуляторов.
На странице всё работает идеально.
Пользователь выбирает:
Senior / 4 специалиста / нужный период
видит стоимость и отправляет заявку.
Менеджер получает:
Имя: Александр
Телефон: +7…
И всё.
Какую конфигурацию выбрал клиент?
Неизвестно.
Можно позвонить и спросить ещё раз, но тогда половина пользы калькулятора исчезает.
Поэтому в заявку Selecty мы добавили передачу параметров:
g
q
p
Теперь CRM получает не только контакт пользователя, но и контекст его заявки.
Например:
Grade: Senior
Quantity: 4
Period: выбранный период
Менеджер открывает лид и сразу понимает, что именно рассчитывал потенциальный клиент.
Это делает калькулятор уже не просто маркетинговым элементом сайта.
Он становится частью процесса продаж.
А где сама формула?
Забавно, но математическая часть подобных калькуляторов обычно самая простая.
Условно она выглядит так:
Стоимость специалиста × количество специалистов × период
Самая большая работа начинается вокруг неё.
Нужно решить:
- где хранить состояние;
- как синхронизировать элементы;
- как объединить формы;
- как не потерять значения;
- как передать параметры в Tilda;
- как красиво показать результат;
- как сохранить машинное значение;
- как заставить всё это работать после загрузки страницы;
- как не сломать стандартную механику отправки формы.
Поэтому хороший калькулятор на сайте — это редко «написали формулу на JavaScript».
Формула может занимать 2% кода.
Остальные 98% отвечают за то, чтобы пользователь никогда не задумался о том, насколько всё сложно внутри.
Почему мы не стали делать калькулятор отдельным приложением
Можно было разработать калькулятор полностью отдельно: собственная форма, backend, API и отдельная отправка данных.
Для некоторых проектов это действительно правильный вариант.
Но здесь в этом не было необходимости.
Selecty уже использовал инфраструктуру Tilda.
Поэтому логичнее было сохранить:
- стандартную работу форм;
- существующую CRM;
- привычную админку;
- возможность редактировать страницу через Tilda;
- текущую структуру лендинга.
А кастомный JavaScript использовать только там, где возможностей конструктора становилось недостаточно.
Это вообще один из наших любимых подходов к Tilda.
Не бороться с платформой, а расширять её.
Если стандартная функция работает — используем стандартную функцию.
Если появляется ограничение — добавляем код только в нужном месте.
В результате сайт не превращается в приложение, которое страшно открыть без разработчика.
Что получилось в итоге
После доработки калькулятор умеет:
Объединять несколько визуальных форм в одну заявку.
Части интерфейса можно свободно располагать по странице, при этом CRM получает единую форму.
Работать с четырьмя уровнями специалистов.
Junior, Middle, Senior и Lead имеют собственную стоимость и активное состояние.
Считать количество специалистов через кастомный slider.
Ползунок синхронизирован с числовым значением и моментально запускает перерасчёт.
Работать с периодом через кастомные radio-кнопки.
Визуально они соответствуют дизайну сайта, но сохраняют правильную механику выбора.
Автоматически пересчитывать стоимость.
Любое изменение параметров сразу отражается в результате.
Разделять данные и отображение.
В логике хранится 1500000, пользователь видит 1 500 000 руб..
Передавать параметры калькулятора в CRM.
Менеджер получает не только контакт, но и выбранные g, q и p.
Почему такие калькуляторы работают лучше обычной формы
Стандартная форма говорит пользователю:
«Оставьте телефон, а потом мы расскажем цену».
Калькулятор работает наоборот:
«Выберите параметры, посмотрите ориентировочную стоимость, а если предложение подходит — оставьте контакты».
Человек получает пользу ещё до отправки формы.
Это особенно важно для сложных B2B-услуг, где нет одной фиксированной цены.
Калькулятор помогает превратить абстрактную услугу в набор понятных параметров.
Вместо:
«Аутсорсинг IT-специалистов»
пользователь начинает думать:
«Мне нужны два Senior-разработчика на такой-то период — сколько это будет стоить?»
А это уже значительно ближе к реальному запросу.
Главное, что мы вынесли из этой задачи
Сам калькулятор — это не число на экране.
Хороший калькулятор состоит сразу из нескольких уровней:
Интерфейс
Пользователь должен быстро понять, что выбирать.
Состояние
Все выбранные значения должны где-то храниться.
Расчёт
Из параметров должен получаться корректный результат.
Отображение
Результат должен быть понятным человеку.
Форма
Контактные данные и параметры конфигурации должны отправляться вместе.
CRM
Менеджер должен получить достаточно информации, чтобы продолжить разговор.
Если хотя бы один уровень потерять, калькулятор превращается либо в красивую игрушку, либо в неудобную форму.
В случае с Selecty мы постарались связать все эти части в одну систему.
И всё это продолжает жить внутри обычной страницы на Tilda.
Tilda можно значительно больше, чем кажется
У Tilda есть репутация конструктора для относительно простых лендингов.
Во многом заслуженная.
Но граница между «это невозможно сделать в Tilda» и «для этого понадобится немного JavaScript» проходит гораздо дальше, чем принято считать.
На стандартных блоках и Zero Block можно собирать интерфейс, а поверх него добавлять собственную логику:
- калькуляторы;
- квизы;
- динамические формы;
- кастомные фильтры;
- интерактивные карточки;
- сложные зависимости между полями;
- передачу дополнительных параметров в CRM;
- webhook-интеграции;
- анимации и микроинтеракции.
При этом клиент сохраняет главное преимущество конструктора — возможность самостоятельно работать с контентом.
И, пожалуй, именно в этом для нас заключается смысл кастомной разработки на Tilda:
не превращать конструктор в самописный сайт, а заставить конструктор делать немного больше, чем он умеет из коробки.
Приходите к нам за нестандартными решениями.
Смотрите также