CRM duomenų sinchronizavimas: kodėl dublikatai grįžta

Kaip išvengti pasikartojančių CRM kontaktų: įrašų atpažinimo taisyklės, duomenų šaltiniai ir saugus pakartotinis siuntimas prieš jungiant naujus įrankius.

2026 m. spalio 2 d.

Areza Digital

Penktadienį sujungiate du to paties kliento įrašus. Pirmadienį dublikatas grįžta. Svetainė sukūrė dar vieną kontaktą, senas importas atkūrė ankstesnį el. pašto adresą, o su tuo pačiu žmogumi jau susisiekia du pardavėjai.

CRM duomenų sinchronizavimui reikia taisyklių, pagal kurias atpažįstamas esamas klientas ir pasirenkama, kuriuos pakeitimus išsaugoti. Vienkartinis duomenų bazės sutvarkymas neapsaugos nuo kitos integracijos, kuri sukurs tą pačią problemą.

Prieš prijungdami dar vieną įrankį ar DI asistentą, atsakykite į keturis klausimus: kurie įrašai priklauso tam pačiam klientui, kuri sistema atsakinga už kiekvieną lauką, kas nutinka užklausą vykdant pakartotinai ir kaip elgtis su sujungtais ar pašalintais įrašais?

Kaip vienas klientas virsta trimis įrašais

Toliau pateikiamas iliustracinis pavyzdys, o ne kliento projekto aprašymas.

Pirkėjas svetainėje paprašo pasiūlymo. CRM sukuria kontaktą C-1042. Vėliau užsakymų sistema sukuria klientą O-778. Pardavėjas dar importuoja lentelę su ankstesniu to pirkėjo el. pašto adresu.

Trys įrašai nebūtinai reiškia tris klientus. Turėti po įrašą kiekvienoje sistemoje yra įprasta. Problema prasideda, kai tarp jų nėra ryšio: kiekvienas naujas pranešimas ar importas tampa proga sukurti dar vieną kontaktą.

Jei pradinė užklausa apskritai nieko nepasiekia, pradėkite nuo mūsų gido apie svetainės užklausų perdavimą. Čia užklausa atkeliauja. Klaida įvyksta sprendžiant, kuriam įrašui ji priklauso.

1. Prieš perkeldami laukus atpažinkite klientą

Laukų susiejimas nurodo, kad svetainės el. pašto lauko reikšmę reikia įrašyti į CRM el. pašto lauką. Įrašų atpažinimo taisyklė nustato, ar atkeliaujantys duomenys priklauso jau esančiam žmogui. Reikia abiejų.

„HubSpot“ dokumentacijoje šie veiksmai atskiriami: įrašai atpažįstami nepriklausomai nuo laukų susiejimo, o vėliau susietų įrašų ryšys palaikomas pagal jų identifikatorius. Šaltinis: „HubSpot“ įrašų atpažinimas.

Kurdami CRM integraciją, naudokite stabilų identifikatorių, kurį abi sistemos jau turi, jei toks yra. Kitu atveju nustatykite, kokių duomenų pakanka pradiniam atpažinimui, ir išsaugokite patvirtintą ryšį. Mūsų pavyzdyje tai reiškia išlaikyti sąsają tarp C-1042 ir O-778, užuot kiekvieną kartą iš naujo ieškojus kliento pagal vardą.

El. paštas gali padėti pirmą kartą atpažinti kontaktą, tačiau jis nėra nekintanti tapatybė. Žmonės keičia adresus. Vienu pirkimų skyriaus pašto adresu gali naudotis keli žmonės. Keičiasi ir darbovietės bei įmonių domenai.

Neaiškius atvejus perduokite peržiūrai. Du toje pačioje įmonėje dirbantys žmonės vardu Aleksas nėra pakankamas pagrindas automatiškai sujungti kontaktus.

Taip pat patikrinkite, ką CRM daro aptikusi galimą dublikatą. „Salesforce“ atskiria atpažinimo taisykles, kurios nustato galimus dublikatus, nuo taisyklių, pagal kurias su jais elgiamasi. Aptikimas ir prevencija yra atskiri sprendimai. Šaltinis: „Salesforce“ atpažinimo taisyklės.

2. Kiekvienam laukui priskirkite pagrindinį šaltinį

Teiginys „teisingi duomenys yra CRM“ atrodo aiškus, kol nepasikeičia užsakymas, neatkeliauja forma su tuščiu telefono lauku arba pardavėjas nepataiso įmonės pavadinimo.

Nuspręskite, kuris šaltinis lemia kiekvieną reikšmę. Toliau – pavyzdinės pardavimų komandos taisyklės, o ne visiems tinkanti konfigūracija.

Braukite arba slinkite, kad palygintumėte.

Atskirai apibrėžkite, ką reiškia nepateikta, tuščia ir sąmoningai išvalyta reikšmė. Jei forma telefono numerio neklausia, ji nepateikė jo atnaujinimo. Jei žmogus sąmoningai pašalino klaidingą numerį, tai jau pakeitimas.

Netaikykite taisyklės „laimi paskutinis atnaujinimas“ visiems laukams. Pavėluotas lentelės importas gali atkeliauti po pataisymo, nors pačioje lentelėje tebėra seni duomenys. Vėlesnis gavimo laikas nepadaro jų tikslesnių.

