Техническая поддержка с использованием AI и повышенной эффективностью

1. Краткое резюме решения DARCA

Поддержка в DARCA - это продуктовый контур: in-app чат всегда под рукой, омниканал с единым кейсом, action-support через кнопки и deep-links, и AI-система из нескольких слоёв для скорости, качества и безопасности.

Info

Поддержка в DARCA - это часть платформы, а не “колл-центр”: она работает по принципам ядро + модули, real-time статусов и security-by-design.

В DARCA клиентский сервис задуман как полноценный продуктовый контур внутри приложения. Не “мы объяснили, что нажать”, а “мы довели пользователя до результата”. Это решение построено так, чтобы поддержка была одновременно: быстрой, безопасной, масштабируемой по языкам и времени, и при этом не превращалась в точку атаки для мошенников.

Доступ к поддержке: помощь всегда рядом, без поиска и ожиданий

В любой момент внутри приложения чат открывается свайпом справа налево. Это специально сделано так, чтобы помощь была всегда рядом, без поиска “где поддержка” и без переходов по меню.

Дальше чат работает как центр управления, а не как “окно переписки”. Если пользователь спрашивает, как выполнить действие, мы не ограничиваемся текстовой инструкцией. Мы ведём пользователя к конкретному результату и даём точный переход или действие через кнопку.

Tip

Логика action-support: вместо “зайдите туда и нажмите это” пользователь получает кнопку, которая ведёт в нужный экран или запускает сценарий.

Примеры того, как это выглядит по смыслу:

• “проверьте статус операции” - кнопка “Открыть статус”
• “нужна выписка” - кнопка “Сформировать выписку”
• “нужно подтвердить действие” - кнопка “Подтвердить в приложении”
• “нужны документы” - запрос документов или файлов прямо в чате

Example

В DARCA чат не заканчивается на ответе. Ответ должен заканчиваться действием или понятным следующим шагом.

Омниканал без потери контекста: один кейс, одна история, один результат

Основной канал поддержки - in-app чат. Дополнительно поддержка доступна в популярных мессенджерах (Telegram/WhatsApp/WeChat/iMessage и т.д.). Ключевой принцип: каким бы каналом ни пользовался клиент, у нас всегда один кейс, один таймлайн и один контекст, чтобы пользователь не повторял одну и ту же проблему несколько раз, а поддержка не “ломалась” на переключениях между каналами.

Note

Омниканал в DARCA - это единый кейс и единая история, а не “разные чаты в разных местах”.

Нулевая терпимость к мошенничеству: мы убираем звонки полностью

Мы полностью убираем звонки как канал обслуживания:

• DARCA не звонит пользователям
• DARCA не принимает звонки

Это сделано сознательно, потому что звонки - наиболее удобный инструмент для мошенничества и Social engineering. Мы отдельно формируем у пользователя привычку: любой звонок якобы от DARCA - это мошенники. Все действия происходят только в проверяемых цифровых каналах: приложение и официальные аккаунты в мессенджерах.

Warning

Любой звонок “от DARCA” считается мошенничеством. Официальные действия происходят только через приложение и официальные каналы.

Разделение полномочий: поддержка помогает, но не может “увести деньги”

Поддержка в DARCA не должна быть точкой, через которую можно украсть деньги “под видом помощи”. Поэтому:

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

Danger

Критичные операции нельзя “сделать за клиента”. Даже если общается оператор, финальное подтверждение и действие - только на стороне пользователя.

AI в поддержке: система из трёх слоёв, а не “один чат-бот”

Мы используем AI как постоянный слой сервиса, а не как “опциональную фичу”. Он работает на разных уровнях:

1. AI для пользователя

• отвечает 24/7
• понимает запрос
• ведёт по сценариям
• даёт кнопки и deep-links
• запрашивает документы и файлы прямо в чате

2. AI-ко-пилот для оператора

• поднимает контекст ещё до подключения оператора
• предлагает варианты ответов
• предлагает кнопки действий и сценарии
• ускоряет закрытие кейса с первого контакта

3. AI контроля качества

• делает саммари диалогов
• оценивает качество решения
• выявляет частые темы обращений
• помогает улучшать базу знаний и продукт

Info

AI в DARCA решает две задачи одновременно: скорость для пользователя и управляемое качество для платформы.

24/7 и все языки: масштабируемся архитектурой, а не численностью

Поддержка должна работать круглосуточно и на всех языках, но без огромных затрат. Мы делаем это так:

• пользователь пишет на любом языке
• система распознаёт язык и помогает перевести
• оператор получает контекст и готовый перевод
• ночью и в выходные AI закрывает массовые обращения, а небольшая команда подключается по on-call для критичных кейсов

Tip

Мы масштабируем поддержку не количеством людей, а архитектурой и автоматизацией.

Поддержка как экосистема: Academy, Universal Assistant, Autopilot, Messenger Module

Поддержка развивается в набор связанных контуров, которые уменьшают число ошибок и повышают самостоятельность пользователя:

• DARCA Academy - обучение и снижение ошибок
• Universal Assistant - ассистент “на любые вопросы”
• Autopilot - автоматические подсказки: поиск по транзакциям, напоминания, сценарии
• развитие в модуль-мессенджер с фин-функциями (переводы в чате, займы, документы/подпись), но всё критичное по-прежнему подтверждается пользователем

Question

Почему это важно? Потому что лучший сервис - это тот, который предотвращает ошибку до обращения: через обучение, подсказки и правильные сценарии.

Почему эта модель сильнее традиционной банковской поддержки

Классический банк пытается “ускориться” наймом. DARCA ускоряется тем, что:

• доступ к помощи мгновенный
• ответ заканчивается действием, а не текстом
• контекст не теряется: один кейс в омниканале
• звонки исключены: ниже риск мошенничества
• AI закрывает типовой поток, оператор усиливается ко-пилотом, качество контролируется отдельным AI-слоем

Ниже упрощённая логика потока:

• пользователь пишет в чат (in-app или мессенджер)
• AI понимает запрос и предлагает решение
• если нужно - подключается оператор с готовым контекстом
• результат фиксируется: действие, документ, статус, саммари
• частые проблемы уходят в аналитику и улучшают продукт

Note

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

2. Проблема и требования к целевому сервису

Фиксируем боли рынка и превращаем их в измеримые требования: поддержка DARCA должна быть быстрой, безопасной, омниканальной и масштабируемой без раздувания штата.

Info

Этот раздел - контракт качества. Если требование не выполняется, мы не считаем поддержку “готовой”, даже если формально есть чат и операторы.

Проблема рынка поддержки не в том, что “банки не стараются”, а в том, что сервис часто построен вокруг внутренних процессов, а не вокруг пользователя. В результате появляются типовые боли: ответы медленные, сервис не работает 24/7 там, где это критично, качество решения с первого контакта низкое (FCR падает), пользователь вынужден повторять одно и то же, а автоматизация раздражает и превращается в лабиринт. Добавим к этому провальный цифровой онбординг, где человек “обрывается” просто потому, что не понимает следующий шаг или не видит статуса, и получим самое опасное: падение доверия и быстрый отток. Когда сервис плохой, пользователь обычно не спорит - он уходит, особенно если речь о деньгах и безопасности.

Warning

Сервис разрушает доверие быстрее, чем его строит маркетинг: пользователь уходит не из-за цены, а из-за ощущения “меня не слышат”, “мне не помогают” и “я не понимаю, что происходит”.

Из этих болей мы выводим требования, которые становятся обязательными и не обсуждаются. Во-первых, поддержка должна быть доступна всегда: 24/7/365, без “режимов работы”, чтобы пользователь не думал “а сейчас они вообще отвечают?”. Во-вторых, она должна работать на любом языке, потому что масштабирование по миру невозможно, если язык - барьер. В-третьих, поддержка обязана быть омниканальной, но не в виде “разных чатов”, а в виде одного кейса и единого контекста: где бы ни начался диалог (в приложении или в мессенджере), пользователь не повторяет всё заново, а оператор видит историю и текущий статус.

Следующее требование - скорость как стандарт. Типовые вопросы должны закрываться мгновенно, сложные - быстро и с понятным ощущением “мой кейс в работе”. Здесь важно не только время ответа, но и способность закрыть кейс с первого контакта. Поэтому для нас ключевой показатель - FCR: пользователь должен получать решение, а не бесконечные уточнения и пересылки.

При этом сервис должен быть безопасным по умолчанию. Поддержка не может стать каналом мошенничества, и поэтому любые действия, связанные с деньгами, блокировками, подтверждениями или подписью, должны подтверждаться пользователем внутри приложения. Никаких “мы вам позвоним и решим” и никаких сценариев, где оператор может провести критичное действие “за клиента”.

Danger

Поддержка не должна создавать новый риск. Всё критичное подтверждается пользователем в приложении, иначе сервис становится точкой атаки.

Наконец, масштабирование не должно происходить “в линейку”. Нельзя решать рост просто наймом операторов: это дорого, медленно и нестабильно по качеству. Поэтому в требования сразу входит архитектура, где AI закрывает типовые запросы, готовит контекст и решения для оператора, а человек подключается там, где нужна ответственность, исключение или сложный кейс. Это не “чат-бот ради галочки”, а система, которая повышает качество, снижает повторные обращения и делает сервис управляемым.

Чтобы эти требования не оставались словами, мы фиксируем набор решений и ограничений DARCA. Первое - политика No Calls: мы не звоним и не принимаем звонки, а любой звонок “от DARCA” считается мошенничеством. Второе - Chat-first доступ: чат в приложении доступен всегда (свайп справа налево) и является основным каналом обслуживания и сопровождения. Третье - “action-чат”: и бот, и оператор могут давать кнопки и deep-links, чтобы пользователь не читал инструкции, а выполнял действие сразу. Четвёртое - разделение полномочий: оператор может выполнять некритичные действия и отправлять документы, но всё критичное (транзакции, подтверждения, подписи) выполняется только через кнопку и подтверждение пользователем в приложении. Пятое - омниканал через мессенджеры: помимо in-app чата поддержка доступна в популярных мессенджерах (Telegram/WhatsApp/WeChat/iMessage и т.п.), но с теми же правилами по критичным действиям и документам. Шестое - AI работает на всех уровнях: AI-ассистент общается с клиентом 24/7, AI-ко-пилот помогает оператору, а Supervisor AI контролирует качество, делает саммари и выявляет повторяющиеся запросы для улучшения продукта. Дополнительно AI является универсальным помощником “по любым вопросам”, частью DARCA Academy и может вести персональные автоматизации (напоминания, поиск по транзакциям, ежедневные дайджесты и т.д.).

Example

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

3. Принципы DARCA Customer Service

Фиксируем принципы, по которым проектируется поддержка, AI и процессы, чтобы сервис оставался быстрым, безопасным и качественным при любом масштабе.

Note

Это не “общие слова”, а правила проектирования. Если мы отступаем от них, поддержка перестает быть масштабируемой и безопасной.

