Spąstai „Tiesiog pridėkite atsiliepimų“: ko jūsų paslaugų rinkai iš tikrųjų reikia toliau

Santrauka

Kai viršininkas prašo atsiliepimų, rezervavimo valdiklio ar „dirbtinio intelekto suderinimo“, gundoma sutikti. Tačiau dauguma funkcijų prašymų iš tikrųjų yra progreso jausmo prašymai. Šis straipsnis pateikia šešių žingsnių sistemą, kaip tuos prašymus paversti atgal į tikrąją kliūtį: pasiūlą, paklausą arba pasitikėjimą. Sužinosite, kaip įvertinti, kas jau yra, prieš kuriant, kaip išbandyti brangias idėjas pigiais pakaitalais ir kaip paaiškinti savo „ne dabar“ sąrašą neatrodant užsispyrusiems. Tikslas nėra vengti funkcijų. Tikslas yra sukurti tas kelias, kurios svarbios tinkamu momentu, ir pasakyti tai kalba, kurią neturintis techninių žinių viršininkas gali apginti prieš savo vadovą.

Jūsų viršininkas ką tik įėjo ir pasakė: „Mums reikia atsiliepimų. Kaip tie konkurentai turi.“ Iš tikrųjų jie paprašė ne atsiliepimų. Jie paprašė jausmo, kad rinka progresuoja, o funkcija yra lengviausias būdas parodyti progresą. Problema ta, kad funkcijos yra baisūs progreso pakaitalai. Rinka yra mašina, turinti vieną kliūtį vienu metu — pasiūlą, paklausą arba pasitikėjimą — ir pridėti dalį, kuri nesprendžia dabartinės kliūties, yra tik mašinos, kuri nejuda, poliravimas.

Tai keistai sunkus pokalbis mažoje vidaus rinkodaros komandoje, nes jūsų viršininkas nėra techninis ir jūs nesate generalinis direktorius. Turite pagrįsti kiekvieną sprendimą negalėdami atsiremti į inžinerijos viceprezidentą, kuris su jumis sutiko. Jums reikia argumento, o ne nuomonės. Geros naujienos: argumentą galima pateikti šešiais žingsniais, ir nė vienas iš jų nereikalauja, kad ką nors sukurtumėte. Jie reikalauja, kad mąstytumėte kaip detektyvas ir kalbėtumėte kaip vertėjas.

Pradėkite nuo prisiminimo, kad paslaugų rinka niekada nebuvo neutrali. Jūs visada nusprendžiate, kuri pusė gauna pranašumą: teikėjas, klientas ar jūsų pačių sveikas protas. Turėkite tai omenyje, kai gaunate funkcijų prašymą.

Pirmas žingsnis: įvardykite kliūtį prieš įvardydami funkciją

Paslaugų rinka turi tris judančias dalis: teikėjus, klientus ir pasitikėjimą tarp jų. Jei negalite patenkinti paklausos, nes nėra pakankamai teikėjų, jokia funkcija, gerinanti klientų patirtį, nepadės — kliūtis yra pasiūla. Jei turite teikėjų, bet žmonės nerezervuoja, kliūtis yra paklausa. Jei žmonės rezervuoja, bet dvejoja prieš mokėdami, kliūtis yra pasitikėjimas.

Būdas išsiaiškinti, su kuria kliūtimi susiduriate, yra užduoti kelis kvailus klausimus. Tarkime, valdote vietinę valymo paslaugų rinką. Jūsų viršininkas nori „vieno paspaudimo rezervavimo“ funkcijos. Prieš net pradėdami kalbėti apie rezervavimą, paklauskite: „Kaip greitai reaguojame, kai klientas susisiekia?“ Jei atsakymas yra „kitą dieną“, jums nereikia rezervavimo valdiklio; jums reikia telefono skambučio. Jei atsakymas yra „reaguojame per dešimt minučių, bet klientai vis tiek nerezervuoja“, galbūt kaina neaiški arba teikėjo profilis tuščias. Mygtukas neišspręs nė vieno. Jei atsakymas yra „klientai rezervuoja, bet paskui atšaukia“, turite pasitikėjimo problemą, o ne tvarkaraščio problemą.

