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

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

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

Разбивка процесса обработки претензий

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

  • FNOL: первое уведомление об убытке — это момент, когда клиент регистрирует претензию у страховщика.
  • Обновления претензии: клиент ищет информацию о претензии или имеет дополнительную информацию, чтобы предоставить страховщику о претензии.
  • Анализ политики: обработчик претензий анализирует политику, чтобы понять применимое покрытие и исключения.
  • Обстоятельства претензии: обработчик претензии создает картину того, что произошло в инциденте, приведшем к претензии, определяя характеристики, важные с точки зрения страхования (например, ответственность).
  • Анализ документов: обработчик претензий проверяет документы, предоставленные страхователем.
  • Оценка убытков: обработчик претензий использует свои знания, инструменты или советы эксперта для получения оценки убытков.
  • Решение о покрытии: обработчик претензий применяет политику к обстоятельствам, чтобы решить, покрывается ли претензия.
  • Решение о мошенничестве: обработчик претензий запрашивает разъяснения у заявителя или передает подозрительные претензии в SIU.
  • Решение о разрешении: обработчик претензий применяет бизнес-политику и свое суждение, чтобы решить, какой тип предложения (предложений) предложить клиенту.

Интересно то, что все эти задачи — какими бы разнородными и сложными они ни были — входят в сферу ответственности группы по работе с претензиями. Во многих страховых компаниях один человек способен выполнить их все. Следовательно, мы можем думать об автоматизации претензий как о задаче создания обработчика претензий ИИ. Это выходит далеко за рамки роботизированной автоматизации процессов (RPA) или автоматизации одной задачи.

В этом определении обработчик претензий ИИ должен:

  1. Обеспечить эффективное взаимодействие с заказчиком.
  2. Поймите претензию.
  3. Принимать решения по претензиям.

Но эффективный обработчик требований ИИ также должен быть способен принимать то, что лучше всего можно определить как «процессное решение». И здесь рушатся RPA и статические бизнес-правила. ИИ должен быть в состоянии определить, когда у него нет нужных данных и информации, необходимых для продвижения претензии. Это то, что настоящий обработчик требований делает естественно, но это нетривиальная проблема при создании решения ИИ. В этой ситуации ИИ должен иметь возможность либо запросить дополнительную информацию (у клиента или другой стороны, участвующей в претензиях), либо направить претензию обработчику претензий. По сути, мы добавляем четвертое требование, которое должен выполнять обработчик претензий ИИ:

4. Уметь принимать процессные решения.

Итак, как это выглядит на практике? Давайте исследуем немного глубже.

Взаимодействие с заказчиком

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

Тем не менее, недостаточно просто создать интерфейс, соответствующий современным рекомендациям по взаимодействию с пользователем. Именно здесь в игру вступает искусственный интеллект, который поддерживает настоящую автоматизацию претензий. Например, подача заявки через Интернет и получение ответа через неделю о том, что вы загрузили неправильный документ, создает ужасный опыт. Правильный ИИ может мгновенно сказать вам, что была допущена ошибка, и как ее исправить, поддерживая процесс и обеспечивая удовлетворенность клиентов. Но, как мы уже подчеркивали, FNOL — это только начало взаимодействия с клиентом в связи с претензией.

Претензии к пониманию

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

Анализ политики

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

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

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

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

Здесь два разных метода могут поддерживать автоматизацию. Анализ документов позволяет извлечь стандартный набор обстоятельств из отчета об аварии, устраняя дублирование усилий, экономя время и снижая вероятность возникновения несоответствий. Добавление использования понимания естественного языка для анализа рассказа заявителя об аварии помогает избежать запроса той же информации к заявителю в другом месте позже в FNOL. Цель состоит в том, чтобы построить богатую модель обстоятельств с минимальным бременем, возложенным на заявителя.

Анализ документов

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

Анализ документов — это область, в которой обработчик претензий ИИ может сыграть решающую роль.

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

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

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

Оценка потерь

Несмотря на разнообразие способов оценки и возмещения убытков в разных направлениях бизнеса, по-прежнему существуют огромные возможности для применения ИИ для оптимизации результатов претензий. Системы могут использовать счета-фактуры от клиентов в качестве основы для оценки убытков — с оговоркой, что несоответствия должны быть в состоянии быть обнаружены и устранены в случае необходимости. Оценки могут быть основаны на известных отраслевых нормах или даже на информации из сторонних источников, таких как онлайн-списки. Наконец, оценка затрат с «низкой точностью» — например, автомобиль легко или сильно поврежден — может предоставить достаточно, чтобы знать, что делать дальше, без необходимости знать точную стоимость ремонта.

Претензионные решения

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

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

  1. Решение о покрытии — покрывается ли претензия?
  2. Решение о мошенничестве — имеет ли претензия обоснованность или существует высокая вероятность мошенничества?
  3. Решение о разрешении — как лучше всего разрешить претензию клиента?

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

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

Технологические решения

Хороший обработчик претензий следит за процессом. Хороший обработчик претензий знает, когда нужно выйти из процесса. Это особенно важно для обработчика требований ИИ, который в противном случае способен многократно и быстро совершать ошибки, не осознавая наличия проблемы.

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

Автоматизация претензий

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

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

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