Ателье: мерки и сроки в записной книжке стоят двух потерянных заказов в месяц

MAATRIX

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

Почему бумажная записная книжка ателье не работает

Тетрадь работает ровно до тех пор, пока в ателье один мастер, один клиент в день и никто никуда не спешит. Дальше начинаются проблемы, знакомые почти всем:

• Мерки живут отдельно от заказа. Записали снятие мерок на одной странице, а через неделю, когда клиент вернулся на примерку, тетрадь пролистывают в поисках нужной записи — иногда находят чужую.
• Нет истории. Мерки человека меняются: похудел, поправился, беременность, возраст. Если в тетради нет дат и предыдущих замеров, каждый повторный заказ снимается заново, будто клиента видят впервые. А в постоянном ателье повторные клиенты — это основная выручка, не разовые.
• Сроки существуют только в голове мастера. Пока мастеров двое, это ещё держится на памяти. Как только их трое и больше — обязательно найдётся заказ, про который вспомнили в день сдачи, а не за три дня, когда ещё можно было успеть.
• Тетрадь физически одна. Если она нужна одновременно администратору на ресепшене и мастеру в примерочной, кто-то ждёт или дублирует записи начерно, а потом переносит — с ошибками при переносе.
• Тетрадь можно потерять. Залить кофе, забыть в такси, отдать вместе со старой мебелью при переезде — и вместе с ней теряется вся история клиентов за годы работы.
• Мессенджер как замена тетради — не лучше. Часть ателье переходит на заметки в телефоне или чаты в WhatsApp с клиентами. Это решает проблему одной физической книжки, но не решает проблему поиска: попробуйте найти мерки конкретного клиента среди трёхсот переписок за два года.

Отдельная история — фотографии эскизов, образцов ткани, примеров моделей, которые клиент присылает или которые делает мастер на телефон. Они разбросаны по галереям разных сотрудников и не привязаны ни к клиенту, ни к заказу.

Что должна знать система учёта: карточка клиента и карточка заказа

Прежде чем разворачивать что-либо на сервере, стоит понять, какие данные вообще нужно хранить и как они связаны. В ателье это две сущности с историей.

Карточка клиента — создаётся один раз, живёт годами:

• имя, телефон, как удобнее связаться (звонок, WhatsApp, Telegram);
• история мерок с датами каждого снятия — не одна актуальная запись, а весь ряд по времени;
• особенности фигуры и пожелания, которые мастер отмечает при работе (одно плечо чуть ниже, не любит приталенное и т. п.);
• ссылка на все заказы этого клиента.

Карточка заказа — создаётся под каждое изделие:

• какой клиент, какой мастер ведёт заказ;
• что шьётся или ремонтируется, из какой ткани (свой материал клиента или закупка ателье);
• какая версия мерок использована (ссылка на конкретную запись из истории, а не «мерки вообще»);
• дата приёма, дата примерки, срок сдачи;
• статус: принят → в работе → на примерке → готов → выдан;
• стоимость и предоплата;
• фотографии — эскиз, ткань, готовое изделие.

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

Своя база на сервере вместо тетради и переписки

Для ателье не нужна тяжёлая ERP с внедрением на месяцы — это оверинжиниринг для мастерской на 2–10 человек. Практичный вариант — низкокодовая база данных с веб-интерфейсом, у которой уже есть готовые таблицы, связи между ними, форма для ввода с телефона или планшета в примерочной, и поле для вложений под фотографии. Это тот же принцип, что уже применяли в похожих нишах: оптика решает почти идентичную задачу с рецептами и заказами на очках, только вместо диоптрий — сантиметры.

Из готовых открытых инструментов для такой задачи хорошо подходит NocoDB — self-hosted аналог Airtable: таблицы, связи между ними (клиент → мерки → заказы), вложения, готовое REST API для автоматизаций и напоминаний, доступ с любого устройства через браузер без установки приложений на каждый телефон в мастерской. Ничего не мешает взять вместо него Baserow или связку PostgreSQL с самописной формой — принцип ниже одинаков, дальше просто пример на конкретном инструменте.

Почему свой сервер, а не облачный сервис с подпиской на пользователя:

• Не платите за каждого мастера отдельно. У облачных CRM для мастерских типична модель «столько-то за место», и при пяти-шести сотрудниках это ощутимая ежемесячная сумма. На своём сервере лицензия одна — на сам сервер, а число пользователей внутри NocoDB не тарифицируется.
• Данные клиентов не покидают вашу инфраструктуру. Телефоны, мерки, история заказов — это персональные данные, и чем меньше сервисов, через которые они проходят, тем меньше рисков и тем проще соблюдать требования по их хранению.
• Не зависите от политики чужого сервиса. Облачный SaaS может поднять цену, ограничить функциональность в бесплатном тарифе или вовсе закрыться — такие истории случались с нишевыми CRM для малого бизнеса. База на своём сервере остаётся вашей до тех пор, пока вы платите за аренду сервера, а не за подписку на конкретный продукт.

