• согласуем каналы обращений (система заявок/email/чат), ответственных и порядок эскалации;
• фиксируем контуры (тест/пром) и правила удалённого доступа (по регламенту заказчика);
• определяем “контрольные точки”, которые держим под наблюдением:
• очередь сообщений, статусы обработки сообщений, преобразование форматов, маршрутизация, доступность целевых порталов, авторизационные данные, журналы и хранилище сообщений;
• согласуем требования к логированию и хранению сообщений (что сохраняем, как долго, как быстро извлекаем для диагностики).

Очередь отправки заявлений и стабильность обработки

• контроль заполнения и обработки очереди: чтобы заявки не “зависали” и не накапливались;
• настройка правил повторной обработки (повторы, таймауты, порядок обработки);
• разбор ситуаций “заявление ушло, но ответа нет” / “очередь не уменьшается” / “есть ошибки на конкретных пакетах”.

• диагностика ошибок, связанных с преобразованием сообщения ИИС в формат целевого портала (поля, вложения, структуру пакета);
• настройка/уточнение правил формирования “портального” запроса (в пределах возможностей шлюза и регламентов);
• корректировка обработки ответов и статусов, чтобы ИИС получала понятный результат.

• поддержка клиентских учётных данных для порталов (проверка актуальности, сроков действия, прав доступа);
• сопровождение обновления авторизационных данных (когда порталы меняют механику входа, сбрасывают сессии, требуют повторной авторизации);
• разбор случаев, когда портал требует “первичной авторизации” или дополнительного подтверждения.

• настройка и контроль получения статусов по отправленным заявлениям (в том числе промежуточных);
• обработка “несоответствий”: статус пришёл, но не сопоставился с заявлением; ответ пришёл, но не прикрепился к нужной записи;
• предотвращение дублей: когда повторная отправка создаёт второй пакет на портале.

• настройка хранения сообщений/ответов по регламенту заказчика;
• поиск и выгрузка “следов” по конкретному заявлению: входное сообщение ИИС → преобразование → отправка → ответ → выдача в ИИС;
• настройка очистки хранилища, чтобы оно не переполнялось и при этом сохранялась диагностическая информация.

• расширение статусов и “человеко-понятных” причин ошибок для операторов;
• дополнительные проверки заполнения полей заявлений до отправки (чтобы меньше было отказов на портале);
• доработка интеграции “ИИС ↔ СУД-Шлюз” (формат, структура, метаданные, связывание статусов).

• проблема авторизации/сессии на портале;
• изменения на стороне портала (форма, шаги, требования);
• ошибка в данных заявления (поля/вложения);
• временная недоступность портала;
• некорректная сопоставимость статуса/ответа с исходным сообщением.

• заявления попадают в очередь, но “не уходят” на портал — проверяем обработчик, доступность портала, авторизацию и ошибки преобразования;
• портал меняет механику входа/сбрасывает сессии — актуализируем авторизационные данные через плагин, проверяем права доступа аккаунта;
• заявление отправлено, но статусы не обновляются — проверяем сценарий получения статусов и сопоставление с заявлением;
• повторная отправка создаёт дубли на портале — настраиваем правила повторов и дедупликации;
• портал возвращает отказ из-за данных/вложений — помогаем выявить поле/причину и выстроить пред-проверки в ИИС/шлюзе;
• нужно “вытащить историю” по конкретному заявлению — находим цепочку сообщений в хранилище и выдаём техническое заключение.

• ИТ-контакт (контуры, доступы, сетевые ограничения, взаимодействие по порталам);
• контакт по процессу (какие статусы и результаты нужны в ИИС, правила повторов/исключений);
• действующие учётные данные целевых порталов и регламент их использования;
• доступ к журналам/логам и идентификаторы сообщений/заявлений при обращении;
• согласованный порядок актуализации авторизации.

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

Вариант 1. Абонентская модель (резерв ресурсов и SLA)
Применяется при необходимости гарантированной доступности специалистов и соблюдения согласованных параметров SLA.
В рамках абонентской платы предусматривается резервирование ресурсов на поддержку, регламент реакции и восстановления, а также сопровождение в пределах согласованного объёма работ. 

Вариант 2. Оплата по фактически затраченному времени (по заявкам)
Применяется при неравномерном объёме обращений либо при необходимости привлечения поддержки по мере возникновения задач.
Оплата производится исходя из фактически затраченного времени по зарегистрированным заявкам. Размер почасовых ставок определяется в соответствии с разделом «Цены». В случае повышенных требований к скорости реакции и приоритетам инцидентов применяются согласованные в договоре коэффициенты или отдельные тарифы.

Вариант 3. Транзакционная модель (за отправленные заявления)
Применяется при необходимости прозрачного расчёта, привязанного к фактическому объёму отправок.
В рамках данной модели может устанавливаться тариф за отправку одного заявления (например, 30 рублей за одно отправленное заявление), при этом получение и обработка статусов и ответов могут учитываться отдельно либо включаться в тариф — в соответствии с условиями договора.
Итоговая стоимость по транзакционной модели зависит от согласованного объёма отправок, числа подключённых порталов и требований к доступности и обработке очереди.

Стоимость поддержки СУД-Шлюза начинается от 200 000 (Двести тысяч) рублей в год.

Итоговая стоимость определяется после согласования перечня порталов, требований к SLA и выбранной модели расчёта и фиксируется в договоре. 

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