Pirmiausia – duomenų savininkai
Kontaktas, įmonė, sandoris ir veikla yra skirtingi objektai. Vieno lauko pakeitimas neturi perrašyti visos kliento istorijos. Kiekvienam laukui nustatomas šaltinis ir konflikto sprendimas.
| Laukas | Pagrindinis šaltinis | Konflikto taisyklės pavyzdys |
|---|---|---|
| Įmonės identifikatorius | Patvirtintas įmonių registras | Nesujungti vien pagal panašų vardą |
| Pardavimo stadija | CRM ir jos savininkas | Išorinis laiškas negali pažymėti sandorio laimėtu |
| Sąskaitos apmokėjimas | Apskaita | Agentas netaiso mokėjimo pagal kliento teiginį |
| Rinkodaros atsisakymas | Kontaktavimo draudimų registras | Naujas importas draudimo nepanaikina |
Tai pavyzdinė atitikmenų lentelė; realūs laukų ID gaunami iš konkrečios CRM.
Dublikatai ir dvipusė sinchronizacija
Naudokite šaltinio bei tikslinės sistemos ID. El. pašto sutapimas gali padėti ieškoti kontakto, bet keli darbuotojai nėra tas pats asmuo vien todėl, kad dirba vienoje įmonėje. Susijungimo neaiškumas perduodamas peržiūrai.
Dvipusiame ryšyje fiksuokite pakeitimo kilmę ir versiją, kad įvykis nesukeltų begalinio atnaujinimų rato. Pavėlavęs pranešimas neturi tyliai perrašyti naujesnės informacijos.
Iliustracinis pakartoto laiško atvejis
Ta pati užklausa per pašto jungtį gaunama du kartus. Pagal laiško ID randamas pirmas vykdymas ir esamos galimybės ID. Antroji žinutė susiejama su tuo pačiu darbu; naujas sandoris ir pakartotinis siuntimas nesukuriami. Nežinomas pirmojo įrašymo rezultatas sutikrinamas tikslinėje sistemoje.
Veiksmai, prieigos ir kontrolė
Skaitymo, kontakto keitimo ir sandorio stadijos keitimo teisės suteikiamos atskirai. Istorijoje saugoma, kuris šaltinis ir vykdymas pakeitė lauką. Rodikliai: dubliuotų įrašų dalis, neaiškūs susiejimai, sinchronizavimo delsa ir nebaigti konfliktai.
CRM integracijose pateikiamas oficialia HubSpot dokumentacija pagrįstas objektų pavyzdys. Jei norite automatizuoti visą pardavimo kelią, rinkitės pardavimų sprendimą.