Vertikális SaaS építése egy régi iskolai iparágban: mit NE tegyünk

Amikor a Buttert a GrubMarket felvásárolta, az egyik fejezet végét és egy másik kezdetét jelentette. Alapítóként az utazás hihetetlen volt – tele nehezen megszerzett, néha fájdalmas leckékkel. Most szeretnék megosztani néhányat ezekből a meglátásokból, hogy remélhetőleg megkerülhessen néhány akadályt, amelyet a következő startup felépítése során ütköztünk.

Eredetünk története

Amikor 2020-ban kitört a világjárvány, társalapítómmal elindítottuk a Buttert, felismerve egy kiaknázatlan lehetőséget az élelmiszeriparban. A bezárások arra késztették a vállalkozásokat, hogy digitális megoldásokat alkalmazzanak – az olyan szoftverek, mint a Toast, a DoorDash és a Shopify robbanásszerű növekedést produkáltak –, és úgy gondoltuk, hogy az élelmiszer-ellátási lánc technológiai halmaza megérett a COVID digitális hátszélének megzavarására.

Két fő probléma merült fel:

1. A szakácsok még mindig a régimódi módon rendelték meg a hozzávalókat – vágólap, papír rendelési útmutatók segítségével, valamint felhívták vagy SMS-ben küldték a beszállítóikat. Mindezek után gyakran fogalmuk sem volt, hogy valójában mi fog megjelenni a konyhájukban egészen másnap reggelig. Képzelje el a napi stresszt, amikor azon aggódik, hogy vajon fel tudja-e kínálni a ribeye-t vagy a cioppino-t az étlapján!

   
   

2. A nagykereskedők, a szakácsok árusai még rosszabbul jártak modern technika nélkül. Közvetlenül az 1990-es évek technológiáját használták: kézi rendelés bevitelt szövegekből vagy hangpostaüzenetekből, elavult DOS ERP-rendszereket és a készletszámlálás követését Excel-táblázatokban. A kifizetéseket továbbra is többnyire papírcsekkekkel bonyolították le! A vevői rendelések beírása a rendszerükbe akár hat órát is felemészthet a napjukból – ez az idő, amit vállalkozásuk fejlesztésére fordíthatnak.

Néhány hónapot töltöttünk a beszállítók munkafolyamatainak árnyékolásával hajnali 3-kor, és azt hittük, megvan a válasz. Tervünk lényegében 3 komponensből állt:

1. Modernizálják elavult rendszereiket egy minden-az-egyben felhőalapú ERP-vel, amely rögzítheti az alapvető munkafolyamatokat és szolgálhat a " nyilvántartási rendszer ” – rendkívül magas ragadósságot és elkötelezettséget biztosít számunkra;

   
   

2. Integrálja a pénzügyi szolgáltatásokat, például a fizetést, a hitelezést, a bérszámfejtést stb., hogy drasztikusan növelje az ügyfél ACV-jét (híresen a16z cikket közölt a pénzügyi szolgáltatások által felhatalmazott vertikális SaaS új hullámáról 2020-ban, így magabiztosnak éreztük magunkat);

   
   

3. Vezessen be egy zökkenőmentes kommunikációs folyamatot mind a szakácsok, mind a nagykereskedők számára, egy DoorDash-szerű alkalmazással a rendeléshez, amely több eladót vonzna a platformhoz való csatlakozásra, lendületes hálózatnövekedési hatást hozva létre (hazudnék, ha azt mondanám, hogy nem volt ránk hatással a Choco , egy másik rendelési alkalmazás meteorikus emelkedés az egyszarvú állapotba );

Úgy tűnt, semmi gond. De tévedtünk – nagyon tévedtünk.

1. buktató: Mérnöki komplexitás és testreszabás