Мы строим поддержку так, чтобы она работала одинаково хорошо при любом масштабе: от 10 000 до 10 000 000 пользователей. Для этого поддержка в DARCA не может держаться на “героических операторах” или на удачном расписании смен. Она проектируется как часть платформы по строгим правилам: chat-first, action-first, context-first, безопасность по умолчанию и масштабирование через AI, а не через линейный рост штата.

Chat-first: единая точка входа в помощь и сценарии продукта

Сервис начинается с того, что пользователь не ищет поддержку. Чат доступен всегда и открывается свайпом справа налево из любой точки приложения. Это превращает чат в главный интерфейс помощи, где пользователь получает не только ответы, но и понятный маршрут к решению. Через чат человек попадает в поддержку, видит статусы операций, получает документы, запускает сценарии, проходит обучение (Academy), включает персональные автоматизации (Autopilot) и использует универсального ассистента для любых вопросов. Важное здесь не количество функций, а принцип: у пользователя есть одно место, где “всё начинается” и где он не теряется в меню.

Tip

Принцип chat-first снижает фрагментацию: вместо десятка точек входа и “где это найти” у пользователя есть один понятный маршрут.

Action-first: диалог заканчивается действием, а не перепиской

В DARCA мы не строим поддержку вокруг длинных инструкций. Мы строим её вокруг результата. Это означает, что почти любой ответ в чате содержит две части: короткое объяснение “что происходит” и следующий шаг, оформленный как кнопка или точное действие. Так появляется action-support: вместо “зайдите туда, потом нажмите это” пользователь получает deep-link на нужный экран, либо готовое действие (например, сформировать выписку или запросить документ), либо подтверждение внутри приложения, если речь о критичном шаге.

Для ясности фиксируем типы “следующего шага”:

• Deep-link: открыть нужный экран, раздел, конкретную транзакцию, статус или кейс
• Action: сформировать выписку, запросить документ, включить или выключить модуль, создать кейс, отправить форму, начать проверку
• Confirm: подтвердить критичное действие внутри приложения (операции с деньгами, подписи, смена критичных настроек)

Warning

Правило action-first: если пользователь должен сделать 5 ручных шагов, мы обязаны превратить это в один сценарий и одну кнопку.

Context-first: решения принимаются на полном контексте, а не на догадках

Скорость и качество невозможны без контекста. Поэтому поддержка и AI работают по принципу context-first: сервис всегда поднимает максимум доступной информации, чтобы закрывать кейсы с первого контакта и без повторов. Контекст включает историю диалогов и обращений, статусы операций и кейсов, события безопасности (входы, новые устройства, попытки подозрительных действий), историю действий в продукте (где пользователь “застрял”), транзакции и паттерны платежей (для подсказок и автоматизаций), документы и формы, которые уже предоставлялись, а также предпочтения общения и настройки ассистента.

Это используется одинаково на двух уровнях. AI видит контекст и предлагает правильный сценарий сразу. Оператор, подключаясь, получает не “чистый чат”, а саммари, ключевые факты и рекомендованные действия с кнопками. Это напрямую повышает First call resolution и снижает количество повторных обращений.

Info

Context-first ускоряет сервис без потери качества: меньше уточнений, меньше повторов, выше точность решения.

No-call policy: звонки исключены как стандарт антифрода

Телефонные звонки - самый удобный канал для мошенничества и Social engineering. Поэтому DARCA работает по политике No Calls: мы не звоним пользователям и не принимаем звонки. Любой звонок “от DARCA” трактуется как мошенничество. Мы закрепляем это в продукте, в обучении и в сценариях чата, чтобы у пользователя формировалась устойчивая привычка безопасности. Официальные действия выполняются только в проверяемых цифровых каналах: in-app чат и официальные аккаунты в мессенджерах.

Danger

No-call policy - это не “ограничение”, а антифрод-стандарт, который снижает риски социальной инженерии и повышает доверие.

Small trusted team + AI: люди как спецназ, AI как масштабирование

DARCA не масштабирует поддержку линейно количеством операторов. Мы масштабируемся архитектурой: AI закрывает массовые вопросы, переводит на любые языки, помогает оператору отвечать быстрее и контролирует качество. Люди подключаются как “спецназ” там, где нужна ответственность, нестандартное решение или контроль критичных кейсов. Ночью и в выходные AI закрывает основной поток, а небольшая доверенная команда работает по on-call для критичных ситуаций.

Здесь важен не только ассистент для пользователя. У нас AI работает на нескольких уровнях:

• AI-ассистент общается с пользователем 24/7
• AI-ко-пилот помогает оператору (контекст, варианты ответов, кнопки действий)
• Supervisor AI оценивает качество, делает саммари и выявляет причины обращений

Example

Пользователь пишет на любом языке и в любое время, сервис отвечает быстро и в одном стиле, а критичные кейсы не “проваливаются” из-за часового пояса.

Никаких критичных действий без пользователя: поддержка не точка взлома

Поддержка не должна создавать новый риск. Поэтому мы жестко разделяем полномочия. Бот и оператор могут выполнять некритичные действия, выдавать документы, запрашивать документы, сопровождать и помогать. Но всё, что связано с деньгами, подтверждениями, подписями и изменениями безопасности, выполняется только через кнопку и подтверждение пользователем внутри приложения. Оператор может подготовить действие, но совершает его всегда пользователь.

Danger

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

Сервис как продукт: поддержка снижает количество проблем, а не “тушит пожары”

Поддержка в DARCA не живет отдельно от продукта. Мы используем её как механизм улучшения системы. Supervisor AI и аналитика выявляют повторяющиеся вопросы, точки, где пользователи застревают, причины негативного опыта и неочевидные элементы интерфейса. Дальше это превращается в конкретные изменения: улучшения интерфейса, онбординга, статусов, базы знаний, автоматизаций (Autopilot) и уроков (DARCA Academy). Чем меньше пользователь ошибается и застревает, тем меньше обращений, выше доверие и ниже стоимость обслуживания.

Tip

Лучший сервис - тот, который предотвращает проблему до обращения: через обучение, подсказки и корректные сценарии.

Модульность: поддержка растет как платформа, без перегруза и монолита

Поддержка развивается по принципу ядро + модули, как и весь банк. Базовый Support Chat всегда включен, а дополнительные контуры подключаются модульно: Academy, Universal Assistant, Autopilot и далее Messenger Module. Это позволяет развивать сервис без перегруза интерфейса и показывать пользователю только то, что ему действительно нужно. Правило простое: сервис растет, но продукт не превращается в монолит.

4. Клиентский интерфейс поддержки

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

Info

Мы делаем поддержку как суперспособность приложения: она рядом в любой момент, понимает контекст и решает, а не переписывается.

Чтобы поддержка действительно закрывала рыночную боль “низкое качество обслуживания”, она должна начинаться не с оператора и не с скриптов, а с интерфейса. Именно интерфейс определяет, будет ли пользователь чувствовать контроль, получать быстрые решения и доверять системе, или будет теряться в меню, ждать ответа и повторять одно и то же. Поэтому клиентский интерфейс поддержки в DARCA - это не “раздел в настройках”, а встроенный слой продукта, который работает постоянно и всегда остается рядом.

Поддержка доступна за 1 жест и не ломает контекст

Основной принцип доступа простой: пользователь не должен думать “где поддержка”. Чат открывается в любой точке приложения свайпом справа налево. Это сделано специально как оверлей, а не как отдельная страница: пользователь не теряет контекст того, что делал, может сразу показать проблему на текущем экране и так же быстро вернуться назад. В местах, где поддержка особенно востребована (операции, обмен, вывод, документы, безопасность), дополнительно доступны быстрые входы, а при ошибках система может предложить “умный вход” в чат именно по событию, чтобы разговор начинался сразу с привязкой к конкретной операции.

Tip

Вход “за 1 жест” убирает лишнюю навигацию, снижает раздражение и сокращает количество обращений вида “не могу найти, где это сделать”.

Чат объединяет статусы операций, кейсы и документы в единую ленту

Одна из самых частых причин обращений в банках - не сам сбой, а отсутствие понимания “что происходит сейчас”. Поэтому в DARCA поддержка встроена в логику статусов: у пользователя есть единая лента событий, где в понятной форме отражаются статусы операций, статусы кейсов поддержки и статусы документов. Если что-то задержалось, отклонено или требует действий, пользователь видит не абстрактную ошибку, а причину, текущий статус и следующий шаг. Таким образом, огромный класс обращений “где деньги?” и “что с заявкой?” закрывается интерфейсом, а не перепиской.

Note

Правило: если есть статус, пользователь видит его без запроса оператору. Поддержка должна уменьшать поток обращений, а не зависеть от него.

Ответ всегда заканчивается действием: deep-links, действия и документы прямо в чате

В DARCA чат - это не окно для инструкций, а инструмент управления. Мы используем action-support: вместо “пройдите в меню и нажмите” пользователь получает кнопку. В зависимости от ситуации это может быть deep-link на нужный экран или конкретную транзакцию, действие (сформировать выписку, запросить документ, создать кейс) или подтверждение внутри приложения, если шаг критичный. Важно, что чат умеет работать с документами и файлами: пользователь может загрузить документ прямо в диалог, получить справку или выписку, увидеть статус проверки и завершить процесс без переходов в почту и без ручной пересылки.

Это принципиально меняет восприятие сервиса: поддержка не “объясняет”, а доводит до результата. Причем результат всегда безопасен: если действие критично, финальное подтверждение делает пользователь внутри приложения.

Example

Пользователь спрашивает “как получить выписку”. Вместо инструкции чат сразу показывает карточку и кнопку “Сформировать выписку”, а результат приходит в диалог как файл. Это экономит время пользователю и снижает нагрузку на поддержку.

В системе нет тупиков: любой сценарий имеет понятный выход

Классическая проблема ботов - они либо не понимают, либо гоняют по кругу. В DARCA это запрещено на уровне продукта. В любой точке у пользователя всегда есть понятный выход: либо решение сейчас (кнопка или действие), либо подключение оператора с уже собранным контекстом, либо создание кейса со статусом и ожидаемым временем. Если AI не уверен, он не “фантазирует”, а переводит на оператора или оформляет кейс. Если вопрос требует времени, это становится кейсом со статусом, а не обещанием “мы уточним”.

Warning

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

Экстренные сценарии без звонков: цифровой SOS внутри продукта

Отказ от звонков не означает отказ от быстрых действий в критической ситуации. Наоборот, мы переводим экстренные сценарии в проверяемый цифровой контур. В чате всегда доступны быстрые сценарии “подозрение на взлом”, “мне звонили от DARCA”, “я не узнаю операцию”, “потерял устройство” и похожие. Выбирая сценарий, пользователь запускает структурированную цепочку шагов: проверка сессий и устройств, рекомендации безопасности, действия, которые можно выполнить немедленно (с подтверждением пользователя), и фиксация статуса каждого этапа.

Danger

Экстренная ситуация должна превращаться из хаоса в структурированный сценарий с понятными шагами и статусами.

Единый стиль общения и персонализация тона ассистента

