Kada prvi put otvorite podešavanja CRM platforme i vidite opciju za dodavanje custom polja, reakcija je obično ista: entuzijazam koji brzo preraste u zbunjenost. Šta zapravo treba da se prati? Koji tip polja? Treba li to uopšte biti polje ili nešto sasvim drugo? Dobra vest — custom polja crm sistema nisu komplikovana ako znate gde da počnete.

Zašto standardna polja nikad nisu sasvim dovoljna

Svaki CRM dolazi sa podrazumevanim skupom polja: ime, email, telefon, kompanija, veličina posla. To pokriva 60-70% potreba prosečnog tima. Ali ostatak? Ostatak je ono što vas razlikuje od konkurencije.

Recimo da prodajete B2B softver za industrijska postrojenja. Jedno od vaših ključnih kvalifikacionih pitanja je "Da li kompanija koristi PLC sisteme?" To nije ni u jednom default CRM-u. Bez tog podatka, vaš tim svaki put ponovo pita isto pitanje na prvom pozivu — traćeći i svoje i klijentovo vreme.

Custom polja rešavaju tačno tu prazninu. Ali loše konfigurisana polja stvaraju sopstveni haos.

Konvencije imenovanja — pravilo koje mnogi preskoče

Pre nego što dodate prvo custom polje, dogovorite se oko imenovanja. Ovo zvuči trivijalno, ali posle godinu dana korišćenja CRM-a sa poljima koja su nazvana "Napomena", "Napomena 2", "Staro polje (ne brisati)" i "TEST (Marko)" — haos postaje stvaran problem.

Preporučena konvencija:

  • Prefiks po entitetu — kontakt_, posao_, kompanija_ ispred svakog naziva polja, posebno ako platforma prikazuje polja iz različitih objekata na istom ekranu.
  • Glagolska ili imenička forma, ne skraćenice — posao_tip_klijenta, ne pos_tip_kl. Skraćenice imaju smisla vama danas; neće imati smisla novom članu tima za šest meseci.
  • Samo mala slova i podvlake za interni ključ polja, čak i ako platforma dozvoljava razmake u displayovanom imenu.
  • Verzija ako je polje zamena — posao_ocena_v2 umesto da obrišete staro i izgubite istorijske podatke.

Jedan tim sa kojim smo radili prošle godine imao je 47 custom polja na kontaktu — od toga 12 su bila duplikati ili zastarela. Čišćenje je trajalo tri dana.

Tipovi polja: kada šta birati

Ovo je centralno pitanje. Pogrešan tip polja znači loše izveštaje, frustracije pri unosu i nekonzistentne podatke.

Tip polja Kada ga koristiti Kada ga izbegavati
Kratki tekst Jedinstven identifikator, kratka oznaka Kad ima skup poznatih vrednosti — tu treba dropdown
Dugački tekst Beleške, kontekstualne napomene Filtriranje i reporting — neiskoristiv za analytics
Dropdown (jedna vrednost) Status, kategorija, segment — kad se bira tačno jedna opcija Kad klijent može biti u više kategorija odjednom
Multi-select Industrije, interesi, oznake — kad može biti više vrednosti Kad vam treba strogo jedna vrednost za reporting
Broj Prihodi, broj zaposlenih, godišnji budžet Slobodan unos kada su vrednosti uvek iz skupa (koristite dropdown)
Datum Datum obnove, datum prvog kontakta Praćenje trajanja — tu je bolje numeričko polje
Checkbox (boolean) Dvostepene odluke — da/ne, aktivan/neaktivan Trostepene situacije gde "nije poznato" ima drugačije značenje od "ne"
Formula/kalkulisano Izvedeni podaci — margina, dani od poslednjeg kontakta Ako izvor podataka nije pouzdan, formula samo pojačava greške

Pravilo palca za dropdown vs. multi-select: pitajte se da li biste mogli da izfiltrujete po ovom polju i da vam ima smisla grupacija. Ako imate klijente koji su istovremeno "Partner" i "Krajnji korisnik", dropdown ne može da odslika stvarnost — tu treba multi-select. Ako klijent u jednom trenutku može biti samo u jednoj fazi pipeline-a, multi-select je overkill koji komplikuje izveštaje.

Kada polje više nije dovoljno: eskalacija na custom objekat

Ovo je prelomni trenutak u konfiguraciji svakog ozbiljnijeg CRM-a. Custom polje na kontaktu ili poslu radi odlično dok pratite atribute jednog entiteta. Ali šta kada imate podatke koji imaju sopstvenu složenost?

Klasičan primer: pratite ugovore. Jedan klijent može imati pet aktivnih ugovora, svaki sa svojim datumom, iznosom u EUR, statusom i kontakt osobom na klijentovoj strani. Ako to pokušate da smestite u custom polja na kontaktu, brzo nailazite na zid — ne možete imati "Ugovor 1 — iznos", "Ugovor 2 — iznos" i nastaviti beskonačno.

Vreme je za custom objekat kada:

  1. Entitet koji pratite ima sopstvene atribute (bar 3-4 polja koja mu prirodno pripadaju).
  2. Jedan nadređeni rekord može imati više instanci tog entiteta — jedan klijent, više ugovora; jedan posao, više ponuda.
  3. Potreban vam je reporting na nivou tog entiteta, ne samo na nivou roditeljskog rekorda.
  4. Tim koji radi sa tim podacima je drugačiji od tima koji radi sa kontaktima — npr. pravna služba prati ugovore dok sales prati klijente.