Úgy gondoltuk, hogy egy modern ERP felépítése könnyű lesz. A régi rendszerek nyilvánvalóan elavultak – milyen nehéz lehet valami jobbat felépíteni? A prototípust néhány helyi vásárlónak bemutattuk, és kipróbáltuk, ezért úgy döntöttünk, hogy belevágunk az építkezésbe. A következő szakasz azonban hatalmas küzdelemnek bizonyult.

Miközben az ügyfelek néhány technikai problémáját kiküszöböltük, például a helyi szerverhibák kockázatának kiküszöbölését, az iparág igényei sokkal változatosabbak voltak, mint gondoltuk. Minden beszállítónak sajátos követelményei voltak a tényleges életbe lépéshez: egyéni billentyűparancsok minden művelethez, pontos oszlopelrendezések az adatbeviteli képernyőkön, egyedi formátumok a számlákhoz és a raktárnyomtatásokhoz, és még a kagylók nyomon követési címkéihez megjelenítendő részletek is.

Minden testreszabás fekete lyukká vált a mérnöki erőforrások számára. Amiről azt gondoltuk, hogy egy egyszerűsített megoldás lenne, az egy nagyon testre szabott termék lett, amely folyamatos módosításokat és fejlesztési ciklusokat igényel, hogy megfeleljen minden ügyfél igényeinek, és biztosítsa a következő lépésközi ügylet lezárását. Mérnöki költségvetésünk megnőtt, ahogy igyekeztünk lépést tartani. Az ék, amit reméltünk, óriási vadállatnak bizonyult. Nem volt méretezhető.

(Eltekintve: nemrég láttam az YC RFS-ét új ERP-szoftverekhez – kérem: gondolja át alaposan, ha le akar ugrani abba a nyúlüregbe.)

2. buktató: A hosszú értékesítési ciklus

Az ERP-rendszer váltása nem olyan, mint a telefon szoftverének frissítése – ez inkább egy nyitott szívműtét, ahol egy élő, lélegző műtét zajlik, amelynek minden területére hatással lesz, a raktártól, a beszerzésen át a könyvelésig és az értékesítési osztályokig. A potenciális ügyfelek haboztak, mert tudták, milyen bomlasztó lehet a folyamat. Sokan halogatják a döntést, ameddig csak lehetséges, annak ellenére, hogy jelenlegi rendszereik nyilvánvalóan időbe és pénzbe kerültek. Még akkor is, ha a tulajdonosok (gyakran a fő gazdasági vevő) váltani akartak, az ezzel járó összetett munkafolyamat azt jelenti, hogy minden részleg kényelmére és bevásárlásra volt szükségük, ami súlyosan meghosszabbította a folyamatot.

Talán az old-school munkafolyamatoknak is köszönhető, hogy az általunk megcélzott élelmiszer-forgalmazók/nagykereskedők nagy része alig tudta a fejét a víz fölött tartani, nemhogy aktívan vásárolni új szoftvereket. Ez különösen rossz az éttermek (végfelhasználóik) zsúfolt évszakaiban, ami lényegében csak kora tavasszal és ősz közepére korlátozza az értékesítési időszakot.

Ez a hosszú értékesítési és örökbefogadási ciklus gyilkos volt számunkra. Annak ellenére, hogy egyértelmű javulást kínáltunk, mindig felfelé ívelő csata volt rávenni a vállalkozásokat – különösen, ha az alapvető tevékenységeiket érintette. Az üzletkötési arányunk még a vége felé is a modellcélunk 1/5-1/3-a volt. Túl sok a folyamatban lévő munka, túl kevés a megkötött üzlet.

3. buktató: Alacsony fizetési hajlandóság / hosszú bevételaktiválási időszak

A legnagyobb megrázkódtatást az árazás okozta. Sok ilyen vállalkozás borotvavékony árrésekkel rendelkezett – gyakran 5%, ha az is. Túlnyomó többségük számára csak a bevétel jut eszébe – bármit felajánlani nekik, de általában nehéz feladat. Megszokták, hogy havi 80 dollárt kell fizetni a QuickBooksért, és óriási kihívás volt rávenni őket, hogy fizessenek egy teljes körű ERP-frissítést olyan ütemben, ami indokolta a fejlesztési költségeinket.