Чтобы поддержка ощущалась “единой системой”, мы даем возможность настраивать тон ассистента (строгий, нейтральный, дружелюбный и т.д.), а оператор видит эти настройки и продолжает коммуникацию в том же стиле. Это снижает стресс, повышает доверие и уменьшает ощущение разрозненности между ботом и человеком.

Интерфейс проектируется с прицелом на Messenger Module

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

5. Каналы поддержки и омниканал

Пользователь пишет там, где ему удобно, но внутри это всегда один и тот же кейс, один таймлайн и единые статусы - без потери контекста и без риска.

Note

Принцип один: несколько каналов снаружи - одно ядро внутри. Это и про удобство, и про безопасность, и про масштабирование.

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

Обязательные каналы DARCA

Главный и приоритетный канал - In-App Chat. Он встроен в продукт, видит полный контекст, умеет запускать действия и подтверждения, и главное - безопасен и проверяем. Это наш базовый “правильный” канал, потому что именно здесь можно доводить сценарий до результата, а не просто переписываться.

Правило: если вопрос связан с деньгами, подписью или безопасностью, финальный шаг всегда происходит в приложении.

Дополнительно мы даем поддержку там, где пользователи реально живут: Telegram, WhatsApp, WeChat, iMessage (и при необходимости региональные каналы под рынки). Эти каналы нужны не для действий, а для быстрого контакта “на ходу”: подсказок, объяснений, сбора деталей, отправки допустимых документов и отправки кнопок/ссылок, которые ведут пользователя в нужный экран приложения через Deep linking.

Tip

Мессенджеры дают скорость входа, а приложение дает контроль и безопасность. Вместе это решает проблему “либо удобно, либо защищенно”.

Единая модель “один клиент - один кейс - один таймлайн”

Неважно, где пользователь начал диалог: в приложении или в Telegram. Внутри DARCA это всегда:

• одна карточка клиента
• один активный кейс (или несколько, если темы разные)
• единый таймлайн событий, где фиксируются сообщения, статусы, решения, запросы документов и выполненные действия

Это дает конкретный эффект: пользователь не повторяет проблему заново, оператор подключается и сразу видит, что уже было, а AI работает по полной истории и не задает “глупых” вопросов.

Жесткое разграничение возможностей по каналам

Чтобы омниканал был безопасным, мы разделяем “коммуникацию” и “действия”.

Во внешних мессенджерах можно консультировать и объяснять, уточнять детали и собирать информацию, отправлять инструкции и краткие гайды, отправлять документы/файлы в рамках правил кейса, отправлять deep-link кнопки на нужный экран приложения, создавать и вести кейс со статусом внутри нашей системы и информировать о ходе решения.

Только в приложении, через кнопку и подтверждение пользователя, находится “красная зона”. Ее не делает ни оператор, ни бот, ни внешний канал:

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

Принцип: внешний канал - это коммуникация и сопровождение. Приложение - это место, где происходят действия.

Warning

Это напрямую снижает вероятность социальной инженерии: даже если внешний канал скомпрометирован, он не может стать “рукой”, которая двигает деньги.

Верификация официальных каналов и защита от подмены

Так как мы исключаем звонки и делаем мессенджеры важным каналом, критично исключить сценарий “фейковая поддержка”. Поэтому в приложении есть раздел “Официальные каналы DARCA” с точными @/ID/названиями аккаунтов и инструкциями, как проверить, что это мы. В мессенджерах используем все доступные механики подтверждения и верификации (где платформа позволяет), а также двустороннюю проверку через приложение: бот или оператор предлагает нажать кнопку “Проверить канал” в приложении, и пользователь получает подтверждение, что контакт действительно официальный.

Маршрутизация между каналами без потери контекста

Пользователь может начать разговор в Telegram, продолжить в приложении, отправить документ в приложении и получить итоговое решение снова в Telegram. Это возможно за счет двух механизмов.

Сначала связывается идентичность: пользователь подтверждает привязку мессенджера к аккаунту DARCA через приложение, после чего мы точно знаем, что конкретный Telegram/WhatsApp/WeChat принадлежит конкретному пользователю.

Далее работает единая модель кейса: любой канал “пишет” в один и тот же кейс, статусы одинаковые, решения одинаковые, таймлайн один. Если запрос касается критичной темы, система не пытается “сделать действие” во внешнем мессенджере и отправляет кнопку “Продолжить в приложении”. Внутри приложения пользователь видит контекст, саммари, готовую кнопку подтверждения и выполняет действие безопасно.

Как омниканал работает с AI, чтобы 24/7 и языки были реальными

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

Почему такая схема снижает расходы и повышает качество

Мы не содержим колл-центр и не строим IVR. Мы не набираем операторов “под языки”. Мы не теряем контекст и не получаем повторные обращения из-за разных ответов. Мы переводим поддержку из “переписки” в “управляемые действия”, что сокращает время решения и повышает доверие.

6. AI-архитектура поддержки: 3 слоя вместо “чат-бота”

В DARCA AI - это не один бот, а постоянная система из трёх взаимосвязанных слоёв: для пользователя, для оператора и для контроля качества.

Info

Важно: AI в DARCA работает постоянно, а не “иногда”. Мы строим систему, где автоматизация дает результат, а не имитирует поддержку.

Мы не рассматриваем AI как “чат-бота ради галочки”. В DARCA AI - это отдельный инженерный слой поддержки, который работает всегда и закрывает сразу три задачи: мгновенно помогать пользователю, усиливать оператора во время диалога и после каждого кейса улучшать качество сервиса и самого продукта. Поэтому AI у нас устроен как система из 3 слоёв, где каждый слой отвечает за свой контур ответственности и не подменяет остальные.

Client AI - слой для пользователя (24/7, сценарии, действия)

Первый слой - Client AI. Это ассистент, который общается с пользователем 24/7 и ведёт его по понятным сценариям, не заставляя угадывать, что делать дальше. Он умеет понимать сложные запросы и разбирать их на шаги, но ключевой момент в том, что он не ограничивается “текстовыми объяснениями”. Он сразу помогает дойти до результата: предлагает нужные действия, даёт кнопки и глубокие ссылки, а когда требуется, запрашивает документы или файлы прямо в диалоге, чтобы не выносить процесс наружу.

Agent Copilot - слой для оператора (контекст, ответы, кнопки)

Второй слой - Agent Copilot. Он работает параллельно, пока оператор подключается к чату, и делает поддержку быстрее без потери качества. Copilot автоматически поднимает контекст пользователя и ситуации, подготавливает саммари, предлагает варианты ответов и самое главное - предлагает готовые кнопки действий, которые помогут закрыть кейс за один контакт. Так оператор не тратит время на поиск информации и на “ручное объяснение маршрутов” и быстрее приводит пользователя к решению через понятный следующий шаг.

Tip

Смысл Agent Copilot не в том, чтобы “заменить оператора”, а в том, чтобы оператор заходил в диалог уже с контекстом, готовыми вариантами решения и следующими действиями, закрывая кейсы с первого контакта.

Supervisor AI - слой контроля качества и развития продукта (саммари, метрики, улучшения)

Третий слой - Supervisor AI. Он включается после завершения диалога и превращает поддержку в механизм постоянного улучшения. Supervisor AI делает саммари разговора, оценивает эффективность решения, выявляет повторяющиеся темы и частые вопросы, а затем помогает улучшать базу знаний и продукт так, чтобы многие проблемы вообще не возникали в будущем. Это принципиально важно: мы не хотим бесконечно масштабировать поддержку “объёмом переписок”, мы хотим снижать число обращений через улучшение интерфейса, статусов, онбординга и сценариев.

Example

Если одна и та же ошибка появляется в сотнях обращений, Supervisor AI фиксирует паттерн, формирует выводы и превращает это в конкретную задачу: улучшить экран, добавить подсказку, изменить сценарий или расширить базу знаний, чтобы пользователи не “упирались в стену”.

Таким образом AI в поддержке DARCA - это не отдельный бот, а система, где пользователь получает помощь и действия в реальном времени, оператор получает ускорение и контроль качества во время работы, а платформа получает непрерывный цикл улучшений после каждого кейса.

7. Client AI: ассистент 24/7, который доводит до результата

Client AI - первый уровень поддержки DARCA: он работает круглосуточно, понимает контекст пользователя и ведёт по безопасным сценариям с кнопками и действиями.

Tip

Принцип: Client AI не “пишет инструкции”, а строит маршрут решения и завершает его вместе с пользователем.

Client AI - это первый слой поддержки DARCA и одновременно самый массовый. Его задача не в том, чтобы звучать “умно” или заменять человека текстом, а в том, чтобы закрывать основной поток вопросов быстро, корректно и без ожидания. Пользователь должен получать помощь в любую минуту, на любом языке и в едином стиле общения, но самое главное - он должен получать не переписку, а решение. Поэтому Client AI работает как постоянный ассистент 24/7 и соединяет в себе поддержку, навигацию по продукту, обучение и запуск действий.

Контекст как базовая способность, а не “дополнительная фича”

Client AI живет внутри in-app чата и доступен в любой момент. Он видит контекст того, что происходит: на каком экране находится пользователь, какую операцию он пытался сделать, какие статусы у транзакций и кейсов, какие документы уже загружены, какие настройки безопасности включены. Благодаря этому помощь начинается не с “расскажите заново”, а с фактов, и ассистент не задает лишних вопросов, которые обычно раздражают и создают ощущение “меня не слышат”.

Note

Чем больше контекста видит ассистент, тем выше точность ответа и тем меньше повторных обращений.

Ответ превращается в сценарий, а сценарий - в следующий шаг

Client AI отвечает так, чтобы человек понимал, что происходит и почему. Но ключевое отличие от классических ботов в том, что он не ограничивается объяснением. Он переводит запрос в понятный сценарий и сразу показывает следующий шаг, потому что в финансовом продукте “инструкция” редко закрывает проблему. Пользователь либо завершает действие, либо застревает снова. Поэтому ассистент ведёт его до результата.

Action-support: кнопки и deep-links вместо длинных инструкций

Client AI умеет давать кнопки и deep-links на нужные экраны и конкретные объекты: транзакцию, документ, статус, настройку. Он может запускать разрешенные действия вроде создания кейса, формирования выписки или запроса документа, а также показывать карточки со статусами и следующими шагами. Это превращает поддержку в интерфейс управления, где пользователь делает всё в 1-2 клика, а не читает “пройдите туда, затем туда”.

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

Warning

Client AI может “подвести” к критичному действию, но не может выполнить его без подтверждения пользователя. Это часть антифрод-архитектуры.

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

Если для решения вопроса нужны данные или документы, пользователь не должен уходить в почту, пересылки и внешние каналы. Client AI запрашивает всё прямо в чате: документ, фото, форму, подтверждение. Он фиксирует статус “ожидаем”, следит за форматом и продолжает сценарий сразу после получения. Это делает процессы короткими, управляемыми и прозрачными, а пользователю не приходится “собирать квест” по разным каналам.

Поддержка как обучение: DARCA Academy и универсальный помощник

