Prodaja koja traje kvartalima izašla je iz mailova i tablica
Generički CRM ne modelira prodaju koja traje kvartalima i uključuje više partnera. Alat je namjerno uzak i trenutačno je u pilotu.
- $25–60k
- godišnja vrijednost licence
- Quarters
- uobičajeni prodajni ciklus
- 1 vertical
- namjerno uzak fokus
- Pilot
- trenutna faza

Polazna situacija
U ovoj se djelatnosti prodaja odvija kroz formalne nabavne postupke, a ciklusi traju kvartalima. Prilike su često poznate mjesecima unaprijed i svaka prolazi kroz iste korake: kvalifikaciju, izradu ponude, pregovore i dodjelu posla. Svaka faza traži vlastite dokumente, odobrenja i provjere usklađenosti, a uz vlastiti tim u poslu sudjeluju i vanjski partneri: podizvođači, partneri u zajedničkoj ponudi i osobe koje daju odobrenja.
Informacije o jednoj prilici pritom žive na pet mjesta: u CRM-u, u e-pošti, u kalendarima, na dijeljenim diskovima i u tablicama. Zbog toga faza u CRM-u može izgledati dovršeno, a da neki obavezan dokument zapravo nedostaje. To se obično otkrije tek kad postane problem.
Što je trebalo riješiti
Očito rješenje bilo bi prilagoditi generički CRM: dodati polja, preimenovati faze, složiti nekoliko prikaza. To ovdje ne pokriva ono najvažnije. U generičkom CRM-u faza je samo oznaka koju svatko može promijeniti; sustav ne provjerava postoje li traženi dokumenti niti tko ih je odobrio, a sudjelovanje vanjskih partnera uopće ne modelira. Pravila procesa tako ostaju u glavama ljudi i u tablicama pokraj alata, umjesto u samom alatu.
Trebalo je, dakle, riješiti dvije stvari: da se obavezni koraci ne mogu preskočiti i da sve što se uz jednu priliku događa, uključujući rad partnera, ostane na jednom mjestu.
Što je izgrađeno
Umjesto još jedne prilagodbe generičkog alata, izgrađen je proizvod namjerno ograničen na jednu industriju i jedan model procesa.
Ključna odluka: faze više nisu oznake na zapisu, nego kontrolne točke koje sustav provodi. Prijelaz u sljedeću fazu nije moguć dok traženi dokumenti i odobrenja ne postoje. Svaki vanjski partner ima jasno definiranu ulogu na prilici. Poruke, sastanci i dokumenti vežu se uz priliku na koju se odnose, pa cijela povijest ostaje dostupna za pregled: što je napravljeno, kada i uz koje dokumente.
Kako sustav radi u praksi
Pozadinski dio napisan je u Pythonu i sadrži pravila procesa: što svaka faza traži i pod kojim se uvjetima smije zatvoriti. Postgres čuva prilike, faze, dokumente i revizijski trag; u formalnim nabavnim postupcima zapis o tome kako je postupak vođen važan je koliko i ishod. Microsoft Graph povezuje e-poštu, kalendare i dokumente koje tim već koristi, pa se zapis o prilici dopunjuje bez ručnog prepisivanja. React sučelje prati način na koji tim stvarno radi: prilike po fazama, dokumenti po prilikama, partneri po ulogama.
U svakodnevnom radu to izgleda ovako: kad netko pokuša prebaciti priliku iz izrade ponude u pregovore, a jedan od traženih dokumenata nedostaje, sustav prijelaz odbije i navede što nedostaje. Kad se vanjski partner uključi u ponudu, njegova uloga i dokumenti vode se na istoj prilici kao i rad vlastitog tima.
Što se promijenilo
Proizvod je trenutačno u pilot-fazi. Ugovoren je jedan plaćeni pilot, a sustav se provjerava u malom broju pilot-okruženja, biranih prema tome koliko dobro odgovaraju procesu.
Ono što se već vidi: dokumenti koji su bili raspršeni po sandučićima i diskovima sada se povezuju u jedan zapis po prilici, a faza više ne može izgledati dovršeno dok nešto obavezno nedostaje. Rani dojmovi iz pilota upućuju i na to da dijelovi ciklusa koje sustav izravno vodi teku brže, ali to su za sada opažanja, ne izmjeren rezultat. Trenutačni fokus je dokazati da model procesa odgovara stvarnom radu i doraditi ga ondje gdje ne odgovara; širenje na više pilota dolazi tek nakon toga.
Što ovaj primjer pokazuje
Kad proces ima stroga pravila, a alati ih samo bilježe umjesto da ih provode, pravila završe u tablicama i u glavama ljudi. Ponekad odgovor nije još jedan prilagođeni prikaz u CRM-u, nego manji, namjenski alat izgrađen oko stvarnog tijeka rada. Takav alat ne mora raditi sve; mora točno provoditi ono što je u procesu obavezno.
Tako pristupamo i drugim poslovima: prvo razumjeti proces do razine pojedinog dokumenta i odobrenja, zatim izgraditi najmanji sustav koji ta pravila stvarno provodi, pa ga provjeriti u stvarnom radu prije bilo kakvog širenja. Ako u Vašem poslu postoji proces koji alati samo evidentiraju, a ne vode, ovakav pristup vrijedi razmotriti.
PythonPostgresReactMicrosoft GraphDomain workflow engine
Imate sličan zadatak?
Trideset minuta o jednom procesu: što se danas radi ručno i može li ga sustav preuzeti. Besplatno, bez prezentacije.
Dogovorite besplatan razgovor