Arra számítottunk, hogy a fintech és a rendelési alkalmazás összetevői nagymértékben kibővítik az egyes ügyfelek ACV-jét a hagyományos SaaS-előfizetéseken túl, és ez meg is történt… csak papíron.

Valójában a fizetési/alkalmazáshasználati bevétel aktiválása is rendkívül sokáig tartott – a fent részletezett, amúgy is hosszú ERP értékesítési cikluson felül . Mind a fizetési, mind az e-kereskedelmi alkalmazások terén az elfogadás végül inkább az éttermi/kiskereskedői vásárlók preferenciáitól függött, ami szintén régi iskola. Az eladók nem akarták hitelkártyás fizetésre kényszeríteni az ügyfeleket, és sok vásárló makacsul inkább a rendelésre hívott/sms-ezést részesítette előnyben a (vitathatatlanul hamis) biztonságérzet miatt, jobb lenne, ha így gondoskodnának róla.

A végeredmény: általában 2-3 hónap kemény erőfeszítésbe telt, hogy elérje a célelfogadás és a hozzáadott bevétel 20-30%-át. Ez egyszerűen túl sok erőfeszítés túl kevés bevételhez.

4. buktató: Túl sok fogadás egyszerre

Végül mi, mint szervezet is szenvedtünk attól, hogy túl sok egyidejű fogadásunk volt egyszerre.

Itt kihagyok néhány részletet, mivel ennek a cikknek az a célja, hogy kiemelje a felmerült kulcsfontosságú problémákat és a levont tanulságokat, nem pedig az út során végigkísért kísérletek lépésről lépésre történő bemutatására. Elég azt mondani, hogy nem sikerült igazi éket találnunk, mielőtt további bevételi forrásokat és lendkerék-hálózati hatásokat próbáltunk volna feloldani. Nagyszabású hadjáratot vívtunk 3 fronton, amikor is gerillaharc módban kellett volna maradnunk, hogy egyetlen nagyobb győzelmet arassunk.

Ez a végrehajtási probléma azt jelentette, hogy nem tudtuk gyorsan iteratívan tesztelni a hipotéziseket, és a csapat kezdett kiégni. Mire az akvizíciós ajánlat megérkezett, még mindig több mit kellett volna tesztelni, például feljebb lépni az élelmiszer-ellátási láncban, ahol a jobb üzleti árrések magasabb ACV-t eredményezhetnek, vagy az új, könnyű mesterségesintelligencia-meghajtású modellünk piacra lépésének mértéke. éktermékeket, de közel 4 évnyi építés után úgy döntöttünk, hogy termékeinket és technológiáinkat egy már kiépített értékesítési csatornával rendelkező személyhez visszük.

Nehéz leckék

Félreértés ne essék – a csapat és én sok olyan dolgot csináltunk, amire büszke voltam: hajnali 2-kor felkeltünk, és szó szerint hetekig a raktárakban aludtunk, hogy biztosítsuk a sikeres bevezetést, egy rendkívül összetett, ugyanakkor intuitív, az ügyfelek által kedvelt szoftvert építettünk, fejlesztést egy szigorú végrehajtási játékkönyv, és a lista folytatható. A dolgok nagy tervét tekintve azonban alulmaradtunk egy olyan kockázati vállalkozás felépítésében, amely valójában méreteződött.

Tapasztalataink egy nagy tanulsággal szolgáltak: ne ugorjunk bele egy olyan ötletbe, amely csak magas szintű téziseken alapul. Hallgassa meg, mit mondanak az emberek a földön, a raktárban és a ház mögött – beszéljen az emberekkel az igazságkeresés érdekében, ne pedig az előzetes elképzelések megerősítése érdekében.

