Регламент Мастерской Смальта® | Код: SMALTA-REGULATIONS | редакция от 06.09.2026 14:37
Настоящий Регламент определяет единую модель работы Мастерской Смальта® с клиентами: от первого обращения и онбординга до исполнения, приёмки, расчётов, юридически значимых документов и сопровождения. Опубликованная редакция этой страницы является первоисточником правил Мастерской.
1.1. Первоисточник: действующая редакция Регламента публикуется по адресу https://smalta.net/kontur/regulations/. Владелец читает и изменяет Регламент на этой странице.
1.2. Обязательность: личный кабинет, CRM, каталог услуг, формы, коммерческие документы и рабочие процедуры Мастерской приводятся в соответствие с опубликованной редакцией.
1.3. Один факт — один источник: другие системы не создают параллельные правила, а хранят операционные факты либо показывают утверждённую проекцию.
1.4. Область: Регламент охватывает работу с клиентом, CRM, услуги, проекты, коммуникации, коммерцию, юридический контур, документооборот и сопровождение.
1.5. Внутренние технические процедуры, служебные роли, журналы и инструкции сотрудников не являются частью публичного Регламента и клиенту не раскрываются.
2.1. Клиент взаимодействует с одной организацией — Мастерской Смальта®.
2.2. Информационный раздел отвечает за знакомство, онбординг, карточку клиента, постановку потребности, коммуникацию, содержание, документы, счета, статусы и приёмку.
2.3. Технический раздел отвечает за диагностику, оценку, план, разработку, дизайн, серверную часть, тестирование, релиз, мониторинг и сопровождение.
2.4. Разделы не подменяют друг друга: Информационный раздел не объявляет техническую готовность без подтверждённого результата; Технический раздел не изменяет коммерческие и юридические факты.
2.5. Перед клиентом за результат отвечает Мастерская Смальта® как единый исполнитель.
3.1. Владелец Мастерской утверждает правила, структуру, услуги, цены и окончательные управленческие решения.
3.2. Проект-менеджер ведёт клиента и проект, поддерживает актуальность CRM, организует коммуникацию, сроки, следующий шаг и приёмку.
3.3. Тимлид определяет техническое решение, декомпозирует работу, координирует сотрудников и принимает их результат до передачи проект-менеджеру.
3.4. Сотрудники — программисты, дизайнеры и другие исполнители — выполняют измеримые задачи в своей профессиональной области.
3.5. Клиент определяет желаемый результат, предоставляет данные и доступы, согласует условия и принимает результат. Контакт клиента действует только в пределах подтверждённых полномочий.
3.6. Партнёр ведёт только своих клиентов и разрешённую коммуникацию, не принимает платежи клиента и не вмешивается в техническое исполнение без отдельного полномочия.
4.1. Публичные правила, услуги, цены, термины и юридические тексты определяются утверждёнными страницами раздела smalta.net/kontur/.
4.2. Панель упраления lk.smalta.net (далее - CRM) хранит операционные факты конкретного клиента: контакты, проекты, этапы, задачи, сроки, обращения, коммуникации и выставленные документы.
4.3. Первичный факт движения денег находится в банке, эквайринге или утверждённой учётной системе. CRM отражает оплату только после такого подтверждения.
4.4. Подписанные договоры, акты, УПД, претензии и иные юридически значимые оригиналы хранятся в Диадоке либо другом утверждённом канале ЭДО. CRM хранит номер, дату, статус и ссылку.
4.5. Техническое состояние инфраструктуры подтверждается средствами Технического раздела. В CRM передаётся краткий проверенный клиентский факт, а не серверный журнал.
4.6. Пароли, токены и ключи хранятся только в защищённом хранилище. В CRM допускается лишь отметка о наличии, владельце и сроке действия доступа.
5.1. Клиента создаёт Партнёр или Проект-менеджер, через обращение (лид). Домен, сайт, сервер или найденный технический узел не создают клиентскую карточку автоматически.
5.2. До создания проверяется отсутствие дубля. Клиент соответствует одному человеку либо одной организации, с которой существуют клиентские отношения.
5.3. У клиента должен быть хотя бы один подтверждённый Контакт с индивидуальным доступом и понятными полномочиями.
5.4. Фиксируются действующие версии обязательных согласий и основание отношений.
5.5. Создаётся либо выбирается Проект с понятным клиенту назначением, ответственным проект-менеджером, первым этапом и ближайшей задачей.
5.6. Контакт проверяет вход в кабинет и видит только собственные данные, проекты, документы и обращения.
5.7. Онбординг имеет статус COMPLETE только после проверки кабинета и видимости первой работы; PARTIAL содержит один конкретный незавершённый шаг; отсутствие обязательной карточки, доступа или изоляции означает FAILED.
6.1. Единый цикл: Обращение → Квалификация → Оценка → Согласование → Исполнение → Приёмка → Расчёт → Архив или Сопровождение.
6.2. Обращение фиксируется в CRM как лид, тикет, задача, смета, предложение или запись звонка. Экстренный канал после стабилизации обязательно получает запись в тикете.
6.3. Информационный раздел определяет клиента, проект, приоритет S0–S3, желаемый результат и полноту данных.
6.4. Технический раздел определяет границу, риск, срок и состав. Работа вне действующего сопровождения получает смету или коммерческое предложение.
6.5. До старта клиент подтверждает объём, цену и условия; основанием платной работы является оплата, договор либо разрешённая отсрочка.
6.6. Исполнение существует как задача проекта. Статус CRM обновляется после факта, а не вместо него.
6.7. Клиент видит результат и замечания. Только подтверждённый результат получает статус «готово».
6.8. Разовый проект закрывается; дальнейшая поддержка ведётся отдельным активным проектом сопровождения.
7.1. Клиент — человек или организация с клиентскими отношениями; Контакт — уполномоченный пользователь; Проект — один результат либо длительный контур сопровождения.
7.2. Стадия (веха) — видимый клиенту рубеж с результатом и сроком; Задача — одна измеримая работа с ответственным и критерием готовности.
7.3. Тикет — входящий вопрос, запрос поддержки или инцидент. Принятая в работу потребность связывается с задачей и не дублируется молча.
7.4. Позиция каталога — утверждённая услуга со стабильным кодом, результатом, единицей и моделью цены.
7.5. Предложение — коммерческое предложение; Смета — согласуемый состав и цена; Договор — договор или дополнительное соглашение.
7.6. Счёт — требование оплаты; Платёж — подтверждённое получение денег; Корректировочный документ — подтверждённая корректировка или возврат; Расход — подтверждённый расход Мастерской.
7.7. Одна сущность не используется вместо другой: претензия не является Предложением, регламент не является Договором, а Смета не подтверждает оплату.
8.1. Проект использует статусы: Не начат, В работе, Пауза, Отменён, Готов. Текстовые псевдостатусы не создаются.
8.2. Проект «В работе» имеет активный этап и ближайшую задачу. «Пауза» содержит причину, ожидаемое действие и дату пересмотра. «Готов» не имеет активной работы и незакрытого хвоста без явной связи.
8.3. Прогресс проекта рассчитывается по задачам. Ручной процент, противоречащий задачам и статусу, не применяется.
8.4. Задача проходит смысловые состояния: ожидает → в работе → проверка или ожидание клиента → готово.
8.5. Приоритеты: S0 — авария или угроза данным; S1 — значимый сбой; S2 — частичное нарушение; S3 — консультация, улучшение или плановая работа.
8.6. Для S0 допускается немедленная стабилизация. Тикет, основание, результат и коммерческий режим фиксируются после снятия аварии.
9.1. Главный экран кабинета отвечает: что обслуживается; что происходит сейчас; какой следующий результат и срок; что требуется от клиента; какие документы и расчёты актуальны.
9.2. Клиент видит свои контакты, проекты, клиентские этапы и задачи, тикеты, предложения, сметы, договоры, счета, оплаты, корректировки и актуальные правила.
9.3. Клиент не видит чужие данные, внутренние задачи, служебные споры, технические журналы, секреты и процедуры без клиентского смысла.
9.4. Основные каналы — личный кабинет, тикеты и электронная почта. Телефон и мессенджеры используются для срочной связи с последующей фиксацией результата в CRM.
9.5. Активная карточка всегда содержит ответственного, ближайший результат и следующий шаг.
10.1. Предложение содержит решение и условия; Смета фиксирует согласуемый состав и цену; Договор закрепляет договорные условия, если публичной оферты недостаточно.
10.2. Счёт выставляется только за согласованный предмет и связывается с клиентом и основанием.
10.3. Платёж создаётся в CRM только после подтверждения банка, эквайринга или учётной системы и хранит безопасный идентификатор этого факта.
10.4. Корректировочный документ оформляет корректировку или возврат без удаления исходной истории.
10.5. Акт или УПД подтверждает юридическую сдачу через ЭДО. Счёт, оплата и закрывающий документ не подменяют приёмку результата.
10.6. Партнёрское вознаграждение возникает после подтверждённой оплаты и сдачи работ, рассчитывается из фактически полученной суммы за вычетом возвратов и скидок.
11.1. Юридический комплект включает публичную оферту, пользовательское соглашение, политику конфиденциальности, согласие на обработку персональных данных, политику cookie, настоящий Регламент, партнёрское соглашение и правила ЭДО.
11.2. Каждый документ имеет устойчивый код, номер или дату редакции, дату вступления в силу и постоянный публичный URL.
11.3. Событие согласия связывается с клиентом, контактом и точной редакцией документа и содержит дату, время, действие, канал и допустимые технические метаданные.
11.4. Согласие не хранится как свободная заметка. Отзыв либо согласие с новой редакцией создаёт новое событие; предыдущее событие не редактируется задним числом.
11.5. Сайт передаёт событие согласия в операционный журнал. Формы и CRM не могут ссылаться на неопределённую или устаревшую редакцию документа.
11.6. Подписанный оригинал хранится в утверждённом ЭДО. Текст в CRM является отображением версии, но не отдельным редактируемым источником.
12.1. Перед изменением создаётся подходящая точка отката либо фиксируется подтверждённое отсутствие технической возможности её создать.
12.2. Доступы выдаются по принципу минимальных привилегий, передаются защищённым каналом и отзываются либо пересматриваются после завершения работ.
12.3. Работа проходит диагностику, подготовку, исполнение, тестирование, приёмку и релиз. Критерий готовности определяется до исполнения.
12.4. Готовность подтверждается проверкой результата. Сам факт выполнения команды, изменения файла или ответа сотрудника готовностью не является.
12.5. Технические журналы и секреты остаются во внутренних системах; клиент получает понятный результат, ограничения и рекомендации.
12.6. Уровни сервиса, сроки реакции и состав сопровождения определяются выбранной услугой, сметой, договором или подпиской. Обещания, не закреплённые в этих основаниях, SLA не образуют.
13.1. Запрещено хранить секреты в карточках клиентов, проектах, задачах, договорах, предложениях, заметках и базе знаний.
13.2. Запрещены межклиентская видимость, общие логины контактов и автоматическое создание клиента по домену или серверу.
13.3. История не исправляется массовым удалением. Ошибочные связи корректируются после проверки владельца факта и подготовки отката.
13.4. CRM не обгоняет реальность: сначала подтверждается факт, затем меняются статус, расчёт и документ.
13.5. Публичные цены, термины и юридические тексты не ведутся параллельно в CRM. CRM получает их утверждённую версию с сайта.
13.6. Изменение внутреннего процесса не может ухудшить согласованные права клиента, безопасность данных и доступность истории.
14.1. Овнер Мастерской вправе изменять Регламент. Новая редакция публикуется на /kontur/regulations/ и получает дату изменения.
14.2. После публикации личный кабинет, CRM, формы, каталог, связанные документы и внутренние процедуры проверяются на соответствие новой редакции.
14.3. При расхождении текста сайта с локальной копией, инструкцией, CRM или автоматизацией действует опубликованная редакция сайта, если обязательный закон или подписанный договор не устанавливает иное.
14.4. Регламент считается целостным, когда по любой активной карточке за одну минуту можно определить клиента и его полномочия, активный проект, следующий результат и срок, требуемое действие клиента, принятые и оплаченные результаты, действующие документы и ответственных со стороны Мастерской.
14.5. Если для ответа требуется память сотрудника, поиск по чатам или чтение несвязанных свободных описаний, механизм Мастерской требует исправления.