Документация TIQQET

Установка

TIQQET разворачивается через Docker Compose. Одна команда — и система готова к работе на любом сервере с Docker. Обзор всех возможностей — на странице демонстрации продукта.

Системные требования

• Docker 20.10+ и Docker Compose v2
• Минимум: 2 vCPU / 4 GB RAM / 20 GB SSD
• Рекомендуемо: 4+ vCPU / 8+ GB RAM / NVMe SSD
• ОС: любая с поддержкой Docker (Ubuntu, CentOS, Debian, macOS, Windows)

Быстрая установка

Состав контейнеров

• app — Node.js 20 + PM2 (backend + frontend)
• postgres — PostgreSQL 16 Alpine
• nginx — Reverse proxy, SSL, статика
• mailpit — SMTP/IMAP для email-интеграции
• openldap — Active Directory (опционально)

Настройка

Основные параметры задаются через файл .env и веб-интерфейс администратора.

Переменные окружения

Веб-настройки

После первого запуска войдите как администратор и настройте:

• Каталог услуг — иерархическая структура с SLA для каждой услуги
• Команды — группировка операторов для маршрутизации заявок
• Рабочий календарь — рабочие часы и выходные для расчёта SLA
• Модули — включение/отключение функциональности (AD, Email, Jira, Оборудование)

Первые шаги

После установки и базовой настройки:

• Создайте каталог услуг с SLA-параметрами
• Добавьте операторов и настройте команды
• Импортируйте пользователей из AD/LDAP или создайте вручную
• Настройте email-интеграцию для автоматического приёма заявок
• Установите мобильные приложения и укажите URL сервера

Управление заявками

Заявки проходят через 7 статусов с контролем переходов. Каждое действие записывается в аудит-лог.

• Новая (не назначена) — создана пользователем, ожидает обработки
• Новая (назначена) — создана оператором с назначением исполнителя
• В работе — оператор работает над заявкой
• Ожидает ответа — запрошена информация у пользователя, SLA приостановлен
• Отложена — временно приостановлена, SLA приостановлен
• Выполнена — оператор завершил работу
• Закрыта — финальный статус

Таблица заявок настраивается: 16 колонок, каждый пользователь выбирает свой набор. Доступны массовые операции и экспорт в Excel.

SLA и контроль сроков

Два типа SLA настраиваются для каждой услуги:

• SLA реакции — время от создания заявки до первого ответа оператора
• SLA решения — время от создания до выполнения
• Учёт рабочих часов по настраиваемому календарю
• Автоматическая пауза SLA при статусах «Ожидает ответа» и «Отложена»
• Цветовая индикация: зелёный (в норме), красный (просрочена), серый (пауза)

Управление оборудованием

Каталог оборудования с полным жизненным циклом: в использовании → ремонт → склад → списано.

• Каталог: название, тип, серийный и инвентарный номер
• Генерация и печать QR-кодов для инвентаризации
• Сканирование QR через камеру (Web + Mobile)
• Привязка оборудования к заявкам и сотрудникам
• Полная история изменений

База знаний

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

Email-интеграция

Автоматическое создание заявок из входящих писем на служебный адрес.

• Обработка вложений и inline-изображений (CID)
• Автоматическая привязка ответов к существующим заявкам
• Возобновление заявки по ссылке из email
• Оценка качества через email (звёзды-ссылки)
• HTML-шаблоны с брендированием

Интеграция с Jira

Связь заявок ServiceDesk с задачами Jira. Поддержка Cloud и on-premise (Server/Data Center).

• Настройка подключения: URL, email, API Token, проект по умолчанию
• Поиск задач по коду проекта или тексту
• Автоматическое обновление статуса из Jira API
• Цветовая индикация: Done (зелёный), In Progress (жёлтый), To Do (серый)
• Доступно на всех платформах: Web, iOS, Android

Active Directory / LDAP

Импорт и синхронизация пользователей из Active Directory или OpenLDAP.

• Автосинхронизация: ФИО, email, должность, отдел, телефон
• Настраиваемый BaseDN и фильтр поиска
• Маппинг атрибутов AD → полей системы
• Создание учётных записей с ролью USER по умолчанию

Мониторинг

Стек мониторинга включён в Docker Compose: Prometheus + Grafana + Node Exporter + cAdvisor + PG Exporter.

• Преднастроенный дашборд из 13 панелей
• Метрики Node.js, PostgreSQL, Docker, системы
• Алерты на критичные события

Мобильные приложения

Нативные приложения для iOS (SwiftUI) и Android (Jetpack Compose). Полный список функций →