Egy sikeres termék felépítéséhez, különösen a régi iskolai iparágakban, a következőkre van szüksége:

1. **Emberek, akiket mélyen érdekel a probléma.**Ha a változatlan maradás fájdalma nem haladja meg a változás okozta súrlódást, akkor senki sem fog zavarni a rendszerváltást, függetlenül attól, hogy milyen nagyszerű a terméke vagy milyen nagyszerű az elképzelése. A tehetetlenség erős, de a változáshoz csak néhány katalizátor kell.
   

2. **Elég mély zsebek.**Ha ügyfelei nem engedhetik meg maguknak a megoldást, az Ön által hozott összes érték nem fogja kárpótolni az eredményt.
   

3. 10-szer jobb termékélmény, mint amivel már rendelkeznek. Minél hagyományosabbak az ügyfelek, annál drasztikusabb fejlesztésre van szükség. Foglalkozz a világ legnehezebb problémáival, mert megvan az oka annak, hogy olyan sokáig kitartanak mellettük.

   
   

4. Az egyszerűség a király. A kezdeti ékterméknek rendkívül egyszerűen alkalmazhatónak kell lennie, és egyetlen alapvető vásárlói egységet kell lefednie. Elad egy díszes japán bidét, vagy kicseréli a teljes vízvezetéket?

Néhány árnyaltabb megjegyzés: Nem azt mondom, hogy a startup kudarcot vall a fenti feltételek nélkül, de ezek együttes jelenléte általában egyértelmű nyerő utat jelent.

A részletek kidolgozása érdekében a SaaS sikeres indítása érdekében az ügyletek méretének arányosnak kell lennie a lezárásukhoz szükséges idővel. cikkében „ A nehézségi arány ” – mutatta be David Sacks az ügyletméret/ciklusidő kvadránsát, hogy segítsen világosan megjeleníteni a kapcsolatot. Nagyon ajánlom, hogy olvassa el teljes egészében, de a TL;DR vagy magas ACV / alacsony ügyleti sebesség, vagy fordítva, lehet, hogy rendben van, de mindkettő alacsony, a cég halálát jelenti.

Visszatérve a fenti 4 kritériumhoz – ha a megcélzott ügyfelei nem rendelkeznek elég mély zsebekkel, de van egy ropogós ékterméke rövid értékesítési + beszállási ciklussal, akkor nyerhet a SMB kategóriában, gyors üzletkötési sebességgel. A másik oldalon, ha a terméke összetett, de különálló értékajánlatokat kínál, amelyekért az ügyfelek hajlandóak felárat fizetni, akkor jelentős üzleteket köthet a vállalati kvadránsban.

A Butter esetében azonban sajnos beleestünk a lassú üzlet sebessége + alacsony ACV halálnegyedbe (pontosabban az ACV nem volt túl alacsony a többletbevételi források miatt, de az ügylet sebessége a teljes bevételaktiválási idővonallal Nem csak lassú – csigatempójú volt).

Végső gondolat

Utólag visszatekintve alábecsültük a vertikális SaaS felépítésének bonyolultságát egy olyan térben, amely mélyen megrögzött gyakorlatokon és elavult technológián alapul. Úgy gondoltuk, hogy egy digitális megoldás felkínálása elegendő lesz az elfogadás elindításához. Ehelyett azt tanultuk meg, hogy bizonyítania kell, hogy terméke jelentős fejlesztéseket tud nyújtani a már meglévőkhöz képest, az általuk értett módokon, hogy megfeleljen az igényeiknek – mert ha nem tűnik ki azonnal a megfelelő illeszkedésből, kitartanak. arra, amit tudnak.

Maradjon velünk a 2. részben, ahol belemerülök abba, hogy a mesterséges intelligencia hogyan nyit új lehetőségeket ezeken a régi iskolai tereken, és hogyan használjuk fel a zsákutcák megoldására.