Vertikāla SaaS izveide vecās skolas nozarē: ko NEDRĪKST darīt

Kad GrubMarket iegādājās Sviestu, tas iezīmēja vienas nodaļas beigas un citas sākumu. Kā dibinātājam ceļojums bija neticams — pilns ar grūti nopelnītām, dažreiz sāpīgām mācībām. Tagad es vēlos dalīties ar dažiem no šiem ieskatiem, lai jūs, cerams, varētu apiet dažus šķēršļus, ar kuriem saskaramies, veidojot jūsu nākamo starta uzņēmumu.

Mūsu izcelsmes stāsts

Kad 2020. gadā sākās pandēmija, es un mans līdzdibinātājs uzsākām pakalpojumu Butter, apzinoties neizmantotu iespēju pārtikas rūpniecībā. Bloķēšana mudināja uzņēmumus pieņemt digitālos risinājumus — tādas programmatūras kā Toast, DoorDash un Shopify piedzīvoja strauju izaugsmi, un mēs uzskatījām, ka pārtikas piegādes ķēdes tehnoloģiju kopums ir nobriedis COVID digitālā aizmugurējā vēja dēļ.

Izcēlās divas galvenās problēmas:

1. Pavāri joprojām pasūtīja sastāvdaļas vecmodīgā veidā — izmantojot starpliktuvi, papīra pasūtījumu ceļvežus un zvanot vai sūtot īsziņas saviem piegādātājiem. Pēc visa tā viņi bieži vien nenojauta, kas patiesībā parādīsies viņu virtuvēs līdz nākamajam rītam. Iedomājieties ikdienas stresu, raizējoties par to, vai jūs patiešām varat pasniegt šo ribeye vai cioppino savā ēdienkartē!

   
   

2. Vairumtirgotājiem, pavāru pārdevējiem, bez modernām tehnoloģijām klājās vēl sliktāk. Viņi izmantoja 90. gadu tehnoloģijas: manuāla pasūtījuma ievade no tekstiem vai balss pasta ziņojumiem, novecojušas DOS ERP sistēmas un krājumu skaita izsekošana Excel izklājlapās. Maksājumi joprojām tika apstrādāti galvenokārt ar papīra čekiem! Tikai klientu pasūtījumu ievadīšana viņu sistēmās varētu apēst sešas stundas viņu diennakts — laiks, ko varētu pavadīt uzņēmuma izaugsmei.

Mēs pavadījām dažus mēnešus, ēnot piegādātāju darbplūsmas pulksten 3:00, un domājām, ka mums ir atbilde. Mūsu plāns būtībā sastāvēja no 3 komponentiem:

1. Modernizējiet savas novecojušas sistēmas, izmantojot visaptverošu mākoņdatošanas ERP, kas varētu aptvert galvenās darbplūsmas un kalpot kā viņu " ” – sniedzot mums ārkārtīgi augstu lipīgumu un iesaistīšanos;

   
   

2. Integrējiet finanšu pakalpojumus, piemēram, maksājumus, aizdevumus, algu sarakstu utt., lai krasi palielinātu klienta ACV (a16z slavens par jauno ar finanšu pakalpojumiem nodrošināto vertikālo SaaS vilni 2020. gadā, tāpēc jutāmies pārliecināti);

   
   

3. Ieviesiet netraucētu saziņas procesu gan šefpavāriem, gan vairumtirgotājiem, izmantojot DoorDash līdzīgu lietotni pasūtīšanai, kas mudinātu vairāk pārdevēju pievienoties platformai, radot spararata tīkla izaugsmes efektu (es melotu, sakot, ka Choco mūs neietekmēja , cita pasūtīšanas lietotne );

Šķita, ka tas ir bezjēdzīgi. Bet mēs kļūdījāmies — tiešām kļūdījāmies.

1. slazds: inženiertehniskā sarežģītība un pielāgošana

Mēs sapratām, ka modernas ERP izveide būtu vienkārša. Vecās sistēmas acīmredzami bija novecojušas — cik grūti varētu būt izveidot kaut ko labāku? Mēs demonstrējām prototipu dažiem vietējiem klientiem un saņēmām izmēģinājuma intereses, tāpēc nolēmām izmantot ēku. Tomēr nākamais posms izvērtās par milzīgu cīņu.

