Pārrunāt projektu Kalkulators

CRM integrācija: formas, e-pasts un pārdošanas process

CRM integrācija ar mājaslapas formu nozīmē, ka katrs pieteikums no mājaslapas automātiski kļūst par ierakstu CRM ar atbildīgo, posmu un nākamo darbību. Neviens to nepārraksta no e-pasta. Šeit skaidrojam, kā izveidot šo plūsmu no formas un e-pasta līdz pārdošanas posmam, atgādinājumam un atskaitei.

Autors
Aitroniclab
Redaktors
Aitroniclab redakcija
Publicēts
Atjaunināts

Ko nozīmē CRM integrācija ar mājaslapas formu

CRM integrācija ar mājaslapas formu ir savienojums, kas pēc formas iesniegšanas izveido vai papildina kontaktu un pieteikumu CRM sistēmā. Kopā ar ierakstu tiek norīkots atbildīgais un izveidota nākamā darbība, piemēram, zvans vai piedāvājums.

Bez šāda savienojuma forma parasti sūta e-pastu uz kopīgu pastkasti. Tālāk viss ir atkarīgs no tā, vai kāds e-pastu pamana, pārkopē datus un atceras atbildēt. Integrācija šo posmu padara redzamu un izmērāmu.

Tas ir īpaši svarīgi, ja pieteikumus apstrādā vairāki cilvēki. Kopīgā pastkastē nav redzams, kurš jau atbildēja, kurš pieteikums ir svarīgs un kurš palika bez uzmanības. CRM katram pieteikumam ir viens atbildīgais, viens statuss un visa saziņas vēsture, tāpēc pārdevēja atvaļinājums vai slimība nenozīmē pazaudētus klientus.

Savienojumu var izveidot vairākos veidos. Daudzām CRM sistēmām ir savas formas, kuras var ievietot mājaslapā. Citos gadījumos esošā forma sūta datus caur integrāciju platformu, piemēram, Zapier vai Make, vai tieši uz CRM API. Izvēle ir atkarīga no pieteikumu apjoma, loģikas sarežģītības un tā, kurš integrāciju uzturēs.

Pilna datu plūsma: no formas līdz atskaitei

Laba CRM integrācija nav tikai “forma sūta datus uz CRM”. Tā ir secīga plūsma, kur katram solim ir skaidrs rezultāts.

Ne katram uzņēmumam vajag visus sešus soļus no pirmās dienas. Bet ir vērts tos visus aprakstīt jau sākumā, jo lēmumi par laukiem un posmiem ietekmē to, ko vēlāk varēs redzēt atskaitēs. Ja formā neprasa, kāds pakalpojums klientu interesē, vēlāk nevarēs pateikt, kuri pakalpojumi ienes visvairāk pieteikumu.

  • Forma: klients ievada datus, un tie tiek pārbaudīti jau mājaslapā, piemēram, e-pasta formāts un obligātie lauki.
  • Ieraksts: CRM izveido jaunu kontaktu vai atrod esošo, lai nerastos dublikāti.
  • Atbildīgais: pieteikums tiek norīkots pēc noteikuma, piemēram, pēc pakalpojuma, reģiona vai valodas.
  • Posms: pieteikums nonāk pārdošanas piltuves pirmajā posmā, un tālāk tā kustība ir redzama.
  • Atgādinājums: ja noteiktā laikā nav aktivitātes, atbildīgais saņem uzdevumu vai brīdinājumu.
  • Atskaite: vadītājs redz, cik pieteikumu atnāca, no kurienes un kurā posmā tie ir.

E-pasts kā otrs ieejas punkts

Ne visi klienti aizpilda formu. Daudzi vienkārši raksta uz uzņēmuma e-pastu. Ja šie pieteikumi paliek pastkastē, CRM rāda tikai daļu ainas.

Daudzās CRM sistēmās var iestatīt e-pasta adresi, no kuras ienākošās vēstules automātiski kļūst par pieteikumiem. Odoo to sauc par e-pasta aliasu: vēstule, kas atnāk uz noteiktu adresi, izveido jaunu potenciālo klientu CRM. Tā formas un e-pasta pieteikumi nonāk vienā vietā un tiek apstrādāti pēc tiem pašiem noteikumiem.

Svarīgi ir izlemt, kā atšķirt jaunu pieteikumu no atbildes esošā sarunā un ko darīt ar surogātpastu. Šos noteikumus vērts aprakstīt pirms ieviešanas, nevis pēc pirmās nedēļas.