Nasuprot tome, ne treba vam custom objekat za svaku stvar koja ima više od jedne vrednosti. Ako klijent može imati više email adresa, to nije razlog za custom objekat — to je standardna funkcionalnost "email lista" koju većina CRM platformi nativno podržava.

Model podataka i relacije između objekata

Kada dodate custom objekat, sledeće pitanje je kako ga povezati sa ostatkom sistema. CRM-ovi obično podržavaju tri tipa relacija:

Jedan-prema-više (1:N) — Najčešća. Jedan kontakt ima više ugovora. Jedan posao ima više zadataka. Funkcioniše dobro kada roditeljski rekord jasno "poseduje" podređene.

Više-prema-više (M:N) — Komplikovanija, ali neophodna. Jedan kontakt može biti uključen u više poslova; jedan posao može imati više kontakata. Ako vaša platforma to ne podržava nativno, obično postoji workaround kroz junction objekat ili tagove.

Lookup polje — Labavija referenca, bez hijerarhije. Koristite kada veza postoji, ali ni jedan ni drugi rekord ne "poseduje" drugi. Tipično za integracije sa eksternim sistemima.

Greška koja se često pravi: preterano normalizovati model podataka kao u relacionoj bazi. CRM nije SQL server — ponekad je bolje imati redundantno polje na dva mesta nego primoravati prodavce da kliktaju kroz tri nivoa relacija da bi videli jedan podatak.

Organizacija polja po sekcijama i vidljivost po timu

Čak i savršeno osmišljeno polje postaje problem ako je zakopano na dnu formulara koji ima 60 stavki. Svaki ozbiljniji CRM dozvoljava grupisanje polja u sekcije i kontrolu vidljivosti po timu ili roli.

Praktičan pristup: razmislite o tome ko unosi koje podatke i kada. Polja koja popunjava SDR na prvom pozivu treba da budu na vrhu, vidljiva odmah. Polja koja popunjava account manager tek posle potpisanog ugovora mogu biti u posebnoj sekciji koja je savijena po default-u.

Vidljivost po timu smanjuje kognitivni zamor — prodavac ne mora da gleda finansijska polja koja su relevantna samo za tim za naplatu. Ovo se čini kao sitnica dok CRM ne narastu na 30+ polja po entitetu. Tada postane kritično.

Migracija i čišćenje starih custom polja

Dodat neko polje pre dve godine "samo da vidi kako izgleda" i nikad ga uklonilo? Nije usamljeni slučaj. Pre čišćenja, proverite:

  • Koliko rekorda ima popunjenu vrednost u tom polju. Ako je 0-2%, polje se verovatno ne koristi.
  • Da li je polje deo nekog workflow-a, automatizacije ili integracije. Brisanje takvog polja bez provere može da pokvari automatske procese.
  • Da li polje koristi neki izveštaj koji neko zaista čita. CRM-ovi retko upozoravaju na ove zavisnosti automatski.

Dobra praksa je arhiviranje, ne brisanje — preimenujte polje u ARHIVA_staro_ime i sakrijte ga od formulara. Ako niko ne pita za mesec dana, bezbedno ga obrišite.

Za detaljan pregled CRM alata koji podržavaju naprednu konfiguraciju custom polja i objekata, pogledajte naš pregled CRM alata.

Konkretni primeri po industrijama

Konfiguracija zavisi od konteksta. Evo nekoliko primera iz prakse:

SaaS kompanija — Na poslu: posao_tip_licence (dropdown: Starter / Growth / Enterprise), posao_broj_korisnika (broj), posao_godisnji_prihod_eur (broj). Custom objekat: "Pretplata" sa poljima za datum obnove, status i metod plaćanja.

Agencija za digitalni marketing — Na klijentu: klijent_industrija (multi-select), klijent_mesecni_budzet_eur (broj), klijent_platforma (multi-select: Meta / Google / TikTok / LinkedIn). Custom objekat: "Kampanja" vezan za klijenta.

Distributeri i veleprodaja — Na kontaktu: kontakt_tip (dropdown: Kupac / Dobavljač / Partner), kontakt_kreditni_limit_eur (broj). Custom objekat: "Narudžbina" sa sopstvenim lifecycle statusima.

Svaki od ovih primera ilustruje isti princip: model podataka prati poslovni proces, ne obrnuto. Ako osećate da morate da menjate proces da biste ga "uklopili" u CRM — to je znak da custom polja crm sistema nisu dovoljno prilagođena.

Kada je konfiguracija "gotova"

Kratki odgovor: nikad. Dobar model podataka se razvija zajedno sa biznisom. Ono što se menja nije filozofija nego disciplina — ne dodavati novo polje jer je to lako, nego jer rešava konkretan problem.

Pre svakog novog polja, postavite jedno pitanje: koji izveštaj ili koji automatizovani proces neće moći da radi bez ove informacije? Ako odgovor nije jasan, polje verovatno nije potrebno.

Custom polja crm baze su, na kraju, samo alat. Vrednost nije u broju polja — vrednost je u tome koliko dobro vaš CRM oslikava način na koji zapravo radite. Ako vaš tim oseća da CRM "razume" vaš poslovni model, konfiguracija je dobra.