Как Vdiga, Pishe и Pomaga могат да работят заедно

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

Точно при тези предавания се губи работа. Бележката остава на лист. Името е записано, но без телефон. В CRM се появяват два еднакви клиента. Колегата научава за заявката на следващия ден. Не е нужен „по-умен чатбот“, а точно разпределение кой какво прави и кога спира.

Vdiga, Pomaga и Pishe могат да поемат различни части от тази работа. Не трябва да имат общ достъп до всичко. Vdiga води разговора. Pomaga проверява и мести данните между програмите. Pishe променя сайта само с вече одобрена информация. Човекът решава при цена, отстъпка, договор, противоречие или случай извън уговорените правила.

Кой какво поема?

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

Vdiga поема входящия разговор

Vdiga вдига телефона, представя се като AI асистент и пита за причината за обаждането. Може да отговори с информация, която фирмата е дала предварително, да приеме заявка и да предложи свободен час, ако календарът позволява надеждна връзка. След разговора оставя обобщение и полетата, които са нужни за следващата работа.

Тук важната настройка не е само какво да казва, а кога да не отговаря. При въпрос извън подготвената информация Vdiga взема данни за обратна връзка или предава разговора. Не обещава цена, отстъпка или услуга, които не са потвърдени.

Pomaga прехвърля данните и създава следващата задача

Pomaga поема работата след разговора, имейла или формата. Проверява например дали има име, телефон, избрана услуга и съгласие за обратна връзка. После създава или обновява запис в CRM, прави задача и я изпраща на човека, който трябва да продължи.

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

Pishe обновява сайта с вече одобрена информация

Pishe сменя цени, услуги, работно време и текстове, подготвя страници и проверява променените места на телефон и компютър. Включва се, след като фирмата е решила какво трябва да пише и кой го е одобрил.

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

Пример 1: от обаждането до CRM и задачата за колега

Клиент се обажда, докато търговците са на срещи. Иска оферта за услуга през следващата седмица.

1. Vdiga приема разговора. Записва име, телефон, искана услуга и кога клиентът очаква обаждане.
2. Pomaga проверява полетата. Търси съществуващ запис по телефон и имейл. Ако намери такъв, добавя новата заявка към него, вместо да създава втори клиент.
3. Pomaga създава задача. В нея има обобщението, срокът и името на човека, който трябва да върне обаждане.
4. Търговецът поема случая. Не слуша целия разговор и не преписва бележки. Вижда какво е поискано и какво още трябва да уточни.

Този процес има смисъл само ако предварително са решени три неща: кои полета са задължителни, как се проверява за дубликат и след колко време непоетата задача се напомня отново. Без тях получавате по-подреден вход, но не и по-добро обслужване.

Ако клиентът не даде телефон, заявката се отбелязва като непълна. Ако поиска отстъпка, Vdiga не я обещава. Ако CRM не отговори, Pomaga не прави пет опита и пет записа. Спира и уведомява човек.

Ако ви интересува само телефонната част, вижте как Vdiga приема разговори и записва часове.

Пример 2: повтарящ се въпрос показва какво липсва на сайта

В рамките на седмица осем души питат дали определена услуга се предлага и колко струва. Vdiga отговаря само ако има одобрена информация и оставя темата в обобщението на разговора.

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

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

Пример 3: заявка по имейл води до задача и промяна в каталога

Доставчик изпраща таблица с нови цени и наличности.

Pomaga може да прочете предварително уговорените колони, да сравни продуктовите кодове и да подготви списък с промените. Ако липсва код или две стойности си противоречат, редът отива за преглед. След потвърждение Pishe обновява продукта или услугата на сайта и проверява засегнатите страници.

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

Какво се предава между служителите?

Предават се полета, а не неясно „целият контекст“. Например:

• име и телефон за нов клиентски запис;
• избрана услуга и предпочитан час за задача към екипа;
• одобрена цена и адрес на страницата, на която трябва да се смени;
• номер на заявка и човекът, който трябва да я поеме;
• бележка какво липсва, когато задачата е спряла.

Записът от целия разговор не трябва да обикаля между всички програми. Pishe няма причина да вижда CRM, ако получава одобрена цена и адрес на страницата. Vdiga няма причина да редактира клиентски картони, ако задачата му свършва с предаването на данните.

