Типография: онлайн-калькулятор тиража, который считает по вашим ценам, а не по чужому шаблону

MAATRIX

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

Как тираж на сайте обычно считают — и где начинаются проблемы

Типовой путь: типография делает сайт на конструкторе, добавляет туда виджет-калькулятор из магазина приложений или встроенного набора блоков. Такой виджет обычно умеет одно — взять несколько параметров (тираж, формат, иногда тип бумаги) и перемножить их на коэффициенты по формуле, которую придумали разработчики виджета для усреднённого бизнеса. Он не проектировался под полиграфию конкретно, и уж тем более не под вашу конкретную линейку станков и закупочные цены на бумагу.

На практике это выглядит так: в калькуляторе можно задать 3-4 параметра максимум, потому что интерфейс конструктора не резиновый и виджет должен работать «из коробки» у тысяч разных клиентов сразу. Форматы бумаги, виды печати (цифровая, офсетная, широкоформатная), плотность, ламинация, послепечатная обработка (биговка, высечка, скругление углов) — реальный прайс типографии живёт в матрице из десятков параметров, а виджет предлагает три выпадающих списка и поле «количество».

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

Почему логика конструктора не совпадает с вашей себестоимостью

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

Несколько вещей, которые типовой виджет просто не умеет:

• Нелинейные скидки за объём. У типографии обычно не «скидка 10% при заказе от 1000 шт», а несколько порогов с разным шагом: до 500 шт цена за штуку одна, 500-2000 — другая, от 2000 — третья, и внутри каждого диапазона своя логика округления печатных листов. Виджет с одним полем «скидка в процентах» такое не выразит.
• Себестоимость складывается из разных компонентов с разной динамикой. Стоимость бумаги меняется у поставщика, стоимость краски и амортизация печатной машины считаются иначе, ручная постпечатная обработка тарифицируется по времени, а не по листам. У конструктора все эти компоненты обычно можно свести только к одному общему коэффициенту.
• Загрузка печатного листа. Реальная типография считает, сколько экземпляров помещается на один печатный лист определённого формата, и цена скачком меняется на границах раскладки — это НЕ линейная зависимость от тиража, а конструктору важно, чтобы формула была простой и предсказуемой для всех клиентов сразу.
• Срочность заказа. Наценка за срочное исполнение обычно не фиксированный процент, а зависит от текущей загрузки цеха — то есть по-хорошему тарифицируется динамически, а не статичной формулой в виджете.
• Комбинации параметров, которые физически невозможны или требуют другого оборудования (например, определённая плотность бумаги плюс определённая биговка требуют предварительного тестового прогона) — это бизнес-правило, которое конструктору попросту негде хранить.

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

Что вы теряете, когда калькулятор не умеет считать по-вашему

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

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

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

Как устроен калькулятор, который считает по вашим правилам

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

Практическая схема выглядит так:

1. Таблицы цен и правил в базе данных, а не в коде виджета. Материалы, форматы, виды печати, пороги скидок, наценки за срочность — всё это строки в таблицах, которые можно менять через админку без разработчика, когда меняется закупочная цена бумаги или появляется новая услуга.
2. Backend, который считает по этим таблицам, а не по зашитой в JS-виджет формуле. Расчёт идёт на сервере — это важно, потому что клиент не должен иметь возможность подменить итоговую цену в браузере, а логика (в том числе коммерческая: как именно вы считаете скидки) не палится в исходном коде страницы.
3. API-эндпоинт, который фронтенд калькулятора дёргает при каждом изменении параметров и получает актуальную цену.
4. Админка для менеджера или технолога — форма редактирования прайса без обращения к разработчику каждый раз, когда меняется цена на картон или добавляется новый вид ламинации.

Упрощённый пример схемы таблиц в PostgreSQL:

CREATE TABLE print_methods (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,      -- 'цифровая', 'офсет', 'широкоформатная'
    base_cost_per_sheet NUMERIC(10,2) NOT NULL,
    setup_cost NUMERIC(10,2) NOT NULL DEFAULT 0  -- стоимость приладки
);

CREATE TABLE paper_types (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,      -- 'мелованная 300г', 'офсет 80г'
    cost_per_sheet NUMERIC(10,2) NOT NULL,
    sheet_format VARCHAR(20) NOT NULL -- 'A4', 'SRA3'
);

CREATE TABLE quantity_tiers (
    id SERIAL PRIMARY KEY,
    print_method_id INT REFERENCES print_methods(id),
    min_qty INT NOT NULL,
    max_qty INT,                     -- NULL = без верхней границы
    price_per_unit NUMERIC(10,4) NOT NULL,
    urgency_markup_percent NUMERIC(5,2) NOT NULL DEFAULT 0
);

