---
title: "Kaip sujungti CRM su DI asistentu: integracijos vadovas 2026"
description: "Žingsnis po žingsnio vadovas, kaip sujungti CRM su DI registratūros asistentu. ClinicCards, Alteg, Google Calendar, API jungtys, BDAR ir paleidimas į gyvenimą."
url: "https://ainora.lt/lt/blogas/crm-ai-asistento-integracijos-vadovas"
---

[Grįžti į blogą](/lt/blogas)
# Kaip sujungti CRM su DI asistentu: integracijos vadovas 2026

## Kodėl CRM integracija yra būtina

DI asistentas be CRM integracijos  -  tai kaip registratorė, kuri negali matyti kalendoriaus. Ji gali atsiliepti į telefoną, maloniai pakalbėti ir užrašyti vardą  -  bet faktiškai vizito neįrašo. Klientas laukia skambučio. Pusė jų nebelauks.

Tai pagrindinis bazinių DI balso botų apribojimas. Pokalbį jie sutvarko, tačiau vizito registraciją perduoda žmogui. Būtent čia prarandami klientai  -  ypač ne darbo metu, kai žmogus negalės atlikti rezervacijos per kelias minutes.

CRM integracija šį perdavimą pašalina visiškai. Kai [DI skaitmeninis administratorius](/lt/blogas/kas-yra-ai-skaitmeninis-administratorius) prijungtas prie Jūsų registravimo sistemos, jis gali:

- **Tikrinti laisvus laikus realiuoju laiku**  -  ne tik užrašyti pageidaujamą laiką, bet iš tikrųjų patvirtinti, ar ta vieta egzistuoja ir ar ji laisva dabar
- **Užbaigti rezervaciją tiesiai pokalbyje**  -  sukurti vizito įrašą, užblokuoti laiką ir išsiųsti patvirtinimą, kol klientas dar kalbasi telefonu
- **Pasiekti kliento istoriją**  -  atpažinti esamus klientus pagal telefono numerį, pasveikinti juos vardu ir žinoti paskutinio vizito datą bei pastabas
- **Grąžinti struktūruotus duomenis**  -  kiekvienas skambutis tampa CRM įrašu: kas skambino, dėl ko, kas buvo užregistruota

Skirtumas rezultatuose reikšmingas. DI [skaitmeninis administratorius](/lt/blogas/kaip-pakeisti-administratore-su-ai) su pilna CRM integracija konvertuoja įeinančius skambučius į rezervacijas maždaug dvigubai dažniau nei sistema, kuri tik renka pranešimus. Verslui, gaunančiam 30 skambučių per dieną, šis skirtumas kaupiasi greitai.

## Kokios CRM sistemos integruojasi su DI

Geroji žinia  -  dauguma šiuolaikinių registravimo sistemų turi API, vadinasi, integracija yra galima. Integracijos kokybė ir gylis priklauso nuo to, ką ta CRM API leidžia daryti.

### Lietuviškos ir Baltijos rinkoje populiarios sistemos

Tai specializuotos platformos, sukurtos konkrečioms industrijoms. Jos paprastai turi išsamiausias registravimo API:

- **ClinicCards**  -  plačiai naudojama Lietuvos odontologijos ir medicinos klinikose. ClinicCards REST API leidžia skaityti laisvus laikus pagal gydytoją ir paslaugos tipą, kurti vizitų įrašus, gauti pacientų profilius ir įrašyti paskambinimo santraukas. Palaikoma pilna dvikryptė integracija  -  DI tiek skaito, tiek rašo į sistemą.
- **Alteg**  -  dominuojanti platforma grožio ir sveikatingumo sektoriuje Lietuvoje ir visose Baltijos šalyse. Alteg API leidžia pasiekti paslaugų katalogą, darbuotojų tvarkaraščius, ieškoti kliento kortelės pagal telefono numerį ir kurti rezervacijas. Ypač tinka salonams, SPA centrams ir estetinės medicinos klinikoms, kur svarbu konkretaus specialisto prieinamumas.
- **Google Calendar**  -  paprasčiausia integracija. DI jungiasi per Google Calendar API naudodamas OAuth2, nuskaito laisvus laikus iš nurodyto kalendoriaus ir kuria įvykius tiesiogiai. Tinka verslams, kurie neturi specialios CRM ir tvarkaraščius valdo Google Calendar. Diegimo laikas: 1-2 valandos.
- **Calendly**  -  panašus į Google Calendar paprastumu, bet su papildoma rezervavimo logika. DI naudoja Calendly API, kad gautų prieinamas laiko nišas ir sukurtų rezervacijas. Calendly automatiškai išsiunčia patvirtinimo laiškus. Tinka konsultantams, treneriams ir smulkiam paslaugų verslui.
- **TimeTo, MedBooker, iDent**  -  kitos medicinos ir sveikatingumo registravimo platformos, populiarios regione. API brandumas skiriasi; bazinė integracija (laisvų laikų tikrinimas + rezervacijos kūrimas) paprastai prieinama.