Žingsnis yra paversti viršininko funkciją į klausimą apie kliūtį. Jei kliūtis yra pasiūla, jokia į klientą nukreipta funkcija nepadės. Gali tekti praleisti mėnesį rankiniu būdu verbuojant teikėjus — senamadiškas, nepatrauklus, bet visiškai efektyvus būdas pradėti rinką.

Antras žingsnis: paverskite „turėtume pridėti X“ skaičiumi

Viršininkų nejaudina kliūtys; juos jaudina skaičiai, kuriuos jie gali pakartoti. Taigi paimkite funkcijos prašymą ir paverskite jį metrika, kuri įrodytų, ar funkcija svarbi. Tai vienas naudingiausių įpročių, kurį galite išsiugdyti ne techninėje darbo vietoje.

Tarkime, prašymas yra „mums reikia dirbtinio intelekto suderinimo“, nes jūsų viršininkas perskaitė tendencijų straipsnį apie tai, kaip dirbtiniu intelektu pagrįsta automatizacija pakeis paslaugų rinkas. Paspauskite stabdžius. Paklauskite: „Koks skaičius parodytų, kad suderinimas yra sugedęs?“ Galbūt tai yra gaunamų užklausų procentas, kurios suderinamos su teikėju per 24 valandas. Jei tas skaičius mažas, nes mieste turite tik tris teikėjus, DI yra žaislas; jums reikia pasiūlos. Jei skaičius didelis, bet klientai vis tiek nerezervuoja, problema yra ne suderinimas — o kainodara ar pasitikėjimas. Dabar kalbate apie tikrus duomenis, o ne apie madingus žodžius.

Kai tai darote, neišgalvokite skaičiaus, kad pagrįstumėte savo argumentą. Per daug komandų sugalvoja metriką tik tam, kad nutildytų idėją, ir taip gaunate viršininką, kuris visiškai nustoja pasitikėti jūsų skaičiais. Naudokite visus netvarkingus, mažus, sąžiningus duomenis, kuriuos iš tikrųjų turite — net jei tai tik dešimt klientų ir žinote visų jų vardus. Tikras skaičius iš mažos operacijos pranoksta išgalvotą skaičių iš pristatymo skaidrių.

Trečias žingsnis: naudokite 21 funkcijos sąrašą kaip filtrą, o ne kaip pirkinių sąrašą

Internete sklando naudingas sąrašas, kuriame išvardytos 21 funkcija, kurių paslaugų rinkai gali prireikti 2026 m. — teikėjų įtraukimas, pasitikėjimas ir tikrinimas, atradimas, saugus mokėjimas ir eskrow, analitika ir panašiai. Jis yra iš Rigby tinklaraščio, ir tai puiki audito priemonė. Problema ta, kad 21 elemento sąrašo egzistavimas verčia kiekvieną nesukurtą funkciją jaustis kaip skola. Jūsų viršininkas jį perskaito ir staiga pagalvoja, kad atsiliekate.

Jūs neatsiliekate. Sąrašas yra žemėlapis visko, ką galėtumėte sukurti, o ne įsakymas juos sukurti. Naudokite jį kaip filtrą: peržiūrėkite visus 21 ir paklauskite: „Kuris atitinka kliūtį, kurią įvardijome pirmame žingsnyje?“ Jei jus riboja pasiūla, „saugus mokėjimas ir eskrow“ yra puikus dalykas, bet nepritrauks nė vieno naujo teikėjo. Jei jus riboja paklausa, „teikėjų įtraukimas“ iš tikrųjų gali būti svarbiausias jūsų rinkodaros turtas, nes tuščias puslapis neišlaikys nė vieno kliento. Jei jus riboja pasitikėjimas, „ginčų sprendimas“ ankstyvaisiais etapais yra svarbesnis nei „teikėjų įvertinimai“.