Lai gan mēs novērsām dažas klientu tehniskās problēmas, piemēram, vietējā servera atteices riska novēršanu, nozares prasības bija daudz daudzveidīgākas, nekā mēs domājām. Ikvienam potenciālajam piegādātājam bija īpašas prasības, lai faktiski sāktu darbu: pielāgoti īsinājumtaustiņi katrai darbībai, precīzi kolonnu izkārtojumi datu ievades ekrānos, unikāli rēķinu un noliktavas izdruku formāti un pat informācija, kas jāparāda vēžveidīgo izsekojamības tagiem.

Katra pielāgošana pārvērtās par melno caurumu inženiertehniskajiem resursiem. Tas, ko mēs uzskatījām par racionalizētu risinājumu, kļuva par īpaši pielāgotu produktu, kuram bija nepieciešami pastāvīgi pielāgojumi un izstrādes cikli, lai apmierinātu katra klienta vajadzības un nodrošinātu nākamā pakāpeniskā darījuma noslēgšanu. Mūsu inženiertehniskais budžets palielinājās, cenšoties sekot līdzi. Ķīlis, uz kuru bijām cerējuši, izrādījās milzīgs zvērs. Tas nebija mērogs.

(Starp citu: es nesen redzēju YC jaunām ERP programmatūrām — lūdzu: tiešām, tiešām pārdomājiet to, ja vēlaties nolēkt pa šo trušu caurumu.)

2. slazds: ilgs pārdošanas cikls

Pārslēgšanās uz ERP sistēmu nav kā tālruņa programmatūras jaunināšana — tā ir vairāk kā atvērta sirds operācija, kurā tiek veikta dzīva, elpojoša operācija, kuras ikvienu aspektu jūs ietekmēsit, sākot no noliktavas, iepirkuma, grāmatvedības un pārdošanas nodaļām. Klienti vilcinājās, jo zināja, cik traucējošs process var būt. Daudzi atlika lēmuma pieņemšanu pēc iespējas ilgāk, lai gan viņu pašreizējās sistēmas viņiem acīmredzami maksā laiku un naudu. Pat tad, kad īpašnieki (bieži vien galvenais ekonomiskais pircējs) vēlējās mainīt uzņēmumu, sarežģītā darbplūsma nozīmē, ka viņiem bija vajadzīgs katras nodaļas komforts un iepirkšanās, tādējādi ievērojami paildzinot procesu.

Iespējams, arī vecās skolas darbplūsmu dēļ lielākā daļa pārtikas izplatītāju/vairumtirgotāju, uz kuriem mēs vērsāmies, tik tikko spēja noturēt galvu virs ūdens, nemaz nerunājot par aktīvu jaunas programmatūras iepirkšanos. Tas ir īpaši slikti restorānu (to galaklientu) noslogotajās sezonās, kas būtībā ierobežo mūsu zelta pārdošanas logu tikai agrā pavasarī un rudens vidū.

Šis garais pārdošanas un adopcijas cikls mums bija slepkava. Lai gan mēs piedāvājām nepārprotamu uzlabojumu, uzņēmumu panākšana vienmēr bija sarežģīta cīņa — it īpaši, ja tas ietvēra to pamatdarbību. Pat beigās mūsu darījuma noslēgšanas līmenis bija 1/5–1/3 no mūsu modeļa mērķa. Pārāk daudz nepabeigtu darbu, pārāk maz paveikto darījumu.

3. slazds: zema vēlme maksāt / ilgs ieņēmumu aktivizēšanas periods

Lielākais šoks nāca ar cenu noteikšanu. Daudziem no šiem uzņēmumiem bija ļoti maza peļņa — bieži vien pat 5%, ja tāda ir. Lielākajai daļai no viņiem prātā nāk tikai ieņēmumi — piedāvāt viņiem jebko, bet parasti tas ir grūts solis. Viņi bija pieraduši maksāt 80 USD mēnesī par QuickBooks, un likt viņiem maksāt par pilna mēroga ERP jaunināšanu ar likmi, kas attaisnoja mūsu izstrādes izmaksas, bija milzīgs izaicinājums.

