AI-агент в середине клиентского сценария: Как я определяю есть ли у моих клиентов фин лицензия?
Мне для одной задачи важно проверять является ли пользователь сотрудником регулируемой организации - есть ли у его работодателя фин лицензия?
Как это происходит в эру до-AI? Делаешь на сайте форму - название компании, сайт, лицензия, регулятор. Дальше просишь прикрепить лицензию и стандартный комплект документации.
Нанимаешь сотрудника, он находит сайт регулятора, сверяет записи из лицензии с реестром, проверяет, что лицензия действующая. Регулятор редко публикует официальный сайт, поэтому у тебя есть телефон и ты можешь дальше делать с ним всё что угодно - например, попрактиковать свои знания французского.
Любой интернет-маркетолог скажет базовое правило - чем более бесшовный опыт клиента, тем больше шансов, что он не потеряется на пути к конверсии. Если ему для триалки надо будет у бухгалтерии выпрашивать копию паспорта директора, то нужно делать ну какой-то очень волшебный продукт. Может для компании с 50-тилетней историей - это норма, но стартапу не выжить.
Я упрощаю задачу до следующего:
1. Валидировать email-адрес (есть ли у заявителя действительно к нему доступ).
2. Найти официальный сайт организации и сравнить с доменом email'а заявителя.
3. Найти информацию о лицензии на сайте организации.
4. Найти кто официальный регулятор для данного типа организации в данной стране.
5. Проверить валидность лицензии на сайте регулятора. Сравнить все данные, которые даёт регулятор (адрес, домен и т.д.)
6. Проверить вторичные признаки: возраст домена, ip заявителя, предыдущий опыт с этой организацией и подсетью, global watchlists и т.д.
7. Дозапросить чего не хватило.
"Сайт" вызывает инстанс claude code прямо на том же сервере, который проводит эту проверку автономно и скорит пользователя. Если что-то насторожило, то уходит на ручное рассмотрение. Нужно ли говорить, что эта автоматизация в первой версии делается быстрее, чем я писал этот пост.
Дальше всё зависит от потребностей в глубине due diligence и фантазии - можно и позвонить, в том числе на языке страны.
Где это можно применять?
- Триалки - стоит ли одобрять или профиль компании не похож на целевого клиента?
- Приоритет в обслуживании - клиент нажал кнопку связаться/демо. давать ссылку на календарь фаундера, рядового продавца или ограничиться отпиской?
- Ценообразование - не хотите смущать богатых enterprise-клиентов дешевой ценой? (учтите только, что это не везде легально)
- Предпроверка документов - загрузи фин отчетность и я скажу можем ли мы дать тебе кредит (за скобками чувствительные данные)
- Обогащение данных в CRM - обычно не нужно делать real-time, но принцип схожий. Хотя здесь доступ к проприетарным данным обычно даст больше ценности чем шариться по сайту клиента.
____
Claude в облаке | Мастер-классы | Консультации
Мне для одной задачи важно проверять является ли пользователь сотрудником регулируемой организации - есть ли у его работодателя фин лицензия?
Как это происходит в эру до-AI? Делаешь на сайте форму - название компании, сайт, лицензия, регулятор. Дальше просишь прикрепить лицензию и стандартный комплект документации.
Нанимаешь сотрудника, он находит сайт регулятора, сверяет записи из лицензии с реестром, проверяет, что лицензия действующая. Регулятор редко публикует официальный сайт, поэтому у тебя есть телефон и ты можешь дальше делать с ним всё что угодно - например, попрактиковать свои знания французского.
Любой интернет-маркетолог скажет базовое правило - чем более бесшовный опыт клиента, тем больше шансов, что он не потеряется на пути к конверсии. Если ему для триалки надо будет у бухгалтерии выпрашивать копию паспорта директора, то нужно делать ну какой-то очень волшебный продукт. Может для компании с 50-тилетней историей - это норма, но стартапу не выжить.
Я упрощаю задачу до следующего:
1. Валидировать email-адрес (есть ли у заявителя действительно к нему доступ).
2. Найти официальный сайт организации и сравнить с доменом email'а заявителя.
3. Найти информацию о лицензии на сайте организации.
4. Найти кто официальный регулятор для данного типа организации в данной стране.
5. Проверить валидность лицензии на сайте регулятора. Сравнить все данные, которые даёт регулятор (адрес, домен и т.д.)
6. Проверить вторичные признаки: возраст домена, ip заявителя, предыдущий опыт с этой организацией и подсетью, global watchlists и т.д.
7. Дозапросить чего не хватило.
"Сайт" вызывает инстанс claude code прямо на том же сервере, который проводит эту проверку автономно и скорит пользователя. Если что-то насторожило, то уходит на ручное рассмотрение. Нужно ли говорить, что эта автоматизация в первой версии делается быстрее, чем я писал этот пост.
Дальше всё зависит от потребностей в глубине due diligence и фантазии - можно и позвонить, в том числе на языке страны.
Где это можно применять?
- Триалки - стоит ли одобрять или профиль компании не похож на целевого клиента?
- Приоритет в обслуживании - клиент нажал кнопку связаться/демо. давать ссылку на календарь фаундера, рядового продавца или ограничиться отпиской?
- Ценообразование - не хотите смущать богатых enterprise-клиентов дешевой ценой? (учтите только, что это не везде легально)
- Предпроверка документов - загрузи фин отчетность и я скажу можем ли мы дать тебе кредит (за скобками чувствительные данные)
- Обогащение данных в CRM - обычно не нужно делать real-time, но принцип схожий. Хотя здесь доступ к проприетарным данным обычно даст больше ценности чем шариться по сайту клиента.
____
Claude в облаке | Мастер-классы | Консультации