• Согласуются каналы обращений: система заявок, электронная почта, чат, а также ответственные лица и порядок эскалации;
• Фиксируются контуры эксплуатации (тестовый и промышленный) и правила удалённого доступа в соответствии с регламентом заказчика;
• Определяются контрольные точки, за которыми ведётся наблюдение:
• Очередь сообщений;
• Статусы обработки сообщений;
• Преобразование форматов;
• Маршрутизация;
• Доступность целевых порталов;
• Авторизационные данные;
• Журналы и хранилище сообщений;
• Согласуются требования к логированию и хранению сообщений: какие данные сохраняются, как долго хранятся и в какие сроки должны быть доступны для диагностики.

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

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

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

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

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

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

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

• Проблема авторизации или сессии на портале;
• Изменения на стороне портала: форма, шаги, требования;
• Ошибка в данных заявления: поля, вложения;
• Временная недоступность портала;
• Некорректное сопоставление статуса или ответа с исходным сообщением.

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

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

Стоимость технической поддержки программы для ЭВМ «СУД-Шлюз» определяется индивидуально и зависит от числа подключённых целевых порталов, интенсивности отправки заявлений, требований к скорости реакции и уровню доступности, а также от объёма работ по анализу статусов и устранению ошибок, включая случаи, вызванные изменениями или временной недоступностью порталов.

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

Вариант 1. Абонентская модель 

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

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

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

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

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

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