И пример логики расчёта на бэкенде (упрощённо, без учёта раскладки на лист — в реальном проекте эта часть отдельная и самая нетривиальная):

async function calculatePrice({ printMethodId, paperTypeId, quantity }) {
  const tier = await db.query(
    `SELECT price_per_unit, urgency_markup_percent FROM quantity_tiers
     WHERE print_method_id = $1 AND min_qty <= $2
       AND (max_qty IS NULL OR max_qty >= $2)
     ORDER BY min_qty DESC LIMIT 1`,
    [printMethodId, quantity]
  );

  const method = await db.query(
    `SELECT base_cost_per_sheet, setup_cost FROM print_methods WHERE id = $1`,
    [printMethodId]
  );
  const paper = await db.query(
    `SELECT cost_per_sheet FROM paper_types WHERE id = $1`,
    [paperTypeId]
  );

  const sheetsNeeded = calcSheetLayout(quantity, paperTypeId); // ваша функция раскладки листа
  const costBase =
    sheetsNeeded * (method.rows[0].base_cost_per_sheet + paper.rows[0].cost_per_sheet) +
    method.rows[0].setup_cost;
  const withUrgency = costBase * (1 + tier.rows[0].urgency_markup_percent / 100);
  const unitPrice = tier.rows[0].price_per_unit * quantity;

  // не продаём ниже фактической себестоимости на нестандартных комбинациях
  return Math.max(unitPrice, withUrgency);
}

Это упрощение — в реальном проекте расчёт раскладки листа (calcSheetLayout) обычно самая сложная часть и требует отдельного продумывания под конкретное оборудование цеха. Смысл примера в другом: вся коммерческая логика — ваша, она читается, версионируется в git и меняется без ожидания, пока разработчик виджета добавит нужную функцию в следующем релизе.

Практика: от заявки клиента до готового расчёта

Минимальный рабочий стек для такого калькулятора не требует ничего экзотического:

Пример nginx-конфига, который отдаёт статику сайта и проксирует API калькулятора на отдельный backend-процесс:

server {
    listen 443 ssl http2;
    server_name printshop.example.ru;

    ssl_certificate     /etc/letsencrypt/live/printshop.example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/printshop.example.ru/privkey.pem;

    root /var/www/printshop/public;
    index index.html;

    location /api/calc/ {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 10s;
    }

    # админку прайса стоит закрыть отдельно — базовой авторизацией
    # или ограничением по IP в отдельном location /admin/

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Отдельный момент — если у типографии уже есть учётная система (1С или собственная база заказов), калькулятор на сервере может дёргать её через внутренний API, а не дублировать прайс в двух местах вручную. Это отдельная задача интеграции, но именно она чаще всего и оправдывает переход со связки «конструктор + виджет» на полноценный backend: при изменении цены в одном месте (учётной системе) калькулятор на сайте обновляется автоматически, без ручной синхронизации.

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

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

Несколько практических вещей, о которые обычно спотыкаются при переходе с виджета конструктора на свой калькулятор.

Нагрузка и отклик. Расчёт должен происходить почти мгновенно — клиент двигает ползунок тиража или меняет бумагу и сразу видит новую цифру. Если база не проиндексирована по нужным полям (print_method_id, диапазоны min_qty/max_qty), задержка становится заметной. Для такой матрицы цен обычной VPS с SSD и правильными индексами достаточно — специальной мощности не требуется, важнее аккуратный код запросов.

Защита от подмены цены на клиенте. Расчёт на сервере, а не в браузере — уже защита от правки цены в devtools перед отправкой заявки. Но проверяйте на бэкенде и границы значений (нельзя отправить тираж «-500» или несуществующий paper_type_id), иначе через API можно получить некорректный расчёт.

Резервные копии прайса. Таблицы с ценами — это коммерческая логика бизнеса, терять их из-за сбоя так же неприятно, как терять базу заказов. Регулярный pg_dump по расписанию плюс копия на отдельное хранилище закрывают этот риск недорого.

История изменений цен. Полезно вести таблицу-лог: кто и когда менял прайс. Если клиент присылает скриншот «вчера было дешевле», у вас есть точный ответ, а не «наверное, обновили прайс».

Интеграция с формой заявки. Калькулятор — не конечная точка, а начало сделки. После расчёта клиент должен уметь сразу отправить заявку с этими параметрами менеджеру — на почту, в Telegram-бот или в CRM, а не пересчитывать всё заново по телефону.

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

Частые вопросы