Разворачиваем NocoDB на VPS: пошагово

Ниже — рабочий минимальный набор: NocoDB плюс PostgreSQL в Docker Compose. Для мастерской на несколько сотен клиентов и десятки заказов в месяц ориентировочно достаточно скромной конфигурации — 2 vCPU и 4 ГБ RAM с запасом; точные цифры зависят от объёма фотографий и числа одновременных пользователей, поэтому если ателье крупное или фото много — берите конфигурацию с запасом по диску.

Устанавливаем Docker, если его ещё нет:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

Создаём рабочую директорию и файл окружения:

mkdir -p /opt/atele && cd /opt/atele
mkdir -p nocodb-data pg-data

docker-compose.yml:

version: "3.8"
services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: nocodb
      POSTGRES_USER: nocodb
      POSTGRES_PASSWORD: замените-на-свой-пароль
    volumes:
      - ./pg-data:/var/lib/postgresql/data

  nocodb:
    image: nocodb/nocodb:latest
    restart: unless-stopped
    depends_on:
      - postgres
    environment:
      NC_DB: "pg://postgres:5432?u=nocodb&p=замените-на-свой-пароль&d=nocodb"
      NC_AUTH_JWT_SECRET: "замените-на-случайную-строку"
    ports:
      - "8080:8080"
    volumes:
      - ./nocodb-data:/usr/app/data

Запускаем:

docker compose up -d

Дальше стоит поставить nginx как обратный прокси с бесплатным сертификатом Let's Encrypt, чтобы открывать базу по своему домену (atele.вашдомен.ru) с HTTPS, а не по IP и открытому порту 8080. Минимальный конфиг nginx:

server {
    listen 443 ssl;
    server_name atele.вашдомен.ru;

    ssl_certificate /etc/letsencrypt/live/atele.вашдомен.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/atele.вашдомен.ru/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

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

Схема таблиц: клиенты, мерки, заказы, статусы

В NocoDB создаётся база (workspace) с четырьмя связанными таблицами.

Клиенты: имя, телефон, канал связи, комментарий по особенностям фигуры, поле-ссылка на связанные записи из таблицы «Мерки» и таблицы «Заказы» (создаётся автоматически при связывании таблиц).

Мерки — отдельная таблица, а не поля внутри карточки клиента, именно чтобы хранить историю:

Заказы:

Сотрудники: мастера ателье, чтобы видеть загрузку каждого и кто отвечает за конкретный заказ.

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

Напоминания о сроках и повторные заказы

Сама база уже убирает путаницу мерок, но вторую часть проблемы — забытые сроки — решает только автоматическое напоминание, а не то, что кто-то вспомнит открыть таблицу. У NocoDB есть встроенные автоматизации (webhook при смене статуса, уведомления по расписанию), но для ателье часто достаточно простого крон-скрипта на самом сервере, который раз в день проверяет ближайшие сроки и шлёт сообщение в Telegram-группу мастерской через бота.

Пример скрипта /opt/atele/check-deadlines.sh:

#!/bin/bash
# Проверка заказов, которые нужно сдать через 2 дня, и рассылка в Telegram

NC_TOKEN="ваш-xc-auth-токен-из-NocoDB"
NC_BASE="https://atele.вашдомен.ru/api/v1/db/data/v1/atele-db/Заказы"
TG_BOT_TOKEN="123456789:ваш-токен-бота"
TG_CHAT_ID="-100XXXXXXXXXX"

TARGET_DATE=$(date -d "+2 days" +%F)

curl -s -H "xc-auth: $NC_TOKEN" \
  "$NC_BASE?where=(СрокСдачи,eq,$TARGET_DATE)~and(Статус,neq,выдан)" \
| jq -r '.list[] | "\(.Клиент) — \(.Изделие), срок \(.СрокСдачи), мастер \(.Мастер)"' \
| while IFS= read -r line; do
    curl -s -X POST "https://api.telegram.org/bot${TG_BOT_TOKEN}/sendMessage" \
      -d chat_id="${TG_CHAT_ID}" \
      -d text="Через 2 дня срок сдачи: ${line}"
  done

Права на выполнение и задание в cron:

chmod +x /opt/atele/check-deadlines.sh
crontab -e

0 9 * * * /opt/atele/check-deadlines.sh

Токен xc-auth берётся в настройках профиля NocoDB, чат-бот создаётся через @BotFather за пару минут — стандартная процедура, если у ателье уже есть рабочая Telegram-группа для мастеров, что почти всегда так и есть. Тот же принцип напоминаний — не полагаться на память, а спрашивать систему — уже применялся для похожей задачи с записью и уведомлениями: автосервис решал ту же проблему пропущенных сроков через собственные напоминания.

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

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