Kur integrācijas parasti pārtrūkst

Visbiežāk problēmas rada nevis pats savienojums, bet neskaidri noteikumi par datiem. Ja tas nav izlemts iepriekš, CRM ātri piepildās ar dublikātiem un nepilniem ierakstiem.

Visbīstamākā ir klusā kļūda. Ja savienojums pārstāj strādāt, forma mājaslapā joprojām izskatās normāli, klients saņem paldies ziņu, bet pieteikums nekur nenonāk. Tāpēc katrai integrācijai vajag rezerves ceļu, piemēram, e-pasta kopiju vai kļūdu rindu, un cilvēku, kurš saņem brīdinājumu.

  • Dublikāti: viens klients aizpilda formu divas reizes, un CRM izveido divus kontaktus.
  • Nesaskaņoti lauki: formā ir lauks “pakalpojums”, bet CRM tādam nav vietas, tāpēc informācija pazūd.
  • Klusa kļūda: savienojums pārstāj strādāt, un neviens to nepamana vairākas dienas.
  • Nav atbildīgā: pieteikums ir CRM, bet nav norīkots nevienam.
  • Personas dati: formā tiek vākts vairāk datu nekā vajadzīgs, vai nav skaidrs, cik ilgi tie tiek glabāti.

Piemērs: Rockmole pieteikumi no kalkulatoriem tieši CRM

Rockmole mājaslapā ir 11 cenu kalkulatori kanalizācijas, ūdensapgādes un zemes darbiem. Klients redz cenu uzreiz, bez kontaktu ievades. Ja viņš vēlas turpināt, pieteikums no mājaslapas vai kalkulatora nonāk tieši CRM.

CRM satur visu ceļu līdz pieņemšanas–nodošanas aktam: saziņu, tāmi, līgumu, rēķinu, aktu un vēsturi vienuviet. Pēc uzņēmuma datiem lielākā daļa kalkulatoru pieteikumu pārvēršas līgumos. Tas nav tikai integrācijas nopelns, bet integrācija nodrošina, ka neviens pieteikums nepazūd pa ceļam.

Svarīga detaļa: kalkulators jau pirms pieteikuma iedod klientam cenas orientieri. Kad pieteikums nonāk CRM, pārdevējs zina, par kādu darbu un kādu summu ir runa, un saruna sākas no konkrētas vietas.

Kā sākt: kontrolsaraksts pirms integrācijas

Pirms izvēlaties, vai savienot formu ar CRM caur integrāciju platformu vai tiešu API, atbildiet uz šiem jautājumiem. Tie noteiks lielāko daļu darba.

Pēc ieviešanas iesniedziet dažus testa pieteikumus ar dažādiem datiem: pilnu formu, formu ar jau zināmu e-pastu un e-pastu bez formas. Pārbaudiet, vai katrs nonāca pareizajā vietā, pie pareizā cilvēka un ar pareizajiem laukiem.

  • Kuri lauki formā ir patiešām vajadzīgi, un kur katrs no tiem nonāk CRM?
  • Pēc kā atpazīt esošu klientu: e-pasta, tālruņa vai uzņēmuma reģistrācijas numura?
  • Kā pieteikums tiek norīkots atbildīgajam, un kas notiek, ja viņš ir prom?
  • Kurā laikā jāsniedz pirmā atbilde, un kad sistēma izveido atgādinājumu?
  • Kurš saņem brīdinājumu, ja savienojums neizdodas?
  • Kāds ir datu apstrādes pamats un glabāšanas termiņš saskaņā ar VDAR?

Personas dati un atbildība

Formas dati ir personas dati, tāpēc uz tiem attiecas Vispārīgā datu aizsardzības regula (VDAR). Praktiski tas nozīmē: vāciet tikai tos datus, kas vajadzīgi pieteikuma apstrādei, skaidri norādiet, kam tie tiks izmantoti, un nosakiet, cik ilgi tie tiek glabāti CRM.

Tāpat izlemiet, kurai sistēmai pieder katrs dati. Ja kontaktu var mainīt gan CRM, gan grāmatvedībā, jānosaka, kura sistēma ir galvenā. Tas pasargā no situācijas, kad divas sistēmas viena otru pārraksta.

Visbeidzot, ierobežojiet piekļuvi. Integrācijai vajag tikai tās tiesības, kas nepieciešamas pieteikumu izveidei, nevis pilnu administratora piekļuvi visai CRM. Piekļuves atslēgas glabājiet drošā vietā un ziniet, kurš tās var nomainīt.

Avoti