### Savos (custom) ir vidinės sistemos

Daugelis didesnių verslų  -  viešbučiai, autoservisų tinklai, daugiafilialaliniai paslaugų centrai  - naudoja savos kūrimo registravimo sistemas. Jas integruoti taip pat galima, tačiau procesas skiriasi. Vietoj standartinio konekveryto Jūsų kūrėjų komanda sukuria API sluoksnį: konkrečius endpoint'us (laisvų laikų tikrinimui, rezervacijos kūrimui, kliento paieškai), kuriuos DI gali kviesti per webhook. Tai papildomai užtrunka, bet suteikia visiškai pritaikytą integraciją.

Jei Jūsų sistema visai neturi API  -  kas vis rečiau pasitaiko, bet dar būna su senomis programomis  - alternatyvos egzistuoja: ekrano nuskaitymo automatizavimas, duomenų bazės lygio jungtys arba tarpinė sinchronizavimo sistema. Jos sudėtingesnės ir brangesnės, tačiau galimos.

## Trys integracijos tipai

Ne visos integracijos yra vienodai gilios. Yra trys lygiai, o tinkamas priklauso nuo to, ką Jūsų CRM palaiko ir ko norite iš DI:

## Integracijos procesas žingsnis po žingsnio

Štai kas vyksta nuo sprendimo integruoti iki momento, kai DI pradeda rezervuoti vizitus gyvo. Tai tikrasis procesas  -  ne rinkodaros apibendrinimas.

## Kokie duomenys juda tarp sistemų

Suprasti, kokie duomenys juda ir kokia kryptimi, būtina tiek techniniam planavimui, tiek BDAR atitikčiai. Štai pilnas vaizdas:

### Duomenys, kuriuos DI skaito iš Jūsų CRM

- **Laisvi laikai**  -  pagal datą, laiką, paslaugos tipą ir, jei reikia, konkretų darbuotoją
- **Paslaugų katalogas**  -  pavadinimai, aprašymai, trukmė, kainos, paruošimo reikalavimai
- **Darbuotojų profiliai**  -  vardai ir specializacijos (DI naudoja, kai skambinantysis turi pageidavimą)
- **Kliento kortelė**  -  ieškoma pagal mobiliojo telefono numerį kiekvieno skambučio pradžioje; apima vardą, paskutinio vizito datą, ankstesnes paslaugas ir pastabas
- **Vietos duomenys**  -  daugiafilialiams verslams, kuriose vietose kurios paslaugos prieinamos

### Duomenys, kuriuos DI rašo į Jūsų CRM

- **Nauji vizitų įrašai**  -  data, laikas, paslauga, paskirtas darbuotojas, kliento vardas, kontaktinis numeris
- **Skambučio santraukos pastabos**  -  pridedamos prie vizito ar kliento kortelės: skambinimo priežastis, rezultatas, reikalingi tolesni veiksmai
- **Naujos kliento kortelės**  -  kai skambinantysis nerandamas sistemoje, DI sukuria minimalų įrašą su vardu ir telefono numeriu
- **Skambučio metaduomenys**  -  trukmė, laiko žyma, rezultatas (rezervuota, tik paklausimas, perduota žmogui, ne temos)

### Duomenys, kurie niekada nepalieka Jūsų CRM

DI nekopijuoja visos Jūsų duomenų bazės. Kiekvieno skambučio metu jis siunčia realaus laiko API užklausas ir nesaugo jautrių pacientų ar klientų duomenų savo serveriuose ilgiau nei skambučio sesijos trukmę. Medicinos dokumentai, finansiniai duomenys ir darbuotojų asmeninė informacija niekada nepasiekiami, nebent jūs aiškiai konfigūruojate tam skirtą endpoint'ą  -  standartiniuose diegimuose to nėra.