Client AI - это не только решение проблем “когда уже что-то сломалось”. Он также работает как универсальный помощник “по любым вопросам” и как часть DARCA Academy. Он может объяснять функции простыми словами, проводить мини-обучение по тому, что доступно прямо сейчас, и показывать, что станет доступно после KYC и как это включить. Он умеет ненавязчиво сопровождать пользователя по постепенному онбордингу, чтобы человек не терялся и не уходил из-за непонимания продукта.

Единый стиль общения и персонализация тона

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

Question

Как избежать ощущения “робота” и сохранить доверие?

Client AI не должен притворяться человеком. Он должен быть предсказуемым и полезным: отвечать коротко, показывать статус, давать следующий шаг и честно переводить на оператора, когда уверенность низкая.

Эскалация без повторов: ассистент передает оператору готовый контекст

Если запрос сложный, рискованный или ассистент не уверен, он не спорит и не “догадывается”. Он собирает необходимые детали, делает саммари и подключает оператора или создает кейс. Оператор получает уже подготовленный контекст, поэтому пользователю не нужно повторять проблему заново. Так Client AI одновременно снижает нагрузку на поддержку и повышает скорость решения сложных ситуаций.

В результате Client AI становится постоянным слоем сервиса, который делает поддержку мгновенной, безопасной и масштабируемой: он закрывает массовые обращения сам, а сложные ускоряет за счет правильной маршрутизации и передачи контекста.

8. Устранение провалов чат-ботов (как в исследовании)

Мы убираем типовые провалы банковских ботов не “скриптами”, а архитектурой: контекст, действия и безопасная эскалация без тупиков, встроенные в кейсы и статусы.

Info

В большинстве банков “чат-бот” - это витрина автоматизации, которая раздражает пользователей. В DARCA AI - часть платформы поддержки, связанная с кейсами, статусами, действиями и операторами.

В исследовании прямо видно, почему банковские боты часто воспринимаются как проблема: они не понимают сложные запросы, не видят контекст, задают бесконечные уточнения и, когда не справляются, превращаются в тупик, где человеку не дают нормального перехода к оператору. В DARCA мы устраняем эти провалы на уровне системы: AI у нас не отдельный “бот”, а инженерный слой, который всегда знает, что происходит, умеет доводить пользователя до действия и умеет корректно передавать кейс человеку.

---

Почему банковские боты проваливаются и как мы это закрываем

Провал №1: бот не понимает сложный запрос и “ломается”.
Пользователь это ощущает как: “я объяснил проблему, бот задаёт странные вопросы и не двигается к решению”. Мы закрываем это тем, что AI работает не как “угадайка”, а как сценарная система: он опирается на контекст (статусы, операции, документы, безопасность, историю) и строит ответ как маршрут к следующему шагу. Если запрос не укладывается в сценарий, AI не “догадывается”, а переключает на оператора или оформляет кейс.

Warning

Запрещено: уверенно отвечать без опоры на контекст и базу знаний. Если уверенность низкая - только handoff или кейс.

Провал №2: у бота нет контекста, и пользователь вынужден повторять всё заново.
Классическая боль: “объяснил боту, потом подключился оператор - и снова расскажи сначала”. У нас это невозможно, потому что коммуникация всегда живёт в сущности кейс, а перед подключением оператора система формирует саммари, список связанных объектов (операция, документ, модуль), текущий статус и следующий шаг. Оператор подключается уже “внутри ситуации”.

Провал №3: бот превращается в тупик.
Когда бот не помог, но дальше некуда, пользователь злится и уходит. В DARCA тупиков нет: в любой момент есть понятный выход - решение кнопкой, подключение оператора или создание кейса со статусом.

Провал №4: бот ничего не может сделать, он только говорит.
Если бот отвечает текстом, а пользователь всё равно вручную проходит сложный путь, это не поддержка. Поэтому у нас чат - это action-чат: помощь завершается действием (кнопкой, deep-link, запросом документа, генерацией выписки, созданием кейса), а не длинной инструкцией.

---

Три обязательных свойства, которые убирают “раздражающий бот-опыт”

Чтобы провалы не повторялись, поддержка должна иметь сразу три свойства, и все три обязательны.

1) Контекст
AI видит историю обращений, статусы операций, документы, события безопасности, активные модули и действия пользователя в приложении. Это делает ответы точными и уменьшает лишние уточнения.

2) Действия
AI умеет выдавать кнопки и глубокие ссылки, запускать процессы Workflow, запрашивать документы и формировать документы (выписки, справки) прямо в чате.

3) Handoff (эскалация)
AI умеет подключать оператора с готовым саммари, передавать кейс в нужную очередь, выставлять приоритет и фиксировать следующий шаг, чтобы оператор не начинал “с пустого листа”.

Tip

Вместе эти свойства убирают ключевую боль: пользователь не “переписывается с ботом”, он проходит маршрут решения.

---

Контуры уверенности: когда AI решает сам, а когда переключает на человека

Мы не делаем робота, который упрямо спорит с пользователем. Мы делаем систему, которая знает границы и действует рационально.

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

Принцип: если это не решается мгновенно, пользователь должен видеть статус и понимать, что происходит.

---

“Обучение на выборе оператора”: как AI становится лучше каждый день

Нам важно, чтобы AI улучшался не “в теории”, а на реальных кейсах. Для этого AI предлагает оператору несколько вариантов ответа плюс предлагаемые действия и кнопки. Оператор выбирает лучший вариант, редактирует или пишет свой, а система фиксирует выбор, правки и результат (закрыт ли кейс, был ли повтор, оценка клиента). Это позволяет улучшать качество ответов, расширять сценарии, снижать число эскалаций и повышать First call resolution.

---

Как мы устраняем “раздражающие” паттерны ботов

Мы запрещаем типовые “грехи” банковских ботов и закрываем их правилами системы.

• Бесконечные уточнения без результата - если за N шагов нет прогресса, AI обязан предложить действие или handoff.
• Ответы “не по теме” - AI обязан опираться на контекст и базу знаний, а если не уверен - не выдумывать, а эскалировать.
• Скрытая поддержка - поддержка всегда доступна, не спрятана в меню и не требует “дозвониться”.
• Перекладывание ответственности на пользователя - вместо “обеспечьте, проверьте, обратитесь” мы даём кнопку и ведём к решению.

---

Что получает пользователь на практике

На уровне ощущений поддержка выглядит так: пользователь написал один раз, получил понятное объяснение, увидел статус, получил кнопку, получил результат. Если нужно - подключился оператор, но уже с пониманием контекста. Если процесс долгий - есть кейс, статусы и сроки. Именно так мы превращаем AI из раздражителя в ключевой драйвер лучшего сервиса.

9. Полный отказ от IVR и звонков как продуктовая стратегия

Мы убираем звонки и IVR не ради “хайпа”, а как практическую anti-fraud стратегию: меньше мошенничества, больше прозрачности, быстрее сервис и проще масштабирование.

Warning

Правило DARCA: мы не звоним и не принимаем звонки. Любой “звонок от DARCA” следует считать мошенничеством.

Мы сознательно убираем телефонные звонки и IVR из клиентского сервиса. Это не спор “какой канал удобнее”, а инженерное решение, которое одновременно снижает мошенничество, повышает прозрачность, делает сервис быстрее и упрощает масштабирование на весь мир. Важно, что мы не просто “убрали звонки”, мы заменили их системой, где любой запрос превращается в управляемый цифровой кейс со статусом, а критичные шаги выполняются только внутри приложения с подтверждением пользователя.

Почему IVR ломает сервис и почему мы исключаем звонки

Телефонные цепочки и IVR почти всегда создают трение. Пользователь тратит время на “нажмите 1, нажмите 2…”, затем вынужден повторять информацию несколько раз, а сам разговор не сохраняет контекст как цифровой кейс. В итоге качество и результат зависят от того, к кому человек попал, то есть сервис становится “лотереей”.

Но ещё важнее безопасность. Телефон - главный инструмент мошенников и Social engineering. Типовой сценарий в реальном мире известен: фальшивый номер, “служба безопасности банка”, психологическое давление, просьбы назвать код или фразу, либо “подтвердить отмену операции”. У звонков нет естественного, встроенного механизма проверяемости, а значит они идеально подходят для атак.

Наконец, телефон плохо масштабируется. Чтобы поддерживать качественный голосовой сервис, нужен огромный штат, множество смен, отдельный контроль качества и постоянное обучение. Это дорого, медленно и в итоге всё равно не даёт того, что даёт цифровая поддержка - статусы, аудит и воспроизводимость процесса.

Note

Отказ от звонков - это способ превратить поддержку из “разговора” в управляемый процесс с прозрачными правилами и проверяемыми действиями.

Как мы заменяем телефон: чат-маршрутизация и экстренные сценарии в чате

Вместо IVR у нас работает чат-маршрутизация. Пользователь пишет один запрос на любом языке, AI делает Triage, а система сразу ведёт по сценарию и даёт кнопки действий. При необходимости задаётся 1-2 уточнения, но без “лабиринта” и без бесконечных перекидываний между категориями.

Так как звонков нет, экстренные сценарии обязаны быть встроены в продукт. Поэтому в чате всегда есть быстрые кнопки:

• “Подозрение на взлом”
• “Мне звонили от DARCA”
• “Я не узнаю операцию”
• “Проблема с доступом”
• “Нужно срочно остановить риск”

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

Для критичных шагов действует отдельное правило: мы не “делаем действие” в мессенджере. Мы даём кнопку “Продолжить в приложении”, и пользователь подтверждает критичный шаг внутри DARCA. Так поддержка остаётся удобной, но критичные действия остаются в защищённом контуре приложения.

Tip

В результате любой риск-сценарий превращается не в разговор, а в набор проверяемых шагов, которые невозможно “уговорить голосом”.

Постоянное обучение: “если звонят от DARCA - это 100% мошенники”

Чтобы правило “No Calls” реально работало, его нужно закрепить в интерфейсе и привычках пользователя. Мы встраиваем его сразу в несколько точек: в профиле и настройках безопасности отдельным блоком “DARCA never calls”, в первом онбординге коротким предупреждением (без запугивания, но чётко), в чате поддержки быстрым сценарием “мне звонили” с объяснением и действиями, а также в Academy уроком “как распознавать мошенничество”.

Когда пользователь пишет фразу “мне звонили”, система реагирует не как “оператор по телефону”, а как anti-fraud механизм: AI сразу распознаёт риск, включает защитный сценарий и предлагает действия - проверить входы, сменить настройки безопасности, ограничить операции и создать кейс.

Кнопка “подозрение на взлом/мошенничество” и защитные действия

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

Дальше сценарий не “обещает помощь”, а делает конкретные шаги, которые пользователь видит и подтверждает:

• “Проверить активные устройства/сессии”
• “Завершить все сессии кроме текущей”
• “Усилить подтверждения” (step-up)
• “Временно ограничить операции” (с подтверждением пользователя)
• “Создать приоритетный кейс Sev-1”
• “Подключить оператора” (если риск высокий)