3. Pasirūpinkite saugiu pakartotiniu vykdymu

Įsivaizduokite, kad CRM sėkmingai sukuria kontaktą, bet ryšys nutrūksta prieš svetainei gaunant patvirtinimą. Svetainė bando dar kartą. Jei integracija kiekvieną bandymą laiko nauja užklausa, vienas formos pateikimas gali sukurti du įrašus.

Kiekvienai pateiktai užklausai suteikite stabilų identifikatorių, kuris nesikeičia bandant pakartotinai. Išsaugokite atlikto veiksmo rezultatą, kad pakartota ta pati užklausa grąžintų jau esamą rezultatą. Programuotojai tai vadina idempotentiškumu: tą patį veiksmą galima kartoti nesukuriant papildomos kopijos.

Ši apsauga turi veikti ir tada, kai du bandymai atkeliauja vienu metu. Patikra „jei nėra, sukurk“ vis tiek gali sukurti dublikatų, jei abu bandymai patikrins prieš kuriam nors užbaigiant darbą. Kai įmanoma, naudokite gavėjo palaikomą pakartojimų apsaugą arba atominį unikalumo užtikrinimą ir patikrinkite konkrečios jungties elgseną.

Tačiau nelaikykite visų to paties kliento užklausų vienu įvykiu. Pirkėjas, paprašęs antro pasiūlymo, pateikė naują užklausą, nors kontaktas lieka tas pats.

Dvikrypčiam sinchronizavimui reikia dar vienos ribos: iš sistemos A į sistemą B nukopijuotas pakeitimas neturėtų be galo grįžti kaip naujas pakeitimas. Sekite, iš kur atėjo atnaujinimas ir ar gavėjo duomenys jau atitinka norimą reikšmę.

4. Numatykite, kas vyks sujungus įrašus

CRM sujungus kontaktus, ne kiekvienas prijungtas įrankis automatiškai sužino, kuris įrašas liko.

Jei integracija teberodo į panaikintą kontaktą, kitas atnaujinimas gali nepavykti arba atkurti nepageidaujamą įrašą. Patvirtinus sujungimą reikia atnaujinti saugomus ryšius ir išsaugoti reikalingą pokalbių, užsakymų bei veiksmų istoriją.

Pašalinimą aptarkite atskirai. Įrašo atsiejimas, archyvavimas ir ištrynimas yra skirtingi veiksmai. Nuspręskite, kaip į kiekvieną jų reaguos susietos sistemos; įprastas importas neturėtų tyliai atkurti sąmoningai pašalinto įrašo.

Prieš masinį tvarkymą išsaugokite atkuriamą duomenų eksportą ir patikrinkite CRM sujungimo veikimą. Pradėkite nuo nedidelės peržiūrėtos grupės, kad galėtumėte patikrinti istoriją ir susijusius įrašus kitose sistemose.

Penki bandymai prieš įjungiant visą sinchronizavimą

Naudokite bandomuosius įrašus ir tikrinkite gavėją, o ne vien žalią jungties būseną.

1. Pateikite tą pačią užklausą du kartus. Turi likti viena užklausa ir vienas kontaktas, o pakartotinis bandymas turi būti matomas.
2. Pateikite kitą to paties pirkėjo užklausą. Ji turi būti priskirta esamam kontaktui, neprarandant naujo prašymo.
3. Pakeiskite pirkėjo el. paštą. Anksčiau susietos sistemos turi toliau atnaujinti to paties žmogaus įrašus.
4. Atsiųskite prieštaringus pakeitimus. Patikrinkite tuščią telefono lauką ir po pataisymo atkeliaujantį senesnį importą; sutartos šaltinių taisyklės turi išlikti.
5. Sujunkite dublikatą ir pakartokite seną atnaujinimą. Jis turi pasiekti likusį įrašą arba peržiūros eilę, bet neatkurti dublikato.

Riboto paleidimo metu stebėkite neatpažintus įrašus, pasikartojančias klaidas ir perrašytus pataisymus. Jungties rodoma sėkmė tik patvirtina, kad veiksmas baigtas; patikrinkite, ar pasikeitė tinkamo kliento duomenys.

Kur DI padeda gerinti CRM duomenų kokybę

DI asistentas gali pasiūlyti, kad du skirtingai parašyti įmonės pavadinimai žymi tą pačią organizaciją, apibendrinti prieštaringas pastabas arba paruošti peržiūros eilę. Pasiūlymams vis tiek reikia pagrindimo, o ten, kur klaidingas sujungimas turėtų pasekmių, – aiškaus patvirtinimo.

Esamam įrašo identifikatoriui atpažinti kalbos modelio nereikia. Pakartotinei užklausai taip pat. Šiems sprendimams naudokite nustatytas taisykles, o DI palikite neaiškiai informacijai.

Areza sistemų integracijos sujungia svetaines, CRM ir vidinius įrankius pagal tokius sprendimus. Jei kontaktų dublikatai vis grįžta, papasakokite, kurios sistemos kuria ar atnaujina jūsų klientų įrašus. Nuo to pradėti naudingiau nei nuo dar vieno duomenų bazės valymo.