## BDAR ir duomenų saugumas

Kiekvienam verslui, tvarkančiam asmens duomenis  -  o tai kiekvienas verslas šiame kontekste  - BDAR atitiktis nėra pasirinkimas. Štai kaip tinkamai įgyvendinta DI asistento integracija tai sprendžia:

### Duomenų tvarkymo sutartis (DTS)

Pagal BDAR Jūsų DI tiekėjas tvarko asmens duomenis Jūsų vardu, taigi jis yra duomenų tvarkytojas. Prieš pradedant integraciją, turi būti sudaryta Duomenų tvarkymo sutartis. Šioje sutartyje nurodoma, kokie duomenys tvarkomi, kokiu tikslu, kaip apsaugomi ir kaip pranešama apie pažeidimus. Solidūs DI tiekėjai turi standartines DTS, paruoštas pasirašyti. Atsisakykite bet kokio tiekėjo, kuris negali jos pateikti.

### Skambučių įrašymas ir sutikimas

Jei įjungtas skambučių įrašymas (paprastai taip, dėl kokybės užtikrinimo), skambinantieji turi būti informuoti skambučio pradžioje. Standartinis sprendimas: DI kiekvieną skambutį pradeda trumpu pranešimu  -  "Šis pokalbis gali būti įrašytas kokybės ir mokymo tikslais." Lietuvoje ir visoje ES, tęsiant pokalbį po šio informavimo, daugeliu atvejų tai laikoma numanomu sutikimu. Pasikonsultuokite su savo teisės patarėju dėl Jūsų konkrečios situacijos.

### Duomenų minimizavimas

DI prašo ir saugo tik tai, ko reikia rezervacijai. Jis neklausia gimimo datos, asmens kodo ar medicinos istorijos, nebent Jūsų paslauga to teisėtai reikalauja ir tai aprašyta Jūsų privatumo politikoje. Duomenų žemėlapis (3 žingsnis) yra ir duomenų minimizavimo pratimas  - jūs apibrėžiate, kuriuos laukus DI gali skaityti ir rašyti.

### Duomenų saugojimo laikotarpis

Skambučių santraukos, grąžintos į Jūsų CRM, priklauso Jūsų esamai CRM duomenų saugojimo politikai. Skambučių įrašai (jei saugomi DI platformos) turėtų turėti apibrėžtą saugojimo laikotarpį  -  paprastai 90 dienų kokybės užtikrinimo tikslais, po kurių automatiškai ištrinami. Jūsų DTS su DI tiekėju turėtų tai nurodyti.

### Duomenų buvimo vieta

ES verslams patvirtinkite, kad Jūsų DI tiekėjas duomenis tvarko ir saugo ES teritorijoje. Tiekėjai, naudojantys JAV infrastruktūrą, turi turėti Standartines sutartines sąlygas (SCC) BDAR atitikčiai. Tai realus klausimas vertinant tiekėjus  -  paklauskite aiškiai prieš pasirašydami.

## Testavimas ir paleidimas

Testavimo etapas nulemia, ar integracija veikia realybėje, o ne tik demonstracijoje. Štai scenarijai, kuriuos reikia patikrinti prieš paleidimą:

### Rezervavimo scenarijų testai

- Naujas klientas rezervuoja dažną paslaugą su laisvais laikais → teisingas vizitas atsiranda CRM
- Esamas klientas skambina → DI teisingai atpažįsta jį pagal telefono numerį ir sveikina vardu
- Skambinantysis pageidauja konkretaus specialisto → DI tikrina būtent to specialisto prieinamumą
- Skambinantysis prašo užimto laiko → DI siūlo artimiausias tris alternatyvas
- Klientas rezervuoja po darbo valandų → rezervacija patvirtinama iš karto (tai pagrindinis privalumas)

### Kraštutinių situacijų testai

- Skambinantysis klausia, ko DI nežino → DI eskaluoja švelniai, nepaleisdamas kliento
- Skambinantysis nori atšaukti jau esantį vizitą → DI tinkamai sutvarko arba nukreipia
- CRM laikinai neprieinamas → DI persijungia į pranešimų rinkimo režimą, o ne klaidos pranešimą
- Skambinantysis nurodo neteisingą telefono numerio formatą → DI paprašo patikslinti