Это лучше звонка, потому что это мгновенно, подтверждается пользователем в приложении, имеет аудит и статусы (прозрачный Audit trail), и исключает социальную инженерию “голосом”.

Example

Пользователь пишет “мне звонили от DARCA, сказали срочно отменить перевод”. Система не спорит и не уточняет лишнего: включает защитный сценарий, показывает активные сессии, предлагает завершить лишние, усилить подтверждения и временно ограничить операции, затем создаёт приоритетный кейс. Всё происходит внутри продукта и фиксируется статусами.

Почему “No Calls” повышает доверие, а не снижает его

Интуитивно кажется, что “без телефона” будет менее доверительно. На практике работает наоборот, потому что доверие строится на предсказуемости и проверяемости. При “No Calls” поддержка всегда доступна (чат 24/7), ответы быстрые (AI), решения конкретные (кнопки и действия), критичные шаги безопасны (подтверждение пользователем), а всё прозрачно (статусы и кейсы). Пользователь перестаёт зависеть от “повезло с оператором” и начинает жить в модели “всё проверяемо и управляемо внутри продукта”.

10. Онбординг и сложные процессы как workflows

Мы проектируем онбординг и любые “длинные” сценарии как управляемые workflows со статусами, прогрессом, кнопками действий и безопасными подтверждениями.

Note

Самая дорогая причина “плохого сервиса” - не ответы операторов, а процессы без статуса: пользователь сделал шаг, дальше тишина, и он уходит, потому что “ничего не происходит”.

В DARCA онбординг и все сложные сценарии поддержки строятся не как набор форм и текстовых инструкций, а как управляемые workflows - процессы, которые ведут к результату и сохраняют состояние на каждом шаге. Это означает, что пользователь всегда понимает, где он находится, что происходит прямо сейчас и что будет следующим шагом. Он не “попадает в лабиринт” и не зависит от того, онлайн ли оператор. Он проходит маршрут, где каждый этап имеет статус, причину (если что-то задержалось) и кнопку действия.

Почему в банках ломается онбординг и “длинные” кейсы

Обычно провал происходит не из-за отсутствия функций, а из-за отсутствия прозрачности. Пользователю дают много шагов и форм без объяснения, затем просят документы, потом “проверяют”, но человек не видит статуса, не понимает сроки и начинает нервничать. Если он отвлёкся или закрыл приложение, прогресс теряется, и ему кажется, что он должен начинать заново. Мелкие ошибки в документах приводят к повторным отправкам, а поддержка превращается в бесконечные сообщения “пришлите ещё раз” вместо понятного процесса.

Warning

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

Как это устроено в DARCA: процесс со стадиями, статусом и следующим шагом

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

Онбординг через чат: chat-guided подход вместо “заполните форму”

Ключевой элемент - in-app чат как интерфейс управления процессом. Пользователь не остаётся один на один с формой. Чат объясняет шаги коротко и по делу, показывает статус проверки, даёт кнопку “продолжить”, запрашивает документы прямо в диалоге и подсказывает, как именно они должны выглядеть. Так онбординг становится “сопровождением”, а не “квестом”. Это сильно снижает процент брошенных регистраций и уменьшает количество обращений в поддержку, потому что большую часть вопросов закрывает сам интерфейс процесса.

Tip

Если человек в любой момент понимает “где я сейчас” и “что дальше”, он редко пишет в поддержку. Workflow - это способ снизить нагрузку на сервис не количеством операторов, а ясностью процесса.

Документы и исправления: не “отклонено”, а понятная причина и кнопка “исправить”

Документы - одна из самых частых точек боли в финтехе. Мы решаем это тем, что запрос документа всегда структурирован: что нужно, зачем это нужно, какой формат, какие частые ошибки. После отправки пользователь видит статус “принято/на проверке/нужно исправить”. Если документ не подходит, система не пишет “отклонено” без пояснения, а показывает конкретную причину и даёт кнопку “исправить” или “загрузить заново”. И всё это происходит в рамках одного и того же workflow и одного кейса, а не разрозненных переписок.

Длинные кейсы поддержки тоже становятся workflows: споры, проверки, восстановление

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

Info

Мы опираемся на принципы Know_your_customer и Anti-money_laundering, но коммуникацию строим так, чтобы у пользователя всегда был статус, причина и следующий шаг.

“Войти и продолжить”: пользователь не теряет прогресс

Одна из ключевых механик workflow - сохранение состояния. Пользователь может закрыть приложение, вернуться через день или неделю и продолжить ровно с того шага, где остановился. При возвращении система показывает короткое саммари: “Вы остановились на шаге X. Следующий шаг - Y” и даёт кнопку “Продолжить”. Это кажется простым, но именно это превращает сложный процесс в ощущение контроля и предсказуемости.

Почему это уменьшает нагрузку на поддержку и повышает доверие

Когда процессы построены как workflows, поддержка перестаёт “разруливать хаос” и начинает управлять понятными кейсами. Становится меньше повторных обращений “что со статусом”, меньше ошибок, меньше потерь документов, меньше разночтений между оператором и системой. Пользователь получает опыт, где всё прозрачно: процесс живой, он движется, и всегда есть следующий шаг. Это повышает доверие и делает сервис масштабируемым без раздувания штата.

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

11. DARCA Academy (обучение как часть сервиса)

Academy - это слой знаний и действий: он обучает пользователей, снижает нагрузку на поддержку и повышает конверсию онбординга через сценарии и кнопки прямо в чате.

Info

Лучший сервис - это не только “быстро отвечать”, а снижать количество ошибок и вопросов, а если они возникают - доводить до результата через контекст и действия.

Мы строим DARCA Academy как полноценную часть сервиса, потому что в финансовом продукте “поддержка” начинается задолго до обращения к оператору. Большая часть раздражения и потери доверия рождается не в момент, когда пользователь написал в чат, а раньше: когда он не понимает, что делать, делает ошибку, путается в интерфейсе, не видит статус, боится нажать “не туда” и откладывает использование продукта. Поэтому Academy для нас - это не “раздел со статьями”, а живой слой знаний, встроенный в продукт и чат, который учит, направляет и помогает завершать действия.

Academy не объясняет, а сопровождает и доводит до результата

Классические базы знаний часто бесполезны, потому что они дают текст, но не дают следующего шага. В DARCA Academy устроена иначе: любой материал не заканчивается “прочитайте и разберитесь”, он заканчивается понятным действием. Если урок объясняет, как подключить модуль, рядом должна быть кнопка “Подключить модуль”. Если урок про верификацию, рядом должна быть кнопка “Начать KYC”, “Загрузить документ”, “Проверить статус”. Таким образом знания становятся частью интерфейса, а не отдельным архивом.

Warning

Правило: знания без действий - это не сервис. Academy всегда связывается с кнопками, deep-links и сценариями.

Какие форматы нам нужны и зачем их несколько

Academy покрывает разные уровни “готовности” пользователя. Кому-то нужна короткая подсказка на 30 секунд, кому-то - пошаговый сценарий, а кому-то - мини-курс, чтобы почувствовать уверенность. Поэтому мы используем несколько форматов, но все они подчиняются одному принципу: быстро дать понимание и привести к следующему шагу. Это могут быть короткие инструкции, guided flows, чек-листы, мини-уроки и курсы, а также FAQ, который в DARCA становится не просто “вопрос-ответ”, а “вопрос-ответ + действие”. При этом любой технический или процессный термин остаётся прозрачным и объяснимым, а ссылки и формулировки опираются на понятные стандарты, например FAQ и Deep_linking.

AI использует Academy как официальный корпус знаний

Чтобы ответы поддержки были едиными и предсказуемыми, AI не должен “объяснять как получится”. Он должен опираться на официальный корпус знаний. Поэтому материалы Academy становятся для AI источником истины: ассистент может дать короткую выдержку, прикрепить нужный урок, провести пользователя по шагам прямо в чате и, что важно, вывести кнопки действий, чтобы человек не терялся в тексте. Это повышает точность, снижает количество ошибок и делает опыт одинаковым независимо от времени суток и языка.

Note

Academy превращает ответы AI из “текста” в сценарии с понятными действиями и статусами.

Контекстное обучение: “учим ровно тогда, когда это нужно”

Мы не заставляем пользователя “идти учиться отдельно”. Academy работает контекстно. Если пользователь застрял на шаге верификации, чат предложит соответствующий мини-урок и кнопку “продолжить”. Если человек делает обмен впервые, система объяснит, как формируется итог, и даст кнопку “посмотреть детали операции”. Если пользователь пишет “как подключить бизнес-функции”, AI не бросит ссылку на статью, а проведёт по сценарию с чек-листом и действиями. Именно так обучение становится частью сервиса, а не “документацией ради документации”.

Почему это снижает нагрузку на поддержку и повышает конверсию

Когда продукт объясняет себя сам и ведёт пользователя по маршруту, резко падает количество обращений “где это найти” и “как это сделать”. Оператор подключается только там, где нужна ответственность, нестандартное решение или высокий риск. Кроме того, Academy усиливает онбординг: шаги становятся понятными, статусы прозрачными, требования к документам объясняются заранее, ошибки исправляются через кнопку “исправить” вместо бесконечной переписки. Это уменьшает “брошенные регистрации” и повышает завершение ключевых сценариев, включая Know_your_customer и процессы, связанные с Anti-money_laundering.

Academy как инструмент доверия, а не только “обучения”

Пользователь доверяет сервису, когда понимает, что происходит, почему так, какие у него есть варианты и что он контролирует ситуацию. Academy делает продукт объяснимым и предсказуемым, а значит повышает доверие и удержание. Это особенно важно в крипто- и финтех-продуктах, где страх ошибки часто сильнее интереса к возможностям.

Как Academy остаётся актуальной

Чтобы Academy не превратилась в “архив статей”, мы управляем ей как продуктом: материалы имеют версии, связаны с действиями и сценариями, а приоритеты обновлений определяются данными. Supervisor AI фиксирует топ повторяющихся вопросов и точки, где пользователи чаще всего “застревают”, после чего мы обновляем уроки, добавляем новые сценарии и улучшаем интерфейс. Так Academy становится живым механизмом улучшения сервиса, который усиливает AI, снижает нагрузку на команду и делает опыт пользователя всё более понятным.

Question

Как сделать так, чтобы знания не устаревали?

Управлять Academy как продуктом: версии, связь с кнопками и сценариями, приоритизация обновлений по данным поддержки и поведения пользователей.

В итоге DARCA Academy закрывает три ключевые цели одновременно: снижает количество ошибок и вопросов, ускоряет поддержку через готовые сценарии и повышает доверие, потому что продукт становится понятным и управляемым на каждом шаге.

12. Universal Assistant (любой вопрос) + встроенные сценарии

Чат DARCA становится универсальным интерфейсом: отвечает на любые вопросы, но при запросах про продукт всегда переводит диалог в конкретные действия через статусы, кейсы и кнопки.

Tip

Мы превращаем чат из “места, куда пишут когда плохо” в универсальный интерфейс, к которому пользователь привыкает обращаться ежедневно.

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