Как се ограничават достъпите?

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

• Vdiga може да вижда свободни часове, без да вижда плащания.
• Pomaga може да създава клиентски запис, без да има право да изтрива клиенти.
• Pishe може да подготвя промяна, а публикуването да чака човешко потвърждение.

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

NIST AI Risk Management Framework разглежда контрола през целия живот на системата, не само при пускането ѝ. В ежедневната работа това означава: знаем защо е даден всеки достъп, пазим следа от всяко действие и предварително сме определили кой човек поема изключението.

Къде трябва да остане човек?

Човекът остава там, където трябва да се прецени риск, да се поеме обещание или да се избере между противоречиви данни. Например:

• определяне или промяна на цена;
• обещание за отстъпка;
• плащане, договор или друга необратима стъпка;
• публикуване на ново твърдение за услуга;
• избор между противоречиви данни;
• случай, който не прилича на примерите от тестовете.

Европейската комисия обяснява правилата за AI според риска. За една фирма полезният въпрос е по-прост: ако тази стъпка е грешна, може ли да бъде поправена лесно? Ако отговорът е „не“, човек трябва да одобри преди действието.

Кога връзката между тримата няма смисъл?

Не всяка фирма има нужда от тримата. Понякога пет минути ръчна работа са по-евтини и по-надеждни от връзка между три системи. Свързването си струва, когато една и съща информация минава по един и същ път достатъчно често, за да губи време или да създава грешки.

Не ги свързвайте, ако:

• обажданията са малко и човек лесно записва нужните данни;
• CRM се използва рядко или записът няма кой да го поеме;
• сайтът се променя веднъж годишно;
• всяка заявка изисква различна преценка;
• програмите не позволяват надеждна връзка;
• никой не е определил какво става при липсващи данни.

В тези случаи започнете само с една задача. Дълга верига, която човек постоянно поправя, не е автоматизация.

Започнете отделно, после свържете предаването

Първо се тества всяка задача отделно. Vdiga трябва да събира нужните данни без да обещава повече от позволеното. Pomaga трябва да разпознава дубликати и да спира при липсващо поле. Pishe трябва да променя само одобреното и да пази възможност за връщане назад. Едва тогава се свързват.

При теста гледаме:

1. Кои точно полета се предават?
2. По какво се разпознава съществуващият клиент?
3. Къде остава история на действията?
4. Колко пъти се прави повторен опит, ако програмата не отговори?
5. Кой получава случая и как разбира, че трябва да действа?

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

С коя задача да започнете?

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

• Ако изпускате обаждания, започнете с Vdiga.
• Ако сайтът показва стари цени и услуги, започнете с Pishe.
• Ако данните се преписват между имейл, CRM и таблици, започнете с Pomaga.

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

Често задавани въпроси

Трябва ли да използваме и тримата AI служители?

Не. Започнете с една задача, която се повтаря често и чието завършване можете да проверите. Добавете втори служител само ако същите данни редовно трябва да продължат към CRM, календар, имейл или сайта.

Може ли Vdiga да записва данни директно в CRM?

Зависи от CRM системата. Преди настройката проверяваме как се създава запис, кои полета са задължителни и дали достъпът може да бъде ограничен. Ако след разговора трябва да се проверят данни, да се създаде задача и да се уведоми човек, тези стъпки може да поеме Pomaga.

Pishe променя ли сайта без одобрение?

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

Какво става, ако липсва информация?

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

Как се тества работа между Vdiga, Pishe и Pomaga?

Първо тестваме всяка задача отделно с примери от фирмата. После проверяваме предаването между тях: кои данни се прехвърлят, къде остават записани, как се хваща дублиран случай и кой поема изключението.

Как е подготвена статията?

Мариян Дечев подготви статията по публикуваните задачи и ограничения на Vdiga, Pishe и Pomaga. Примерите показват как трябва да се проектира предаването на работа, а не готова връзка с всяка CRM или система за сайт. Конкретната интеграция се потвърждава след проверка на програмата, достъпите и случаите, при които трябва да се намеси човек. Използвани са рамката на NIST и информацията на Европейската комисия за управление на риска. Статията е проверена на 16 септември 2026 г.