Оптика: рецепты, подбор оправ и заказы в лабораторию в одной своей системе

MAATRIX

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

Что теряется, когда рецепт, оправа и заказ живут порознь

Разрозненность в оптике не бросается в глаза, пока не случается ошибка — а она случается регулярно, просто по мелочи, которую списывают на человеческий фактор.

• Рецепт переписывается вручную минимум дважды: врач-офтальмолог или оптометрист вписывает его в карточку или бланк, а потом кто-то из персонала перепечатывает данные для заказа в лабораторию. Каждая перепечатка — шанс перепутать OD и OS, сдвинуть цилиндр или ось.
• История подбора оправ не сохраняется системно. Клиент примерил пять моделей, выбрал шестую через месяц по фото на телефоне — а в следующий раз консультант снова начинает с нуля, потому что предыдущий визит нигде не зафиксирован.
• Статус заказа в лаборатории известен только по звонку. «Скажите, мои линзы готовы?» — обычный вопрос, на который в бумажной модели можно ответить только после того, как кто-то дозвонился в лабораторию или посмотрел журнал.
• Срок действия рецепта не отслеживается. Оптометрический рецепт обычно действителен ограниченное время, но без единой базы никто не напомнит клиенту, что пора на повторную проверку зрения, — это упущенный визит, а не забота о клиенте.
• Данные о зрении клиента расходятся по бумажным носителям и личным устройствам сотрудников, что плохо и с точки зрения конфиденциальности, и с точки зрения преемственности: увольняется консультант — уходит часть истории клиентов.

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

Что даёт единая система на своём сервере

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

Технически это не требует сложной инфраструктуры. На арендованном VPS или выделенном сервере разворачивается:

• база данных (PostgreSQL или MySQL) с таблицами клиентов, рецептов, примерок оправ и заказов в лабораторию;
• веб-приложение поверх неё — либо кастомная разработка под конкретный салон, либо адаптированная под оптику связка из open-source инструментов (например, NocoDB или Baserow как визуальный слой над базой, плюс отдельная форма для генерации бланка заказа);
• хранилище фотографий (клиент в примеряемых оправах, снимки для подбора формы лица) — папка на том же сервере или отдельный контейнер с объектным хранилищем;
• регулярный бэкап базы и файлов на другой сервер или в другой регион.

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

Карточка рецепта: что должно в ней быть

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

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

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

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

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

Что стоит фиксировать в карточке клиента при каждой примерке:

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

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

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

Заказ в лабораторию: от рецепта до статуса «готово»

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

В единой системе заказ формируется из уже введённого рецепта одним действием:

1. Оператор открывает карточку клиента с действующим рецептом.
2. Выбирает оправу (из каталога, с привязкой к модели, которую клиент примерил и купил) и параметры линз — тип, покрытие, материал.
3. Система генерирует бланк заказа с уже подставленными значениями рецепта — без ручного переноса цифр.
4. Заказ получает статус: *оформлен → передан в лабораторию → в работе → готов → выдан клиенту*.
5. Каждая смена статуса фиксируется с датой — видно, сколько реально занимает цикл, и на каком этапе застревают заказы, если это происходит регулярно.

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

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

Права доступа и напоминания клиентам

У системы, объединяющей рецепты, примерки и заказы, должна быть внутренняя логика доступа — не потому что это модно, а потому что в салоне разные роли реально нуждаются в разных данных:

• консультант в зале видит карточку клиента, историю примерок, оформляет заказ — но обычно не должен редактировать сам рецепт;
• оптометрист или врач — единственный, кто вносит и правит значения рецепта;
• администратор/владелец видит статистику по заказам, срокам изготовления, повторным визитам.

Реализуется это через обычную ролевую модель на уровне приложения (или прав в базе данных), а не через honor system «мы верим, что никто не полезет не в свою карточку». Дополнительно стоит закрыть доступ к серверу через VPN или хотя бы ограничить его по IP — рецепты и данные о зрении клиентов относятся к чувствительной персональной информации, и лишний открытый порт наружу — ненужный риск.

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

Что нужно физически, и сколько это реально стоит

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

Ориентировочно (именно ориентировочно — точная конфигурация зависит от числа сотрудников, объёма фотоархива и того, разворачиваете ли вы готовое open-source решение или кастомную разработку):

• 2 vCPU, 4 ГБ RAM — достаточный старт для одной-двух точек с несколькими одновременными пользователями;
• 40–80 ГБ диска — с запасом под фотоархив примерок, который растёт медленнее, чем кажется, если хранить фото в разумном сжатии;
• регулярный автоматический бэкап базы и файлов на отдельный сервер или в другой регион — рецепты и история клиентов не тот случай, где можно полагаться на «сервер ещё ни разу не падал».

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

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

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