Čia taip pat galite pagrįsti, kad jūsų rinkai dar nereikia būti stebuklinga programinės įrangos platforma. Ji turi veikti, net jei tai reiškia užklausų rūšiavimą rankiniu būdu. Konciergo versija rinkos nėra žingsnis atgal; tai žingsnis pirmyn, kuris atrodo kaip skaičiuoklės ir tolesni el. laiškai.

Ketvirtas žingsnis: imituokite funkciją prieš ją sukurdami

Tai pats labiausiai nuvertintas žingsnis visame argumente. Beveik kiekvieną funkciją galima imituoti rankiniu būdu, kol ji tampa projektu.

Jūsų viršininkas nori susitikimų planavimo integracijos. Užuot tyrinėję įrankius ir lyginę nemokamus Calendly, Acuity ir Setmore planus, kol akys pavargs, padarykite taip: sukurkite paprastą puslapį, kuriame rašoma „Užsakykite nemokamą konsultaciją“, ir nukreipkite žmones el. paštu atsiųsti jums tinkamą laiką. Tada rankiniu būdu įrašykite tą laiką į teikėjo kalendorių ir atsakykite patvirtinimu. Darykite tai savaitę. Jei gausite tik tylą, problema nėra tvarkaraštis; problema ta, kad niekas nenori susitikimo pakankamai, kad parašytų el. laišką. Jei gaunate el. laiškų, bet daug žmonių niekada nebaigia, galbūt tikra susitikimų nuoroda padidintų pasitikėjimą. Tačiau dabar įrodėte, kad jums to reikia už labai mažą kainą.

Rankinė versija sukuria konkretų artefaktą — tikrus el. laiškus — vietoj abstraktaus „turėtume integruoti“. Kai rankinis bandymas veikia, galite drąsiai pasirinkti tinkamą įrankį. Kai jis nepavyksta, sutaupėte mėnesį darbo ir susitikimą apie API raktus. Kai pasiekiate įrankio pasirinkimo tašką, iššūkis yra pasirinkti tinkamą momentui, o ne patį įmantriausią. Yra pakankamai apžvalgų, įskaitant vieną iš Zapier, kad galva apsisuktų.

Kai ten pateksite, klausimas nėra „kuri programa turi daugiausiai funkcijų?“. Klausimas yra „kiek mažiausiai kodo turime parašyti, kad išlaikytume rankinį darbo srautą gyvą?“ Tai tikrai kitoks klausimas, ir būtent jis apsaugo jūsų veiksmų planą nuo padrikų integracijų.

Penktas žingsnis: atidėkite pasitikėjimo mechanizmą, kol bus ką įvertinti

Teikėjų įvertinimai yra dažniausiai prašoma funkcija paslaugų rinkose, ir tam yra gera priežastis — pasitikėjimas yra visas žaidimas. Tačiau įvertinimo sistemos pridėjimas prieš turint nuolatinį atliktų darbų srautą yra blogiau nei jos neturėjimas. Gausite tris atsiliepimus, iš kurių du yra iš teikėjo draugų, ir skaičiai bus beprasmiai. Žvaigždučių vidurkis 4,7 su dviem atsiliepimais nėra tas pats, kas 4,7 su keturiais šimtais atsiliepimų, bet klientai neapdoroja šio niuanso; jie tiesiog mato 4,7. Dar blogiau, tuščia „atsiliepimų“ skiltis teikėjo profilyje klientams sako, kad niekas niekada nebaigė darbo su šiuo asmeniu. Tai pasitikėjimo vakuumas, kurį sukūrėte bandydami sukurti pasitikėjimą.

Pirmiausia sukurkite sandorį, tada ant jo uždėkite įvertinimo sistemą. Tai prieštaringiausia dalis: pavojingiausia funkcija yra ta, kurią ką tik paleido jūsų didžiausias konkurentas. Matote jų žvaigždes ir rekomendacijas ir jaučiatės pavėlavę. Tačiau jie turėjo šimtus sandorių, kol gavo tas žvaigždes. Negalite peršokti į to proceso pabaigą pridėdami valdiklį.

