Asystent, który doradza i kwalifikuje klientów

Problem

Firma dostawała zapytania w dwóch trybach: przez formularz i telefonicznie. Oba mają tę samą wadę — działają w godzinach pracy biura, a znaczna część zapytań o eventy powstaje wieczorami i w weekendy, kiedy ktoś planuje konferencję albo wesele.

Drugi problem to charakter tych rozmów. Zanim w ogóle da się coś wycenić, trzeba ustalić datę, lokalizację, obiekt, godziny i typ wydarzenia. Do tego dochodzą powtarzalne pytania techniczne: ile miejsca zajmuje flipper, czy potrzebne jest osobne zasilanie, czy da się to postawić na zewnątrz. To dziesiątki takich samych rozmów miesięcznie, a każda zjada kilkanaście minut czasu handlowca.

Trzeci — i najtrudniejszy: wyceny nie da się zautomatyzować. Cena zależy od liczby dni, godzin, lokalizacji, kosztu transportu i ilości sprzętu, a przy tym obowiązuje minimum zamówieniowe. Bot, który poda cenę „z głowy”, nie oszczędza firmie pracy — kosztuje ją pieniądze i wiarygodność.

Co zrobiłem

Zaprojektowałem asystenta wokół jednej zasady: doradza i kwalifikuje, nigdy nie wycenia.

• Silnik automatyzacji n8n na własnym serwerze, z widgetem czatu osadzonym bezpośrednio na stronie klienta.
• Model językowy Google Gemini, podłączony przez dedykowany, rozliczany projekt API — z limitami dobranymi pod realny ruch na stronie.
• Kompletna baza wiedzy w system prompcie: 14 urządzeń wraz ze specyfikacjami, osobna tabela wymaganej przestrzeni montażowej (co jest czymś innym niż wymiary sprzętu), usługi dodatkowe — namioty, nagłośnienie, scena, agregaty — zasady logistyki, obszar działania i warunki montażu na zewnątrz.
• Zbieranie kompletu danych w rozmowie: data, lokalizacja, nazwa obiektu, godziny, typ wydarzenia, dane kontaktowe. Dokładnie ten sam zestaw co formularz „Szybka wycena”, tylko zebrany konwersacyjnie.
• Rozpoznawanie typu rozmówcy — inaczej podchodzi do rozmowy z organizatorem konferencji, inaczej z parą planującą wesele.
• Wysyłka na skrzynkę firmy przez dedykowaną skrzynkę nadawczą na domenie klienta, z zapytaniem sformatowanym jako gotowy do obsługi brief — oznaczonym tak, żeby odróżnić leady z bota od tych z formularza.
• Mapowanie nazw urządzeń na adresy podstron — bot potrafi podesłać link do galerii konkretnego sprzętu.

Wyzwanie techniczne

Najtrudniejsza część tego projektu nie była techniczna, tylko projektowa: jak sprawić, żeby model językowy był użyteczny, a jednocześnie nie zmyślał.

Pierwsze wersje bota potrafiły podać nieprecyzyjne wymagania techniczne albo skupiać się wyłącznie na najbardziej rozpoznawalnym urządzeniu, pomijając resztę oferty. Problem nie leżał w modelu, tylko w kompletności bazy wiedzy — wszystkie specyfikacje trzeba było zebrać, uporządkować i zapisać w formie, którą model traktuje jako źródło prawdy, a nie sugestię.

Doszło do tego kalibrowanie zachowania. Bot ma proaktywnie podawać wymaganą przestrzeń montażową przy omawianiu konkretnego urządzenia, ale nie zasypywać nią użytkownika przy ogólnym przeglądzie oferty. Ma pytać o jedną rzecz naraz, a nie wysyłać ankietę. I ma najpierw doradzić, a dopiero potem zbierać dane — bo odwrotna kolejność odstrasza.

To był proces iteracyjny: audyt promptu, test, poprawka, ponowny test — aż zachowanie stało się przewidywalne.

Bot, który pomyli się w wycenie, kosztuje więcej, niż oszczędza automatyzacja.