Поэтому мы вводим модуль Universal Assistant: пользователь может обратиться по любому вопросу - от банковского до повседневного. При этом ассистент всегда умеет переводить разговор в “действие”, если вопрос связан с DARCA.

---

Режимы: вопросы про DARCA и вопросы “обо всём”

Чтобы универсальность не превращалась в хаос, мы разделяем работу ассистента на два логических режима (для пользователя это выглядит как один чат, но внутри система понимает контекст).

Режим DARCA

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

Режим Universal

Сюда относятся общие знания (например “когда родился Клинтон”), погода, справочные данные и объяснения любых тем (финансы, технологии, путешествия, бытовые вопросы и т.д.). Это делается для двух эффектов: пользователь привыкает, что “DARCA всегда рядом и помогает”, а чат становится естественным интерфейсом, а не “местом, куда пишут только когда плохо”.

Note

“Universal” нужен не ради “болтовни”: он создаёт привычку пользоваться чатом каждый день, а значит повышает удержание и снижает число ошибок в продукте.

---

Встраивание в чат: команда → ответ → кнопки и действия

Ключевой принцип универсального ассистента: если вопрос связан с продуктом или финансами пользователя, ассистент должен переводить ответ в конкретное действие.

Как ассистент понимает, что вопрос “про продукт”

Есть маркеры, по которым система распознаёт продуктовый контекст: упоминание транзакции, суммы, даты, магазина; фразы “почему не прошёл перевод”, “где деньги”, “почему удержали”; вопросы “как подключить модуль”, “как сделать обмен”; команды “покажи баланс”, “покажи портфель”.

В этих случаях ассистент не ограничивается текстом. Он прикрепляет к ответу статус или объект (операция или кейс) и даёт кнопки “Открыть”, “Проверить”, “Сформировать”, “Подтвердить”, “Продолжить”.

Примеры поведения

• Пользователь: “Где мой перевод?”
  Ассистент: кратко объясняет ситуацию, предлагает “Открыть статус операции” и даёт возможность “Создать кейс, если задержка”.

• Пользователь: “Какая погода в Тбилиси завтра?”
  Ассистент: отвечает в универсальном режиме. Если пользователь добавит “напомни взять зонт утром” - ассистент создаёт задачу (Autopilot).

• Пользователь: “Когда родился Клинтон?”
  Ассистент: отвечает в универсальном режиме. Если пользователь говорит “запомни эту дату как…” - создаёт событие по команде пользователя.

---

Контроль качества и предотвращение ошибок в фактах

Universal Assistant должен быть не только полезным, но и качественным, особенно в фактах.

Проверка фактов в универсальных вопросах

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

Внутренняя “истина” для вопросов про DARCA

Для вопросов про продукт, статусы и процессы ассистент отвечает на основе базы знаний (Academy/KB), статусов и данных платформы, кейсов и workflow. Это исключает ситуацию “ассистент сказал одно, система делает другое”.

Warning

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

---

Universal Assistant как инструмент удержания и сервиса

Если человек использует чат только в проблеме - чат ассоциируется с негативом. Если человек использует чат ежедневно (вопросы, задачи, портфель, напоминания) - чат становится “домом”.

Чем чаще пользователь общается с ассистентом, тем быстрее он понимает продукт, тем меньше он ошибается и тем меньше у него стрессовых ситуаций. А сложные процессы (верификация, KYC, онбординг, документы) легче проходить, когда рядом ассистент, который объясняет, показывает статус и даёт кнопки.

---

Связка Universal Assistant с Academy и Support Core

Universal Assistant не существует отдельно. Если вопрос “как сделать” - ассистент использует Academy (урок или сценарий) и даёт кнопки действия. Если вопрос “проблема” - ассистент создаёт кейс в Support Core, показывает статус и следующий шаг. Если вопрос повторяется часто - Supervisor AI фиксирует это и запускает улучшение продукта и базы знаний.

Так универсальный ассистент становится частью нашей системы лучшего сервиса, а не “болталкой ради болталки”.

13. Personal Finance Autopilot - напоминания, поиск по транзакциям, задачи

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

Example

Вместо тысяч одинаковых обращений “я забыл оплатить” или “найдите платеж” - Autopilot делает это частью продукта и снижает стресс, ошибки и нагрузку на поддержку.

Мы хотим, чтобы DARCA помогал пользователю не только в момент, когда “что-то пошло не так”, а раньше - в точке, где проблема ещё не произошла. Это напрямую повышает качество сервиса: чем больше мы предотвращаем забытые платежи, путаницу в истории операций и потерю контекста, тем меньше негативных обращений, тем выше доверие и удержание.

Autopilot - это модуль, который использует наш AI и доступ к данным пользователя, чтобы распознавать паттерны расходов и платежей, напоминать и предлагать действия, отвечать на вопросы по истории транзакций, выполнять задачи по расписанию (дайджесты, курсы активов и т.д.) и превращать важные события в удобные “метки” и напоминания.

---

Умные напоминания по распознанным паттернам транзакций

Один из самых частых источников раздражения - регулярные платежи: аренда, связь, коммуналка, подписки. Autopilot строит “карту регулярности” и помогает пользователю без ручной настройки каждого напоминания.

Как Autopilot понимает, что платёж регулярный

Мы определяем регулярность на основе сигналов:

• повторяющийся получатель/мерчант
• близкая сумма или диапазон
• периодичность (месяц/неделя/квартал)
• похожее назначение
• повторяющиеся категории (аренда, коммуналка, связь, подписки)

На основе этих сигналов Autopilot формирует “кандидата на регулярный платёж” и дальше действует по правилам:

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

Так мы избегаем лишнего шума, но сохраняем максимальную пользу.

Как выглядит напоминание

Напоминание - это не просто “текст”. Это карточка с кнопками:

• “Оплатить сейчас”
• “Напомнить завтра / через 3 дня”
• “Изменить дату напоминания”
• “Отключить напоминания по этому платежу”
• “Это не регулярный платёж” (чтобы автопилот не ошибался дальше)

Если платёж требует критичного действия - кнопка ведёт в приложение, пользователь подтверждает оплату там.

Напоминания по приближению даты

Если мы видим, что аренда всегда платится, например, 1-5 числа:

• мы напоминаем заранее (например, за 2 дня)
• при этом учитываем поведение пользователя (если он всегда платит 3-го - подстраиваемся)

---

Поиск по транзакциям “человеческим языком”

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

Tip

Natural language поиск в финансах снижает фрустрацию и экономит время: пользователь задаёт вопрос как обычно, а система сама строит фильтры.

Примеры запросов пользователя

• “Месяц назад я покупал цветы, напомни дату”
• “Сколько я потратил на такси за прошлую неделю?”
• “Найди перевод, где было 300 долларов, кажется, в октябре”
• “Покажи все платежи за квартиру за последние 6 месяцев”
• “Когда я в последний раз платил за мобильную связь?”

Как мы это решаем

Autopilot:

• понимает смысл запроса
• фильтрует транзакции по времени/сумме/категории/мерчанту
• выдаёт результат:
  • дата
  • сумма
  • получатель
  • ссылка на транзакцию
  • и, если нужно, кнопка “показать детали”

Расширение результата в действие

Если пользователь спрашивает “напомни дату”, мы можем сразу предложить:

• “Добавить в события”
• “Поставить напоминание на год вперёд”
• “Сохранить как метку”

Это превращает “поиск” в полезную автоматизацию.

---

Личные события и “память” пользователя

Пользователи часто связывают траты и платежи с событиями жизни. Мы превращаем это в продуктовую ценность: пользователь сам придаёт смысл транзакциям, а Autopilot помогает сохранить этот смысл и возвращаться к нему.

Пример: “это был день первого свидания”

Пользователь: “Месяц назад я покупал цветы, найди дату. Запомни её как день первого свидания.”

Autopilot делает:

• находит транзакцию
• вытаскивает дату
• создаёт событие “Первое свидание”
• предлагает варианты:
  • “Напоминать каждый год”
  • “Напомнить за неделю до даты”
  • “Добавить заметку”
  • “Привязать фото/место” (если нужно)

События как часть чата

События становятся доступными через чат:

• “какая дата первого свидания?”
• “когда я покупал кольцо?”
• “когда была первая оплата аренды?” и т.д.

---

Автоматизации по расписанию: дайджесты, курсы, отчёты, уведомления

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

Пользователь задаёт задания в чате

Пользователь может прямо написать:

• “Отправляй мне курсы всех криптовалют в моём портфеле каждое утро”
• “Каждый понедельник присылай расходы за неделю”
• “Каждый день в 21:00 показывай баланс и изменения”
• “Раз в месяц присылай отчёт по подпискам”
• “Если курс актива упал на X% - уведомь”

Autopilot превращает это в задачу:

• сохраняет расписание
• источник данных (портфель, транзакции)
• формат сообщения
• канал доставки (in-app / мессенджер, если допустимо)

Дайджесты должны быть короткими и полезными

Мы не делаем “простыню текста”. Мы делаем карточки:

• “портфель: изменения”
• “основные расходы”
• “ожидаемые платежи”
• “подозрительные события” и кнопки “смотреть подробнее”.

---

Центр автоматизаций: управление задачами и историей выполнения

Если у пользователя появляется много задач (“каждое утро”, “каждый месяц”, “напомни”), ему нужен контроль. Поэтому в приложении появляется раздел:

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

Правило: у пользователя всегда есть управление и прозрачность - что делает автопилот и когда.

---

Как Autopilot снижает нагрузку на поддержку и повышает сервис

Autopilot убирает огромный класс обращений:

• “я забыл оплатить”
• “я не понимаю, когда платил”
• “найдите платеж”
• “почему списалось”
• “где мой документ/выписка”
• “напомните мне”

И главное - он превращает DARCA в привычный ежедневный инструмент, а не приложение “на случай проблемы”. А это самое сильное, что можно сделать для удержания и доверия.

14. Операционная модель: маленькая команда, которой можно доверять

Поддержка DARCA масштабируется глобально за счет AI, строгих регламентов и on-call для критичных кейсов, сохраняя скорость, безопасность и качество без огромного штата.

Info

Мы строим поддержку 24/7/365 и на всех языках, но без “армии операторов”: масштаб дает AI, а доверие и ответственность держит маленькая команда.

Мы проектируем поддержку как систему, а не как “колл-центр”. В классических банках качество сервиса часто упирается в размер штата, смены, очереди, человеческий фактор и неизбежную разницу в уровне операторов. В DARCA мы делаем иначе: скорость и доступность обеспечивает AI-first контур, а сложные и критичные ситуации решает небольшая, хорошо обученная и полностью контролируемая команда. Такой подход позволяет одновременно держать качество, безопасность и экономику масштабирования.

AI-first линия: мгновенный ответ, единый стандарт, любой язык