• Авторизация с настраиваемым URL сервера
• Полный функционал: заявки, комментарии, действия оператора
• QR-сканер оборудования через камеру
• Статусная timeline — визуализация переходов

Безопасность

• JWT авторизация с Bearer Token и HTTP-only cookie
• bcrypt хеширование паролей (rounds 8)
• Ролевая модель с проверкой на каждом эндпоинте
• HTTPS с автоматическим редиректом
• CORS и CSP настройки
• Rate limiting на критичных эндпоинтах
• Аудит-лог всех действий с заявками

Методология внедрения

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

Этап 1: Подготовка (1–3 дня)

Задача этапа — подготовить среду, согласовать процесс, собрать справочные данные. Что нужно сделать:

• Выделить сервер под TIQQET согласно системным требованиям. Для тестового внедрения подойдёт виртуальная машина с 4 vCPU / 8 GB RAM. На продакшен — рекомендуем NVMe-диски и минимум 10 GB RAM.
• Получить SSL-сертификат для вашего домена (например, через Let's Encrypt или корпоративный CA). TIQQET работает через Nginx, который обрабатывает TLS на уровне reverse-proxy.
• Определиться с email-адресом для приёма заявок — обычно это help@company.ru или support@company.ru. Получить от почтового администратора данные SMTP и IMAP.
• Набросать структуру каталога услуг на бумаге — какие категории, их SLA, ответственные команды. Это самая важная часть подготовки, от неё зависит, насколько удобно будет работать в системе.
• Определить роли: кто операторы, кто аудиторы, кто рядовые пользователи. Если планируется синхронизация с Active Directory — определить OU, из которых будут импортироваться пользователи.

Этап 2: Установка и базовая настройка (1 день)

Практическое развёртывание системы:

• Скачать deployment-архив, заполнить .env с параметрами базы данных, JWT-секретом, URL системы.
• Запустить docker compose up -d — все контейнеры (PostgreSQL, приложение, Nginx, Prometheus, Grafana) поднимаются за несколько минут.
• Открыть систему в браузере, войти под суперадмином (логин создаётся при первом запуске).
• Включить лицензию — либо пробный триал на 7 дней, либо ввести ключ, полученный после оплаты.
• Настроить системные параметры: название организации, часовой пояс, рабочие часы по умолчанию.
• Настроить SMTP для исходящей почты и протестировать отправку тестового письма.

Этап 3: Каталог услуг и SLA (2–5 дней)

Это этап, на котором формируется «скелет» вашего сервисного процесса. Правильно настроенный каталог услуг — это 70% успешного внедрения любой программы для техподдержки.

• Построить дерево услуг: корневые категории (например, «Рабочее место», «Серверная инфраструктура», «Прикладное ПО», «Сетевые сервисы», «Доступы»), и под ними — конкретные услуги.
• Для каждой услуги настроить SLA реакции и решения исходя из реальной загрузки. Не ставьте завышенно агрессивные SLA в начале — это приведёт к постоянным просрочкам и недоверию к системе. Лучше начать с достижимых цифр и ужесточать по мере накопления статистики.
• Настроить рабочий календарь: рабочие дни, часы, государственные праздники. Для некоторых услуг (24/7-инфраструктура) — отдельный календарь с круглосуточным режимом.
• Назначить команды на услуги — это механизм автоматической маршрутизации заявок.

Этап 4: Пользователи и команды (1–2 дня)

• Если есть Active Directory — настроить синхронизацию по расписанию. Если нет — импортировать пользователей из CSV или создать вручную.
• Создать команды по специализациям: «Helpdesk 1-я линия», «Системные администраторы», «Сетевые инженеры», «Разработчики», «Администраторы 1С». Распределить операторов по командам.
• Настроить роли: кто оператор, кто аудитор, кто пользователь. Убедиться, что у каждого оператора корректно заполнены имя, фамилия, email — эти данные видны в комментариях и истории.
• Настроить политику смены паролей, политику блокировки при неудачных попытках входа.

Этап 5: Email и мобильные приложения (1 день)

• Подключить IMAP-поллер к почтовому ящику приёма заявок. Протестировать: отправить письмо на help@company.ru → убедиться, что оно превратилось в заявку за 30 секунд.
• Проверить обратную связь: оператор отвечает на заявку → пользователь получает email → отвечает на email → ответ попадает в комментарии заявки.
• Раздать операторам и ключевым пользователям мобильные приложения iOS и Android. Проверить логин, создание заявки, push-уведомления.

Этап 6: Пилот (2–4 недели)

Не запускайте TIQQET сразу на всю компанию. Выберите пилотный отдел — например, один филиал или один IT-департамент — и поработайте в системе 2-4 недели. За это время обычно всплывают нюансы: услуга не так называется, SLA завышен/занижен, не хватает кастомного поля, оператор хочет другой фильтр.

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

Этап 7: Раскатка на всю организацию (1 неделя)

• Объявить официальный запуск внутренним письмом с инструкциями и контактами службы поддержки TIQQET.
• Отключить старые каналы приёма заявок (группы в Telegram, личные email операторов, Excel-таблицы) — иначе люди продолжат писать в привычные места.
• В первую неделю — усиленная поддержка пользователей, быстрый отклик на замечания.
• Через месяц — анализ метрик в аналитике: сколько заявок обработано, сколько просрочено SLA, какая средняя оценка качества, какие услуги самые загруженные.

Типовые сценарии настройки

Сценарий 1: Внутренняя IT-служба среднего бизнеса (50–500 сотрудников)

Простейшая конфигурация. Один корневой каталог «IT-поддержка» с 8-12 услугами (почта, 1С, доступы, ПО, принтеры, сеть, учётные записи, удалёнка). Одна команда операторов, одна очередь. SLA реакции 30 минут, решения 4 часа для критичных, 8 часов для обычных. Active Directory обязательно — пользователи не должны запоминать ещё один пароль. Типичное внедрение — 3-5 дней.

Сценарий 2: Аутсорсинговая IT-компания

Несколько клиентов, у каждого свой каталог услуг и SLA. Решение — верхний уровень иерархии услуг содержит названия клиентов, под ними — услуги. Команды разделены по клиентам или по технологическим зонам. Для каждого клиента — своё SMTP/IMAP с отдельного ящика, чтобы переписка выглядела от имени клиента. Аналитика фильтруется по клиенту для контроля исполнения контрактов.

Сценарий 3: Производственное предприятие с распределённой географией

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

Сценарий 4: Госучреждение или регулируемая отрасль

Строгие требования к защите данных, хранение в РФ, ограничения на облака. TIQQET разворачивается в изолированном контуре без выхода в интернет (все внешние зависимости — из корпоративного registry). Аудит-лог всех действий операторов включён принудительно. Интеграция через корпоративный OpenLDAP. Это и есть реальное импортозамещение service desk — работает полностью внутри периметра, без зависимости от зарубежных вендоров.

Диагностика проблем

Если что-то идёт не так — начните отсюда. Большинство вопросов на внедрении решаются проверкой нескольких базовых пунктов.

Не приходят email-уведомления

• Проверить настройки SMTP в админке → тестовая отправка
• Проверить папку «Спам» у получателя — частая причина, решается настройкой SPF/DKIM/DMARC записей для исходящего домена
• Проверить логи контейнера приложения: docker compose logs app
• Убедиться, что у пользователя включены email-уведомления в настройках профиля

IMAP-поллер не забирает письма

• Проверить подключение по IMAP через telnet или openssl s_client
• Убедиться, что настроен именно TLS (порт 993), а не обычный IMAP (порт 143)
• Некоторые почтовые сервисы требуют создания «пароля приложения» вместо основного пароля
• Проверить, что поллер запущен только на одном воркере PM2 — чтобы не было дублирования заявок

Синхронизация AD падает

• Проверить, что сервер TIQQET может достучаться до контроллера домена по порту 636 (LDAPS)
• Если используется self-signed сертификат — разрешить его в настройках LDAP
• Проверить правильность bindDN и пароля сервисной учётки
• Проверить фильтр поиска — слишком широкий фильтр может приводить к таймауту

Заявки не создаются по маршрутам каталога услуг

• Проверить, что у услуги настроена команда или ответственный
• Убедиться, что пользователь при создании заявки выбрал именно услугу, а не просто категорию
• Для Jira-интеграции — проверить валидность API-токена и доступность проекта

Техническая поддержка

Если документация не отвечает на ваш вопрос, обратитесь в техподдержку TIQQET:

• Email: sales@tiqqet.ru — оставьте заявку с описанием проблемы, приложите логи и скриншоты
• Время реакции: в рабочее время в рамках условий оферты
• Что приложить к обращению: версию TIQQET (видна в футере админки), окружение (Docker version, ОС сервера), логи контейнера за последние 15 минут, скриншот ошибки если применимо

Также можно посмотреть полный список функций и API-референс — часто там есть ответы на вопросы о конкретных возможностях.