01

Проблемът: входящи запитвания, които чакат твърде дълго

Запитване пристига в неделя вечер или в 23:00 през делничен ден. Докато търговският екип го види в понедели сутрин, потенциалният клиент вече е написал на двама конкуренти. Проблемът не е липса на интерес от страна на екипа, а разликата между момента на запитването и момента на първия контакт.

Формулярите с 15 задължителни полета решават проблема частично — намаляват обема на запитванията, защото отблъскват част от хората, преди да се разберат намеренията им. AI агент, който веде кратък, насочен разговор веднага след постъпване на запитването, запазва скоростта на формуляра без неговата студенина.

02

Какво е AI агент за продажби — разлика от чатбот и формуляр

Обикновен чатбот отговаря на често задавани въпроси по фиксиран скрипт. Формулярът събира данни, но не реагира на отговорите. AI агент прави нещо средно: задава въпроси на естествен език, адаптира следващия въпрос според предходния отговор и записва резултата структурирано в CRM.

Разликата с човешки търговец е ясна и трябва да се комуникира така към клиентите: агентът квалифицира и насочва, но не договаря условия и не е оторизиран да поема ангажименти извън предварително зададени правила. Той е първа линия, не финален collocutor.

03

Входяща квалификация по ясни критерии

Класическият BANT модел (бюджет, авторитет, нужда, срок) остава работещ ориентир, адаптиран към естествен разговор, не към формуляр с чекбоксове. Агентът пита за конкретната задача на клиента, приблизителен мащаб, и дали вече има наличен бюджет или процес на одобрение.

Важно е агентът да не отказва автоматично лийдове, които не отговарят на критериите — той ги маркира с по-нисък приоритет и ги предава на CRM, за да реши човек дали си заслужават допълнително внимание. Автоматичен отказ без човешки преглед рискува да загуби нестандартни, но ценни възможности.

  • Каква конкретна задача или проблем клиентът иска да реши
  • Приблизителен мащаб — брой потребители, обем трафик, бройки продукция
  • Наличие на бюджет или процес на вътрешно одобрение
  • Времева рамка — спешно, в рамките на тримесечие, проучвателно
04

Discovery разговор: граници на разбирането на модела

Discovery не е анкета — то изисква да се улови контекст, който клиентът не е казал директно. Тук е честно да се признае граница: езиковият модел разпознава ключови думи и структура на изречението добре, но не улавя тон, недоверие или неизказани резерви така, както опитен търговец.

Затова discovery разговорът на агента трябва да е структуриран около 4-6 конкретни въпроса, а не да се опитва да имитира свободен консултативен разговор. Когато клиентът зададе въпрос извън обхвата (сложна техническа интеграция, нестандартни условия), правилният отговор на агента е признаване и предаване към човек, не опит за импровизиран отговор.

05

Връзка с CRM: запис без дублиране

Всеки отговор от разговора трябва да се запише директно в CRM през API — в структурирани полета, не само като свободен текст. Преди създаване на нов контакт, агентът проверява дали имейл или телефон вече съществуват в базата, за да не дублира запис на клиент, който вече е бил в pipeline преди месеци.

Ако дубликат се открие, правилното действие е актуализация на съществуващия запис с нова бележка за контакт, а не ново картичка — това пази историята на връзката с клиента непрекъсната. За основите на такава CRM структура вижте /crm-client-portali.

06

Асистирано скориране, не автоматично отхвърляне

Агентът може да предложи числов или категориен score (топъл/топъл-среден/студен) въз основа на отговорите от квалификацията. Score-ът е препоръка в CRM-а, видима за търговеца, не скрито решение, което филтрира кой лийд изобщо ще бъде видян от човек.

Причината да се пази човешкият преглед: качествени сигнали — репутация на компанията, лично познанство, стратегическо значение на клиента — рядко присъстват в структурираните данни от разговор и трябва да коригират автоматичния score.

07

Насочване към правилния търговец или екип