Mēs gaidījām, ka fintech un pasūtīšanas lietotņu komponenti ievērojami paplašinās katra klienta ACV, pārsniedzot tradicionālo SaaS abonementu, un viņi to darīja... tikai uz papīra.

Patiesībā maksājumu / lietotņu lietošanas ieņēmumu aktivizēšana arī prasīja ārkārtīgi ilgu laiku — papildus jau tā garajam ERP pārdošanas ciklam, kas aprakstīts iepriekš. Gan maksājumu, gan e-komercijas lietotņu jomā adopcija vairāk bija atkarīga no gala restorānu/mazumtirgotāju klientu vēlmēm, kas arī ir vecās skolas gaitas. Pārdevēji nevēlējās piespiest klientus norēķināties ar kredītkarti, un daudzi klienti joprojām spītīgi deva priekšroku zvanīšanai/īsziņu sūtīšanai, lai pasūtītu (apšaubāmi nepatiesas) drošības sajūtas dēļ, par ko viņiem būtu labāk parūpēties.

Gala rezultāts: parasti bija nepieciešami 2–3 mēneši smagas pūles, lai sasniegtu 20–30% no mērķa ieviešanas un pievienotajiem ieņēmumiem. Tas vienkārši ir pārāk daudz pūļu pārāk maziem ieņēmumiem.

4. slazds: Pārāk daudz likmju vienlaikus

Visbeidzot, mēs kā organizācija arī cietām no pārāk daudzām vienlaicīgām likmēm vienlaikus.

Šeit es izlaidīšu dažas detaļas, jo šis raksts ir paredzēts, lai izceltu galvenās radušās problēmas un gūtās mācības, nevis lai soli pa solim atstāstītu visus eksperimentus, ko esam izmēģinājuši ceļojuma laikā. Pietiek pateikt, ka mums neizdevās atrast īstu ķīli, pirms mēģinājām arī atbloķēt papildu ieņēmumu plūsmas un spararata tīkla efektus. Mēs cīnījāmies ar liela mēroga kampaņu 3 frontēs, kad mums vajadzēja palikt partizānu kara režīmā, lai nodrošinātu vienu lielu uzvaru.

Šī izpildes problēma nozīmēja, ka mēs nevarējām ātri iteratīvi pārbaudīt hipotēzes, un komanda sāka izdegt. Līdz iegādes piedāvājuma nākšanai vēl bija jāpārbauda vairāki veidi, kā būtu, piemēram, virzība uz augšu pārtikas piegādes ķēdē, kur labākas uzņēmējdarbības peļņas normas var nodrošināt augstākus ACV, vai mūsu jaunā vieglā, ar mākslīgo intelektu darbināmo, vieglā tirgus virzība. ķīļveida izstrādājumus, taču pēc gandrīz 4 gadu būvniecības mēs nolēmām savus produktus un tehnoloģijas nodot kādam, kam jau ir izveidots izplatīšanas kanāls.

Mācības, ko guvām grūtā ceļā

Nepārprotiet mani nepareizi — komanda un es darījām daudzas lietas, ar kurām lepojos: cēlāmies pulksten 2:00 un burtiski gulējām noliktavās nedēļām ilgi, lai nodrošinātu veiksmīgu iestāšanos, izveidojām ļoti sarežģītu, vienlaikus arī intuitīvu, klientu iecienītu programmatūru, izstrādājām stingra ieviešanas rokasgrāmata, un sarakstu var turpināt. Tomēr lielajā shēmā mums neizdevās izveidot riska biznesu, kas faktiski palielinājās.

Mūsu pieredze mums mācīja vienu lielu mācību: neiedomājieties ideju, kas balstīta tikai uz augsta līmeņa tēzēm. Klausieties, ko saka cilvēki uz vietas, noliktavā un aizmugures mājā – runājiet ar cilvēkiem patiesības meklēšanas labad, nevis atkārtoti apstiprinot aizspriedumus.