Первый контакт в поддержке всегда должен быть быстрым, а ответы - одинаковыми и предсказуемыми. Поэтому у нас первый уровень построен вокруг AI. Он закрывает типовой поток: объясняет функции, помогает найти нужный экран, показывает статусы операций, ведет по сценариям онбординга, прикрепляет материалы Academy, выполняет маршрутизацию и мгновенно переключается на язык пользователя. Важно, что AI отвечает не “как получится”, а на основе базы знаний и внутренних сценариев, чтобы сервис не зависел от времени суток и случайного “качества смены”.

Note

AI даёт масштаб, но не получает полномочий “делать риск”. Любые критичные действия остаются за пользователем через подтверждение в приложении.

Маленькая команда L2/L3: решают сложное, а не “объясняют очевидное”

Там, где нужна ответственность, нестандартное решение или человеческое участие, подключается второй уровень - команда экспертов. Их задача - не пересказывать инструкции, а доводить кейсы до результата. А третий уровень - узкие специалисты, которые подключаются точечно: сложные расследования, редкие инциденты, тонкие комплаенс-ситуации, критические ошибки. Мы сознательно не растим “массовку”, потому что массовка неизбежно увеличивает ошибки и риски. Вместо этого мы строим “спецназ” поддержки, который можно быстро обучать, контролировать и которому можно доверять.

24/7 без огромной ночной смены: on-call только для Sev-1

Круглосуточность обычно означает большие смены и высокие расходы. Мы достигаем 24/7 по другой логике: AI всегда присутствует и закрывает основную часть обращений, а для критичных кейсов работает on-call. Это значит, что мы будим человека только тогда, когда система автоматически распознала действительно высокий приоритет, а не потому что у пользователя нет ответа “сейчас”. При этом AI и платформа сами понимают, что считать критичным (Sev-1), кому эскалировать, какие данные приложить к кейсу и какой следующий шаг дать пользователю, чтобы он не сидел в неопределённости.

Tip

Пользователь не должен “выбивать” приоритет. В критике приоритет выдаётся автоматически, а коммуникация всегда остаётся прозрачной через статусы и следующий шаг.

Полномочия без риска: оператор помогает, но не может “сломать безопасность”

Наша модель строится на жёстком разграничении. Оператор может помогать, ускорять и сопровождать: запрашивать документы, выдавать справки, разъяснять статус, отправлять пользователю правильные deep-links и кнопки. Но любые действия, которые создают финансовый, юридический или репутационный риск, не делаются “вручную из чата”. Они выполняются только через действие пользователя в приложении, подтверждение, step-up проверки и аудит. Это защищает одновременно и пользователя, и нас: исключается человеческая ошибка, злоупотребление и “соц-инженерия через поддержку”.

Playbooks и чек-листы: превращаем редкие ситуации в управляемые процессы

Чтобы маленькая команда была сильной, решения должны быть стандартизированы. Мы используем playbooks - регламенты и чек-листы по ключевым типам кейсов. Каждый playbook описывает признаки проблемы, быстрый триаж, пошаговое решение, правила эскалации и то, какие кнопки/действия дать пользователю. Это превращает сложные и редкие случаи из “импровизации” в предсказуемый процесс, который одинаково хорошо работает независимо от того, кто открыл кейс.

Warning

Любая поддержка без регламентов рано или поздно становится лотереей. Playbooks делают сервис воспроизводимым и защищают репутацию.

Контроль качества и обучение: AI-ко-пилот и Supervisor AI

Мы ускоряем работу команды двумя слоями. Первый - AI-ко-пилот, который подсказывает оператору ответы, шаги и нужные материалы, сокращая время решения и снижая риск ошибки. Второй - Supervisor AI, который делает саммари диалогов, оценивает качество, выявляет повторяющиеся проблемы и указывает, где нужно улучшить playbooks, Academy или продукт. В результате поддержка становится самонастраивающейся системой: чем больше она работает, тем меньше ошибок и тем выше скорость.

Почему эта модель экономически сильнее и ощущается премиальнее

Эта операционная модель делает сервис “премиальным” не за счет дороговизны, а за счет архитектуры. AI закрывает массовое и языки, небольшая команда решает сложное и критичное, 24/7 достигается on-call, процессы стандартизированы, а качество контролируется автоматически. В итоге пользователь получает быстрый ответ, ясный статус и следующий шаг, а мы получаем поддержку, которая масштабируется глобально без взрыва затрат и без компромисса по безопасности.

15. Метрики, SLA и контроль качества

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

Info

Лучший сервис - это не “кажется, что стало лучше”, а измеримая система, где в любой момент видно качество, скорость и причины недовольства.

Лучший сервис - это не “кажется, что стало лучше”, а измеримая система, где мы в любой момент видим:

• что происходит с качеством
• где появляются проблемы
• насколько эффективно работает AI
• насколько быстро решаются кейсы
• где пользователи недовольны и почему

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

Note

Метрики для нас - это не отчёт “для галочки”, а система управления: видим - объясняем - исправляем - подтверждаем улучшение в данных.

Как это работает на практике

Мы собираем показатели в единый контур контроля качества: по каналам, категориям кейсов, языкам, регионам и продуктовым зонам. Важно, что мы оцениваем не только “сколько отвечали”, но и “чем закончился кейс” - решением, повторным обращением, эскалацией, задержкой или недовольством.

Ключевой смысл: если где-то “вспухла” нагрузка или упало качество, система должна показать это быстро и точно - с привязкой к причинам и типам кейсов. Тогда улучшения делаются адресно: продуктом, базой знаний, сценариями, правилами риска, или изменениями в работе оператора и AI.

16. Архитектура сервиса поддержки

Поддержка в DARCA - часть архитектуры платформы: она растёт вместе с продуктом, не ломает ядро и масштабируется через модульный подход и наблюдаемость.

Info

Мы строим Support не как “отдельный отдел”, а как архитектурный слой платформы, чтобы масштабирование не превращалось в хаос.

Мы строим клиентский сервис не как “отдельный отдел”, а как часть архитектуры платформы DARCA. Это критично, потому что:

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

Поэтому архитектура сервиса у нас строится по принципу Core + Modules: есть стабильное ядро, и есть подключаемые модули, которые расширяют функциональность.

---

Support как default-модуль платформы + расширения как подключаемые модули

Базовый слой, который есть у всех

У каждого пользователя всегда включён базовый слой сервиса:

• in-app чат (доступ в 1 жест),
• создание кейсов и статусы,
• базовые сценарии поддержки,
• безопасность support-канала (no-calls, подтверждение критичного),
• базовый AI (ответы + маршрутизация + кнопки).

Это “default”: без него продукт просто не существует.

Note

Базовый слой - это минимально достаточная поддержка, которая всегда доступна и всегда одинакова по качеству, независимо от региона и времени суток.

Расширения - по желанию пользователя

Дальше функционал наращивается модулями:

• DARCA Academy (обучение, сценарии, гайды)
• Universal Assistant (любой вопрос)
• Personal Finance Autopilot (напоминания, задачи, поиск по транзакциям)
• Messenger Module (эволюция чата в мессенджер с фин-функциями)
• Бизнес-модули (корпоративные сценарии поддержки и документооборота)
• Инструменты безопасности (расширенные режимы защиты)

Принцип: пользователь подключает только то, что ему реально нужно. Это снижает перегруз интерфейса и упрощает масштабирование продукта.

---

Core + Modules: как мы добавляем новые возможности без “ломки ядра”

Support Core (ядро)

Это неизменяемое ядро, которое обеспечивает фундамент:

• Case Management (кейсы, статусы, SLA)
• Омниканал (единый таймлайн)
• Документооборот в чате
• Аудит и журнал действий
• Политики безопасности (критичное только через подтверждение)
• Интеграции с продуктовым ядром (статусы операций, события)

Support Core не должен зависеть от UI или конкретных мессенджеров. Он должен быть стабильным и расширяемым.

Experience Layer (слой интерфейсов)

Это “витрины” одного и того же ядра:

• in-app чат,
• каналы в мессенджерах,
• (в будущем) полноценный мессенджер внутри приложения,
• админ-панель операторов.

Любой новый канал не требует переписывать ядро - он просто подключается к нему.

AI Layer (интеллектуальный слой)

AI подключён к ядру и к базе знаний, и работает на всех уровнях:

• пользовательский ассистент,
• ко-пилот оператора,
• Supervisor AI.

AI - тоже модульный: мы можем улучшать модели, менять компоненты, добавлять новые сценарии, не ломая основу.

Modules Layer (подключаемые продукты)

Каждый модуль:

• имеет свою функциональность,
• свои сценарии,
• свои UI-элементы,
• но опирается на общие сервисы ядра:
  • кейсы,
  • статусы,
  • кнопки действий,
  • подтверждения,
  • документооборот,
  • события.

Итог: новый модуль = новая ценность без переписывания платформы.

---

Интеграции: payments/risk/KYC/docs/ledger/notifications

Поддержка становится по-настоящему эффективной только тогда, когда она “видит” продукт и может сопровождать действия пользователя по статусам, документам и рискам, а не просто переписываться текстом. Поэтому мы строим интеграции как часть Support Core.

Payments / Transfers / Exchange

• статусы операций в реальном времени,
• возможность открыть транзакцию из чата,
• кнопки “проверить статус”, “создать кейс”.

Risk & Anti-fraud

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

KYC / Compliance workflows

• прозрачные статусы проверок,
• запрос документов прямо в чате,
• продолжение процесса “с того же шага”.

Docs & Sign

• выписки, справки, подтверждения,
• подписи (только через подтверждение пользователем),
• хранение статусов и истории выдачи.

Ledger / Portfolio

• контекст портфеля и активов для запросов пользователя,
• дайджесты и напоминания Autopilot,
• поиск по транзакциям.

Notifications

• уведомления о статусах кейсов,
• уведомления о статусах операций,
• напоминания Autopilot.

---

Надёжность и наблюдаемость поддержки (traces/metrics/logs)

Наблюдаемость (observability)

Мы строим систему так, чтобы видеть:

• что именно происходит с обращениями,
• где падает скорость,
• где выросли ошибки,
• где AI стал хуже справляться.

Нам нужны:

• логи диалогов (внутренние),
• события кейсов,
• метрики SLA,
• метрики AI,
• трассировка ключевых сценариев (workflow, выдача документов, подтверждения).

Tip

Observability в поддержке - это способ держать качество предсказуемым: мы видим деградацию раньше, чем её массово почувствуют пользователи.

Устойчивость к нагрузке

Поддержка должна выдерживать пики:

• массовые кампании,
• рост пользователей,
• волны обращений при инцидентах.

Для этого:

• AI снимает нагрузку с людей,
• кейсы и статусы работают как система очередей,
• критичное (Sev-1) имеет отдельный маршрут.

Деградация без “обвала”

Если часть систем недоступна, поддержка не должна “умирать”. Например:

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

---

Мы учитываем, что технологии меняются быстро - поэтому архитектура должна быть гибкой

Мы заранее проектируем DARCA так, чтобы:

• можно было заменять компоненты AI без переписывания Support Core,
• можно было подключать новые каналы общения,
• можно было добавлять новые модули,
• можно было быстро выпускать новые продукты.

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

17. Безопасность сервиса и контроль риска

