CRM un API / 02
Mājaslapas integrācija ar CRM: pieteikumi bez zudumiem un dublikātiem
Forma rāda “Nosūtīts”, taču CRM nav jauna darījuma. Vai arī klients nospiež pogu divreiz un divi darbinieki saņem vienādu pieteikumu. Mājaslapas integrācijai ar CRM jānodrošina izsekojams datu ceļš no formas līdz atbildīgajam darbiniekam, arī kļūmju un atkārtojumu gadījumā.
Galvenā atziņa
Formas pieņemšana un darījuma izveide CRM ir atsevišķi notikumi. Saglabājiet pieteikumu pirms saņemšanas apstiprinājuma, sekojiet piegādei un nosakiet atkārtojumu noteikumus.
1. Vienojieties par datiem pirms API pieslēgšanas
Sāciet ar lauku atbilstības tabulu: katrai vērtībai norādiet avotu, formātu, obligātumu un CRM lauku. Parasti vajadzīga kontaktinformācija, pieprasījuma teksts, pakalpojums, saziņas valoda un lapas avots. Neievāciet papildu datus tikai tāpēc, ka CRM ļauj tos glabāt.
Nošķiriet kontaktu un pieteikumu. Vienam klientam var būt divi dažādi uzdevumi; vienāds e-pasts nenozīmē darījuma dublikātu. Kontaktu apvienošanai un atkārtotas iesniegšanas novēršanai vajadzīgi atsevišķi noteikumi. Izlemiet arī, vai publiska forma drīkst pārrakstīt esoša klienta vārdu vai tālruni.
| Lauks | Mērķis | Noteikums |
|---|---|---|
| request_id | Pieteikuma identifikators | Tehniskā atkārtojumā paliek nemainīgs |
| email / phone | Klienta kontakts | Pārbaude serverī |
| service / message | Pieprasījuma konteksts | Saglabājas, veidojot darījumu |
| language / source | Pieteikuma novirzīšana | Tikai atļautās vērtības |
2. Izveidojiet uzticamu pieteikuma ceļu
Ja pieteikuma zudums nav pieļaujams, noder shēma: pārlūks → mājaslapas serveris → saglabāts pieteikums → nodošana CRM → ārējā identifikatora saglabāšana. Saņemšanu apstiprina tikai pēc drošas saglabāšanas. Ja CRM īslaicīgi nav pieejama, klientam nav atkārtoti jāaizpilda jau pieņemta forma.
Nelielā sistēmā rindas lomu var pildīt tabula ar apstrādes statusiem un atsevišķs apstrādātājs. Lielākai slodzei var būt vajadzīgs īpašs rindas risinājums. Svarīgi atšķirt stāvokļus “pieņemts”, “gaida nodošanu”, “piegādāts” un “vajadzīga uzmanība”. Kļūda pašu datu glabātuvē jāparāda kā kļūda, nevis veiksmīga saņemšana.
3. Apstrādājiet atkārtojumus un neskaidras atbildes
Idempotence nozīmē, ka vienas operācijas atkārtojums nerada jaunu rezultātu. Viena pieteikuma atkārtotai nosūtīšanai izmantojiet stabilu identifikatoru un servera pārbaudi. Pogas atspējošana pēc klikšķa uzlabo saskarni, taču neaizsargā pret tīkla atkārtojumiem vai paralēlu apstrādi.
Sarežģītāka situācija rodas, ja CRM izveido darījumu, bet atbilde pazūd. Akls atkārtojums var radīt dublikātu. Ja API atbalsta idempotences atslēgu, izmantojiet to; citādi jāizvērtē meklēšana pēc ārējā identifikatora un datu salīdzināšana. Pirms solīt apstrādi tieši vienu reizi, pārbaudiet konkrētās CRM iespējas.
Pārbaudiet arī webhook piegādes noteikumus. Piemēram, Stripe dokumentē iespējamos atkārtotos notikumus un negarantē piegādes secību. Tas ir ārējas API uzvedības piemērs; katras CRM nosacījumi jāpārbauda atsevišķi.
4. Nošķiriet īslaicīgas un pastāvīgas kļūdas
Noildze vai īslaicīga nepieejamība var pieļaut atkārtojumu ar pieaugošu aizkavi. Nepareizs lauka formāts prasa datu labojumu. Nederīga piekļuves atslēga prasa atbildīgā iesaisti. Bezgalīgi atkārtot visas kļūdas vienādi nozīmē slēpt problēmu un radīt lieku slodzi.
Ierobežojiet automātisko mēģinājumu skaitu, ievērojiet dokumentētos API limitus un saglabājiet drošu pēdējās kļūdas aprakstu. Nepiegādātiem pieteikumiem vajadzīgs manuālas izskatīšanas saraksts. Vērojiet arī vecākā gaidošā pieteikuma vecumu: rinda var augt, kamēr atsevišķi sistēmas pieprasījumi izskatās veiksmīgi.
5. Ierobežojiet piekļuves un žurnālu saturu
Slepenās CRM atslēgas izmantojiet tikai serverī. Integrācijai piešķiriet vajadzīgās tiesības, atdaliet testa un darba vidi un nosakiet atslēgu maiņas kārtību. Ienākošos paziņojumus pārbaudiet ar piegādātāja dokumentēto metodi; grūti uzminama adrese viena pati neapstiprina sūtītāju.
Tehniskajā žurnālā parasti pietiek ar pieteikuma identifikatoru, laiku, statusu un drošu kļūdas kodu. Nekopējiet klientu ziņojumus un piekļuves datus nekontrolēti žurnālos. Datu glabāšanas termiņus un piekļuvi saskaņojiet ar uzņēmuma atbildīgo par datu apstrādi.
6. Pārbaudiet visu scenāriju pirms palaišanas
Nepietiek tikai ieraudzīt darījumu testa CRM. Pārbaudiet atbildīgo, valodu, pakalpojumu, paziņojumu un iespēju atrast sākotnējo pieteikumu. Katram testam fiksējiet sagaidāmo rezultātu un veidu, kā to novērot.
Projekta nodošanā iekļaujiet lauku un statusu aprakstu, iestatījumu sarakstu bez noslēpumiem, atkārtotas apstrādes instrukciju un uzturēšanas atbildīgo. Divvirzienu sinhronizācijai atsevišķi nosakiet galveno sistēmu katram laukam un konfliktu risināšanas noteikumus.
- Parasts pieteikums izveido pareizos laukus un atbildīgo.
- Viena pieprasījuma atkārtojums nerada otru darījumu.
- Jauns tā paša klienta pieprasījums paliek atsevišķs pieteikums.
- CRM kļūmes laikā pieņemtais pieteikums ir atjaunojams.
- Pazudusi CRM atbilde tiek pārbaudīta pirms iespējama dublikāta izveides.
- Nepareizi dati un nederīgas atslēgas ir redzamas atbildīgajam.
- Pēc savienojuma atjaunošanas rinda tiek apstrādāta un rezultātu var salīdzināt.
Biežākie jautājumi
- Vai datus CRM var sūtīt tieši no pārlūka?
- Daži piegādātāji piedāvā šim nolūkam publisku API, taču slepenas atslēgas nedrīkst ievietot pārlūkā. Servera pieņemšana ļauj vienuviet pārbaudīt datus, pārvaldīt atkārtojumus un sekot piegādei.
- Kad pietiek ar gatavu spraudni?
- Ja tas atbalsta vajadzīgos laukus, ir savietojams ar mājaslapas un CRM versijām, parāda kļūdas un ļauj atjaunot neveiksmīgu nodošanu. Pārbaudiet to ar testa pieteikumiem pirms palaišanas.
- Vai divvirzienu sinhronizācija ir obligāta?
- Nē. Pieteikumu pieņemšanai bieži pietiek ar nodošanu no mājaslapas uz CRM. Atpakaļsinhronizācija vajadzīga, ja mājaslapā rāda CRM pārvaldītus statusus vai citus klienta datus.
Pielāgosim jūsu uzdevumam
Pastāstiet, kā veidota mājaslapa, kuru CRM izmantojat un kam jānotiek pēc pieteikuma. Noteiksim integrācijas shēmu un pārbaudes pirms palaišanas.
Pārrunāt uzdevumuSaistītais pakalpojums: Backend izstrāde un API integrācijas