Lai izveidotu veiksmīgu produktu, jo īpaši vecās skolas nozarēs, jums ir nepieciešamas šādas lietas:

1. **Cilvēki, kuriem šī problēma ļoti rūp.**Ja sāpes, kas rodas, paliekot nemainīgas, neatsver pārmaiņu radīto berzi, neviens netraucēs pārslēgt sistēmas neatkarīgi no tā, cik lielisks ir jūsu produkts vai jūsu redzējums. Inerce ir spēcīga, bet pārmaiņām ir nepieciešami tikai daži katalizatori.
   

2. **Pietiekami dziļas kabatas.**Ja jūsu klienti nevar atļauties risinājumu, visa jūsu sniegtā vērtība nespēs kompensēt jūsu ienākumus.
   

3. 10 reizes labāka produkta pieredze nekā viņiem jau ir. Jo tradicionālāki ir jūsu klienti, jo krasākiem uzlabojumiem ir jābūt. Risiniet grūtākās problēmas viņu pasaulē, jo ir iemesls, kāpēc viņi ir iestrēguši tik ilgi.

   
   

4. Vienkāršība ir karalis. Jūsu sākotnējam ķīļveida produktam jābūt ļoti vienkārši lietojamam un jāaptver viena pamata klientu vienība. Vai pārdodat greznu japāņu bidē vai maināt visu santehniku?

Dažas niansētākas piezīmes: Es nesaku, ka jūsu startēšana neizdosies bez visiem iepriekš minētajiem kritērijiem, taču viņu klātbūtne kopā parasti nozīmē skaidru uzvarētāju ceļu.

Lai nodrošinātu veiksmīgu SaaS startēšanu, darījumu apjomam ir jābūt samērojamam ar laiku, kas nepieciešams to slēgšanai. Savā rakstā " ”, Deivids Sakss iepazīstināja ar darījuma lieluma/cikla laika kvadrantu, lai palīdzētu skaidri vizualizēt attiecības. Es ļoti iesaku to izlasīt pilnībā, taču TL;DR ir vai nu augsts ACV / zems darījuma ātrums, vai arī otrādi, tas var būt pareizi, taču, ja abi ir zemi, tas nozīmē jūsu uzņēmuma nāvi.

Atgriezties pie 4 iepriekš minētajiem kritērijiem — ja jūsu mērķa klientiem nav pietiekami dziļas kabatas, bet jums ir kvalitatīvs produkts ar īsu pārdošanas un iekļaušanas ciklu, varat uzvarēt MVU kategorijā ar ātru darījumu. Ja, no otras puses, jūsu produkts ir sarežģīts, taču piedāvā atšķirīgus vērtības piedāvājumus, par kuriem klienti ir gatavi maksāt, jūs varat nodrošināt ievērojamus darījumus uzņēmuma kvadrantā.

Taču Sviesta gadījumā mēs diemžēl iekļuvām lēnā darījuma ātruma + zemā ACV nāves kvadrantā (precīzāk sakot, ACV nebija ļoti zems, ņemot vērā papildu ieņēmumu plūsmas, taču darījuma ātrums ar pilnu ieņēmumu aktivizēšanas laika grafiku ne tikai lēni – tas bija gliemežu temps).

Pēdējā doma

Atskatoties, mēs par zemu novērtējām vertikālās SaaS izveides sarežģītību telpā, kas balstās uz dziļi iesakņojušos praksi un novecojušām tehnoloģijām. Mēs domājām, ka ar digitāla risinājuma piedāvāšanu pietiks, lai veicinātu adopciju. Tā vietā mēs uzzinājām, ka jums ir jāpierāda, ka jūsu produkts spēj nodrošināt būtiskus uzlabojumus tam, kas viņiem jau ir, viņiem saprotamos veidos, lai apmierinātu viņu vajadzības — jo, ja tas uzreiz neizcelsies kā piemērots, tas paliks spēkā. uz to, ko viņi zina.

Sekojiet līdzi 2. daļai, kurā es aplūkošu, kā mākslīgais intelekts paver jaunas iespējas, kas darbojas šajās vecās skolas telpās, un kā mēs to izmantojam, lai atrisinātu strupceļus.