Поддержка - это attack surface финтеха, поэтому мы проектируем её как защищённый контур: правила, ограничения, подтверждения, аудит и риск-сценарии.

Warning

Клиентский сервис - одна из самых атакуемых зон в финтехе: мошенникам выгодно обходить защиты через эмоции и социальную инженерию. У нас поддержка - не слабое звено, а дополнительный слой защиты.

Клиентский сервис - одна из самых атакуемых зон в финтехе, потому что мошенникам выгодно “обойти” продуктовые защиты через человека, эмоции и социальную инженерию. Мы строим поддержку так, чтобы она была не слабым звеном, а наоборот - дополнительным слоем защиты. Для этого безопасность сервиса у нас - это не “инструкция оператору”, а архитектура: правила, ограничения, подтверждения, аудит, риск-сценарии и постоянный контроль.

---

17.1. Политика No Calls как базовая защита от социальной инженерии

Info

Мы убираем целый класс атак одним правилом: мы не звоним и не принимаем звонки. Любой звонок “от DARCA” - это мошенничество.

17.1.1. Почему это критично

Телефонный звонок:

• легко подделать
• легко использовать для давления (“срочно”, “вас взламывают”, “назовите код”)
• сложно доказуем в расследовании
• не имеет встроенного статуса/кейса и аудит-трейла как цифровой контур

Поэтому мы фиксируем правило:

• мы не звоним и не принимаем звонки
• любой звонок “от DARCA” = мошенничество

Это фундамент, который убирает огромный класс атак.

17.1.2. Как мы закрепляем это в продукте

• предупреждение в настройках и безопасности
• блок в онбординге
• сценарий в чате “мне звонили от DARCA” - защитные действия
• урок в Academy по мошенничеству

---

17.2. Разделение полномочий: оператор не может выполнить критичное действие

Note

Поддержка может объяснить и подготовить действие, но не может “выполнить критичное” вместо пользователя. Это снижает риск ошибок и давления на оператора.

Мы специально проектируем поддержку так, чтобы даже хороший оператор не мог “случайно” ошибиться, а мошенник не мог “уговорить” оператора сделать опасное.

17.2.1. Критичные действия: всегда подтверждает пользователь

Любое действие, которое связано с:

• переводами
• подтверждениями
• подписями
• изменениями безопасности
• операциями с высоким риском

выполняется только через кнопку и подтверждение пользователя внутри приложения.

Оператор и AI:

• готовят действие
• объясняют
• дают кнопку

но выполнение всегда идёт через подтверждение пользователя.

17.2.2. Step-up подтверждение для повышенного риска

Если риск высокий (новое устройство, нетипичное поведение, подозрение на фрод), мы усиливаем подтверждение:

• дополнительные шаги подтверждения
• ограничения по времени действия кнопки
• повторная проверка контекста

Смысл: даже если кто-то получил доступ к переписке, он не сможет “сделать действие”.

---

17.3. Поддержка как часть risk-контуров: защитные сценарии в один клик

Tip

Безопасность - это не памятка, а сценарии. В критический момент важнее всего быстрые шаги, которые снижают риск сразу.

Мы делаем безопасность не “памяткой”, а кнопками.

17.3.1. Основные защитные сценарии в чате

В чате всегда доступны быстрые кнопки:

• “Подозрение на взлом”
• “Мне звонили от DARCA”
• “Я не узнаю операцию”
• “Подозрительная активность”
• “Проблема с доступом”

17.3.2. Что делает защитный сценарий

В зависимости от ситуации система:

• фиксирует событие в кейсе
• показывает последние входы и устройства
• предлагает завершить все сессии (кроме текущей) - по подтверждению пользователя
• предлагает усилить подтверждения
• предлагает временно ограничить рискованные операции - по подтверждению пользователя
• создаёт Sev-1 кейс и подключает on-call специалиста при необходимости

Принцип: защитный сценарий должен снижать риск немедленно, а не “ждать оператора”.

---

17.4. Защита от подмены поддержки в мессенджерах

Warning

Внешние мессенджеры - удобный канал, но они же дают риск подмены “официального аккаунта”. Мы закрываем этот риск через верификацию и привязку внутри приложения.

Раз мы используем внешние мессенджеры, мы должны исключить ситуацию “пользователь пишет фейковому аккаунту”.

17.4.1. Официальные каналы подтверждаются внутри приложения

В приложении есть раздел:

• “Официальные каналы DARCA”
• точные аккаунты, ID, названия
• инструкции по проверке

17.4.2. Привязка мессенджера к аккаунту

Чтобы пользователь получал полноценную поддержку в мессенджере:

• он подтверждает связь через приложение
• после чего мы уверены, что канал принадлежит этому пользователю

17.4.3. Любые критичные шаги всё равно уводим в приложение

Даже если пользователь общается в Telegram:

• критичное действие не делается там
• мы даём кнопку “Продолжить в приложении”

---

17.5. Антифрод-триггеры в поддержке

Info

Поддержка - это ранний датчик риска: в тексте и поведении часто видны сигналы атаки раньше, чем наступит ущерб. Мы превращаем эти сигналы в автоматические реакции.

17.5.1. Сигналы риска в тексте и поведении

Примеры:

• “мне звонили”, “сказали назвать код”, “служба безопасности”
• “срочно”, “помогите отменить”
• “я потерял телефон”
• нетипичные запросы на изменение настроек
• резкие изменения поведения и активности

17.5.2. Реакции системы

• перевод кейса в приоритетный режим
• включение защитных сценариев
• запрос дополнительных подтверждений
• ограничение “опасных” кнопок до прохождения step-up
• подключение оператора/специалиста

---

17.6. Аудит и доказуемость: кто что сделал, почему и на каком основании

Note

Мы делаем поддержку расследуемой. Это защищает и пользователя, и компанию, и операторов - потому что любые действия имеют прозрачный след.

Поддержка должна быть расследуемой. Поэтому мы фиксируем:

• все сообщения
• все действия
• все статусы
• все выданные кнопки
• все подтверждения пользователя
• все решения оператора

Это защищает:

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

---

17.7. Контроль качества и безопасность AI

Danger

AI не должен становиться источником риска. Мы ограничиваем его правилами и контролем так же строго, как любую другую часть финтех-системы.

AI в поддержке - мощный инструмент, но мы не допускаем, чтобы он:

• предлагал опасные действия
• нарушал политику подтверждений
• уводил пользователя во внешние каналы для критичного

Мы фиксируем правила:

• AI никогда не просит коды, seed, пароли
• AI никогда не “принимает” критичные подтверждения в чате
• AI всегда отправляет критичные действия на подтверждение в приложении
• Supervisor AI и внутренние проверки отслеживают нарушения и блокируют рискованные шаблоны

---

17.8. Итог: поддержка усиливает безопасность, а не ослабляет её

Example

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

За счёт:

• отказа от звонков
• подтверждения критичного только пользователем
• защитных сценариев в один клик
• привязки мессенджеров
• риск-триггеров
• аудита и контроля качества

мы превращаем поддержку из “атакуемой точки” в реальный элемент защиты пользователя и платформы.

18. Будущее: Messenger Module и фин-функции прямо в чате

Чат DARCA эволюционирует от поддержки к полноценному Messenger Module, где финансовые договоренности превращаются в объекты со статусами, без потери контроля и безопасности.

Info

Мы проектируем чат DARCA так, чтобы он был не временным “окном поддержки”, а основой коммуникационного и финансового контура, который со временем может масштабироваться в полноценный мессенджер.

Почему мы идём к мессенджеру

У пользователей уже сформировалась привычка: важные действия и договоренности происходят в чатах. Но финансовые действия часто “оторваны” от общения, из-за чего появляются системные боли:

• договоренности есть, а перевод нужно делать “в другом месте”
• документы обсуждаются в мессенджере, а подписывать нужно “где-то ещё”
• долги и расчёты ведутся вручную
• подтверждения и статусы теряются

Именно поэтому мы развиваем чат так, чтобы финансовые сценарии были рядом с коммуникацией, а договоренности превращались в понятные объекты со статусами и прозрачной историей.

Note

Логика проста: если контекст и действие находятся рядом, снижается число ошибок, споров и “потерянных обещаний”.

Принцип безопасности остаётся тем же

Даже когда чат станет мессенджером с фин-функциями, мы не меняем базовую политику безопасности:

• любые операции с деньгами
• подписи
• критичные подтверждения

всегда проходят через подтверждение пользователем в продукте (внутри приложения) с нужным уровнем step-up проверки.

Warning

В переписке может появляться “карточка действия”, но критичное никогда не исполняется “словами в чате” - только через подтверждение пользователем внутри приложения.

Что именно появится в Messenger Module

Переводы в чате (P2P и внутри DARCA)

Пользователь сможет:

• отправить деньги прямо в диалоге (контакт, номер, юзернейм)
• приложить комментарий
• видеть статус перевода в виде карточки в переписке

Это убирает классическую боль “я перевёл, но где подтверждение и что по статусу”.

“Дать в долг” и расчёты в чате

В чате можно будет:

• создать карточку “долг”
• установить срок и сумму
• видеть статусы “создано / подтверждено / частично погашено / закрыто”
• получать напоминания

Важно: подтверждения - всегда через пользователя.

Документы и подписи прямо в переписке

Чат станет местом, где:

• обсуждают документ
• прикладывают версии
• подписывают (через подтверждение пользователя)
• получают статус “подписано / отклонено / требуется исправление”

Особенно важно для бизнеса и сделок.

Платежи и счета в чате

В чатах появляются “карточки счета” с действиями:

• “оплатить”
• “подтвердить”
• “разбить на части”
• “напомнить позже”
• “сформировать квитанцию/документ”

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

Почему мы можем это сделать без переписывания продукта

Мы уже строим фундамент правильно:

• Support Core (кейсы, статусы, аудит, документы)
• кнопки действий (deep-links, actions, confirms)
• workflow (процессы со статусами)
• AI Layer (ассистент, копилот, супервизор)

Messenger Module - это:

• новый интерфейс и новый тип “диалога” (peer-to-peer, группы)
• но на том же базовом контуре: действия, подтверждения, документооборот, аудит

Итог: мы расширяем платформу модулем, а не делаем “новую систему с нуля”.

Tip

Такой подход важен для масштаба: новые сценарии появляются как расширение, а не как “второй продукт”, который нужно заново поддерживать и защищать.

Как это влияет на сервис

Когда чат превращается в мессенджер:

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

Это делает клиентский сервис не “реактивным”, а частью ежедневной коммуникации и финансовой жизни пользователя.

Плавная эволюция без резких изменений

Мы не делаем “переворот интерфейса”. Мы делаем постепенное расширение:

1. чат поддержки с кнопками и документами (сейчас)
2. расширение действий (больше сценариев, больше документов, больше автоматизаций)
3. добавление фин-карточек в чате (инициирование)
4. полноценный Messenger Module как модуль для тех, кому он нужен

Принцип: пользователю не навязывается лишнее. Он подключает модуль, если ему это нужно.