### Darbuotojų patikrinimas

Prieš paleidimą atlikite 20-30 bandomųjų skambučių. Kiekvienam skambučiui darbuotojas patikrina, ar gautas CRM įrašas tikslus  -  teisingas laikas, teisingas klientas, teisingos pastabos. Šis patikrinimo žingsnis išaiškina duomenų žemėlapio klaidas, kurių nematyti pokalbio tekste.

## Dažnos problemos ir sprendimai

Štai problemos, kurios dažniausiai iškyla integracijos metu ir po jos, bei kaip jas spręsti:

### DI registruoja netinkamu laiku (laiko juostų problema)

Dauguma API datos ir laiko laukų naudoja UTC. Jei Jūsų CRM saugo laikus UTC, bet verslas veikia EET (UTC+2 žiemą, UTC+3 vasarą), kiekviena rezervacija bus perstumta dviem ar trimis valandomis. Sprendimas: aiškiai nustatyti laiko juostą visose API užklausose ir patikrinti, kaip CRM API dokumentacija nurodo grąžinamus laikus. Patikrinkite rezervacijas artimose vietos vidurnakčiui laikams.

### Klientas neatpažįstamas, nors sistemoje yra

Dažniausia priežastis  -  telefono numerių formato neatitikimas. Jūsų CRM gali saugoti numerius kaip "+37060000000", bet skambinančiojo numeris DI sistemoje ateina kaip "060000000". Sprendimas: normalizuoti visus telefono numerius į E.164 formatą (+šalies kodas + numeris) tiek DI įvesties sluoksnyje, tiek CRM. Normalizavimo funkcija, šalinanti pradines nules ir pridedanti šalies kodą, išsprendžia daugumą atvejų.

### DI siūlo jau užimtus laikus

Tai atsitinka, kai DI saugo talpykloje prieinamumo duomenis, o ne tikrina gyvo. Sprendimas: užtikrinti, kad prieinamumo tikrinimas yra tiesiogines užklausos, arba, jei naudojama talpykla greičiui, riboti jos gyvavimo laiką iki 30 sekundžių ar mažiau.

### Paslaugų pavadinimai nesutampa

Skambinantysis sako "dantų balinimas", bet Jūsų CRM katalogas turi "dantų balinimas (kabinete)". DI negali šių variantų sujungti be aiškios konfigūracijos. Sprendimas: integracijos metu (3 žingsnis) peržiūrėkite duomenų žemėlapį ir pridėkite sinonimų atitikmenį kiekvienai paslaugai, įskaitant šnekamuosius pavadinimus ir dažnas klaidas.

Kai CRM integracija veikia, perėjote nuo balso boto prie tikro [DI registratūros](/lt/blogas/kaip-pakeisti-administratore-su-ai). Visi [trys DI integracijos lygiai](/lt/blogas/trys-ai-integracijos-lygiai) remiasi šiuo pagrindu. Su pilna CRM jungtimi galite pereiti nuo įeinančių skambučių tvarkymo prie proaktyvaus klientų sugrąžinimo ir pajamų generavimo, nekeisdami pagrindinės sistemos.

Klientų atpažinimas ir personalizavimas, kurie skiria gerą DI asistentą nuo puikaus, įmanomi tik kai DI turi tiesioginę prieigą prie Jūsų CRM duomenų. Integracija nėra techninis papildymas  -  tai funkcija, kuri daro visą sistemą verta naudoti. Sužinokite daugiau apie [kaip DI prisimena klientus](/lt/blogas/kaip-ai-prisimena-klientus) ir kaip tai veikia praktiškai. Norite išgirsti, kaip skamba pilnai integruotas DI asistentas? Išbandykite mūsų [balso įskiepį](/lt/balso-iskiepis), peržiūrėkite visas [AINORA paslaugas](/lt/platforma) arba [užsisakykite nemokamą demo](/demo) ir parodysime integraciją su Jūsų CRM.

Daugiau apie Ainora

Platformos ir srities puslapiai, susiję su šiuo straipsniu.

- [AINORA balso agentasPlatformos apžvalga](/lt/di-balso-agentas)
- [KainosPlanai ir įtrauktos minutės](/lt/kainos)
- [Kaip veikiaDiegimas ir integracijos](/lt/kaip-veikia)
- [DUKDažniausi klausimai](/lt/duk)