Kai būsite pasiruošę atsiliepimams, jūsų įvertinimo sistemos dizainas nusipelno atskiro kruopštaus apmąstymo — ne todėl, kad žvaigždės yra stebuklingos, o todėl, kad nuo jų priklauso visas jūsų rinkos patikimumas. Iki tol skirkite savo energiją tam, kad pirmieji darbai būtų atlikti gerai, ir klauskite klientų, ką jie pasakytų apie teikėją tekstiniu pranešimu. Tai nėra įvertinimo sistema; tai žaliava jai.

Šeštas žingsnis: aiškiai pasakykite, ko nekursite

Ginamiausia pozicija funkcijų susitikime nėra „taip“ arba „ne“; tai „štai ką darome vietoj to“. Sukurkite lentelę su trimis stulpeliais: prašymas, tikroji kliūtis ir ką darysite per ateinančias 90 dienų. Šis artefaktas pakartoja viršininko kalbą, parodydamas logiką — ir jį lengva atsispausdinti ir nunešti aukštesniam vadovui.

Prašymas	Tikroji kliūtis	Ką darysime per ateinančias 90 dienų
„Mums reikia atsiliepimų“	Pasitikėjimas po atlikto darbo	Rankiniu būdu paprašyti pirmųjų klientų rekomendacijų ir jas paskelbti
„Mums reikia momentinio rezervavimo“	Laiko patvirtinimo greitis	Naudokite bendrą kalendorių ir paprastą nuorodą, koordinuokite rankiniu būdu
„Mums reikia dirbtinio intelekto suderinimo“	Per mažai teikėjų rajone	Verbuokite pasiūlą ir rūšiuokite užklausas rankiniu būdu, kol apimtys pateisins automatizavimą

Ši lentelė atlieka du dalykus. Ji gerbia prašymą, paversdama jį rezultatu. Ir ji signalizuoja, kad neignoruojate ateities — jūs ateinate su planu, kaip ten patekti. Jūsų viršininkas gali nunešti šią lentelę savo viršininkui ir pasakyti: „mes pažiūrėjome į atsiliepimus, bet pirmiausia turime sutvarkyti X.“ Tai daug geresnė istorija nei „pridedame atsiliepimus“.

Lentelė taip pat suteikia jums bendrą kalbą sakyti „ne dabar“ nesakant „niekada“. Tame pačiame puslapyje laikykite „ne dabar“ sąrašą, pažymėtą data, kada grįžti. Idėja nėra nužudyta; ji atidėta iki kito susitikimo.

Vieno puslapio santrauka susitikimo pabaigai

Kai įeisite į susitikimą, atsineškite vieną puslapį. Antraštė: „Kliūtis yra X.“ Tada sakinys: „Mes nepridėsime atsiliepimų, kol nepakeisime šio skaičiaus iki Y.“ Tada lentelė. Tada „ne dabar“ sąrašas. Viršininkas arba sutiks, arba paprašys parodyti skaičių. Jei paprašys parodyti skaičių, laimėjote, nes dabar abu žiūrite į skaičiuoklę, o ne į funkcijų prašymų krioklį.

Ir jei jūsų viršininkas vis dar skeptiškas, priminkite jam, kad funkcijos paleidimas yra pažadas. Kai tik ką nors išleidžiate, prisiimate lūkestį, kad tai kažką išspręs. Paleisti funkciją, kuri neišsprendžia kliūties, yra blogiau nei jos neišleisti, nes dabar turite sulaužytą pažadą ir išleistą biudžetą.

Kai kitą kartą kas nors pasakys „tiesiog pridėkite atsiliepimus“, įkvėpkite. Jie neprašė jūsų sukurti funkciją; jie prašė, kad rinka jaustųsi saugesnė, greitesnė ar pilnesnė. Tai galite padaryti be nė vienos kodo eilutės — paprastai su pokalbiu, skaičiuokle ir šiek tiek rankinio darbo. Tai nėra žingsnis atgal. Tai ir yra visa mažos komandos esmė: galite judėti prieš kurdami.