След квалификация, агентът насочва лийда според предварително зададени правила — по индустрия, по регион, по размер на сделката, по наличен капацитет на търговския екип. Routing логиката е детерминирана (if-then), не AI решение — защото трябва да е предвидима и лесна за одит, когато екипът пита „защо този лийд отиде при мен“.

AI частта свършва работата на разбиране и структуриране на отговорите; разпределението на готовите данни към правилния човек е класическа автоматизация, интегрирана с CRM — вижте /integratsii-avtomatizatsiya за модела на такава връзка.

08

Чернови за follow-up, не автоматично изпращане

Агентът може да подготви чернова на follow-up имейл — обобщение на разговора, предложена следваща стъпка, прикачени релевантни материали. Черновата се появява в CRM или имейл клиента на търговеца за преглед и изпращане, не излиза директно към клиента.

Този преглед не е формалност: човек добавя личен щрих, коригира тон, а при необходимост маха твърдения, които агентът е формулирал прекалено категорично. Директно автоматично изпращане на търговски имейл без преглед носи репутационен риск, несъразмерен на спестеното време.

09

Оферти само от оторизирани ценови правила

Най-рисковата точка в целия процес е генерирането на цена. Правилото тук трябва да е абсолютно: агентът цитира цена или условия единствено от документ с ценови правила, зададен от компанията (чрез RAG върху актуален прайслист или ценови API), и никога не изчислява, преценява или „закръглява“ цена сам.

Ако запитването не покрива ясно дефиниран случай в ценовите правила — нестандартен обем, комбинирана услуга, специална отстъпка — агентът не предлага цена, а маркира случая за ценообразуване от човек. Грешна цена, изречена уверено от агент, е по-скъп проблем от забавен отговор.

10

Предаване на човек: кога и как

Handoff към търговец трябва да се случва на ясно дефинирани точки: клиент с висок score, въпрос извън обхвата на агента, изрично искане да говори с човек, или всяко запитване, свързано с цена извън стандартните правила. При предаване, търговецът получава пълното обобщение от агента, не празна страница.

Клиентът трябва винаги да знае, че говори с AI агент на този етап и да има лесен начин да поиска човек веднага — това е и въпрос на прозрачност, не само на UX.

11

Какво AI агентът не прави добре

Честно ограничение, което трябва да е част от всеки проект: агентът не преговаря условия, не усеща емоционално съпротивление на клиента отвъд явни думи, и не борави добре с нестандартни, многопластови случаи. Опитите да се „разшири“ обхватът му да покрива всичко водят до объркващи, прекалено общи отговори, които вредят на доверието повече от честно „ще ви свържа с колега“.

Там, където процесът е напълно предвидим — потвърждение на поръчка, статус на съществуваща сделка, изпращане на вече одобрен документ — класическа детерминирана автоматизация през API е по-бърза, по-евтина и по-предсказуема от AI агент.

12

Логване и обратна връзка за подобряване на квалификацията

Всеки разговор, score и handoff решение се логва с входните отговори и крайния резултат. Периодичен преглед от търговския екип — кои лийдове с нисък score реално се затвориха като сделки, кои с висок score не отговориха — е основният механизъм за калибриране на критериите за квалификация с времето.

Без тази обратна връзка, score-ът на агента остава статичен предположение, а не нещо, което се учи от реалния пазар на компанията.

13

Практически старт

Разумен обхват за първа версия: агент, който квалифицира входящи запитвания от сайта извън работно време, записва структурирани данни в CRM и предлага score и следваща стъпка — без автоматично изпращане на нищо навън. Разширяването към follow-up чернови и ценови правила идва след няколко седмици наблюдение на логовете.

За по-широк контекст върху видовете агенти, приложими в продажбения процес, вижте /ai-asistenti-agenti, а как AI агент поддържа хигиена и обобщения вътре в самия CRM е разгледано в /blog/ai-agent-crm-avtomatizatsiya. Ако данните на клиентите трябва да останат в контролирана среда, /lokalen-ai-za-biznesa описва локална алтернатива на облачните модели. За да стартирате конкретен проект, вижте /start.