Kaip parašyti svetainės RFP, kad gautumėte kokybiškus pasiūlymus

Pasiūlymų prašymas (RFP), tai formalus dokumentas, kuriame aprašomi jūsų svetainės projekto reikalavimai ir kviečiamos agentūros ar kūrimo komandos teikti pasiūlymus darbui atlikti. Jis tarnauja kaip tiekėjų vertinimo pagrindas, užtikrinant, kad kiekvienas dalyvis atsakytų į tuos pačius reikalavimus, todėl galite lyginti pasiūlymus vienodomis sąlygomis. Be RFP tenka lyginti nevienodus dalykus, viena agentūra siūlo kainą penkių puslapių brošiūrinei svetainei, kita, pilnai funkcionaliai web programinei sistemai, ir nė viena neatitinka to, ko jums iš tikrųjų reikia.

RFP reikia, kai jūsų svetainės projektas yra pakankamai sudėtingas, kad neformalus pokalbis negalėtų apimti visų reikalavimų. Tai paprastai reiškia projektus, kurių biudžetas viršija dešimt tūkstančių dolerių, projektus su keliais suinteresuotais subjektais, projektus, reikalaujančius integracijos su esamomis sistemomis, arba projektus, kuriuose planuojate vertinti tris ar daugiau tiekėjų. Paprastesniems projektams, vieno puslapio svetainei, nedideliam dizaino atnaujinimui, turinio atnaujinimui, dažniausiai pakanka išsamaus aprašymo.

RFP procesas taip pat apsaugo jūsų organizaciją. Jis sukuria dokumentinę reikalavimų seką, nustato vertinimo kriterijus prieš pardavėjų santykiai įneša šališkumą ir suteikia pirkimų ar teisininkų komandai dokumentą, kuriuo galima remtis visos bendradarbiavimo eigoje. Bet kokiam svetainės dizaino projektui, kuris susijęs su reikšmingomis investicijomis, RFP praleidimas yra lyg statymas be brėžinių: galbūt gausite funkcionalų rezultatą, tačiau jis tikrai nebus toks, kokio tikėjotės.

Kokybiška RFP laikosi aiškios struktūros, kuri leidžia pardavėms pateikti išsamių atsakymų. Būtinos skiltys apima: įmonės apžvalgą, kuri suteikia kontekstą apie jūsų verslą; projekto apžvalgą, paaiškinančią, ką kuriate ir kodėl; funkcinius reikalavimus, detalizuojančius specifines funkcijas ir galimybes; techninius reikalavimus, nurodančius platformas ir integracijas; dizaino reikalavimus, perteikiančius vizualinius lūkesčius; biudžeto diapazoną ir terminus; vertinimo kriterijus bei pateikimo instrukcijas.

Kiekviena dalis turi būti pakankamai išsami, kad nukreiptų tiekėjų atsakymus, bet ne tokia nurodomoji, kad panaikintumėte kūrybinius sprendimus. Pavyzdžiui, nurodyti, kad jums reikia turinio valdymo sistemos, yra tinkama; reikalauti, kad tai būtų WordPress, nebent turite rimtą techninę priežastį tokiam apribojimui, yra pernelyg nurodoma. Geriausi RFPS aprašo problemą, kurią reikia išspręsti, ir norimus rezultatus, o tada leidžia tiekėjui pasiūlyti sprendimą. Toks požiūris išryškina tiekėjus, kurie mąsto strategiškai, o ne tuos, kurie tiesiog vykdo nurodymus.

Viena skiltis, kurią daugelis RFP praleidžia, bet kuri žymiai pagerina atsakymų kokybę, yra esamos svetainės problemų aprašymas. Pardavėjams pasakant, kas neveikia, lėtas puslapio įkrovimas, didelis atmetimo rodiklis mobiliuosiuose įrenginiuose, paini navigacija, neįmanoma atnaujinti turinio be programuotojo, jiems suteikiate konkrečių problemų, kurias reikia spręsti pasiūlymuose. Pardavėjai, kurie siūlo specifinius sprendimus jūsų nurodytoms problemoms, demonstruoja įsipareigojimo lygį, kurio negali pakartoti bendro pobūdžio atsakymai.

Tikslų skiltis yra svarbiausia jūsų RFP dalis, nes ji formuoja viską, kas seka po jos. Pradėkite nuo verslo tikslų: padidinti potencialių klientų generavimą 30 %, sumažinti palaikymo užklausų kiekį suteikdami savitarnos galimybę, paleisti el. prekybos kanalą, pirmąjį metą generuojant šimtą tūkstančių dolerių pajamų, arba sujungti tris senos kartos svetaines į vieną platformą. Šie tikslai suteikia pardavėjams būtiną kontekstą, kad jie galėtų siūlyti sprendimus, kurie realiai stumtų jūsų verslą į priekį, o ne tik atrodo įspūdingai pristatymuose.

Paverskite savo verslo tikslus matomais svetainės reikalavimais. Jei tikslas, potencialių klientų generavimas, jūsų reikalavimai gali apimti daugiakopį kontaktinę formą, nukreipimo puslapių šablonus reklamos kampanijoms, resursų biblioteką su turiniu, prieinamu tik registruotiems vartotojams, ir CRM integraciją. Jei tikslas, el. prekyba, jums reikia produktų katalogo valdymo, krepšelio ir apmokėjimo funkcionalumo, mokėjimų sistemų integracijos ir užsakymų sekimo. Būkite konkretūs dėl būtinų funkcijų, tačiau lankstūs dėl technologijų, naudojamų joms įgyvendinti.

Atskirkite reikalavimus į „būtinas“ (must-haves) ir „pageidautinas“ (nice-to-haves). Šis skirtumas padeda pardavėjams prioritetus nustatyti pagal jūsų biudžetą ir suteikia jiems erdvės siūlyti alternatyvas. Pardavėjas gali pasiūlyti paprastesnį pageidaujamo elemento sprendimą, sutaupantį biudžetą būtinam elementui, kurio atsisakyti ketinate. Be tokio prioritetų nustatymo pardavėjai linkę kainuoti viską maksimaliu mastu, išpūsdami pasiūlymus ir apsunkindami jų palyginimą.

Vienas dažniausiai ginčijamų klausimų RFP procese, ar įtraukti biudžeto diapazoną. Mūsų kategoriška rekomendacija: visada įtraukite. Biudžeto slėpimas neduoda geresnės kainos, jis duoda pasiūlymus, kurie visiškai neatitinka jūsų finansinių galimybių. Agentūra, kuri įprastai kuria penkiasdešimties tūkstančių dolerių svetaines, sugadins tiek jūsų, tiek savo laiką pateikdama pasiūlymą projektui, kuriam numatėte tik šešiolikos tūkstančių dolerių biudžetą. Atvirkščiai, nišinė komanda, idealiai tinkanti jūsų apimčiai, gali visai nereaguoti, manydama, kad projektas viršija jų kapacitetą.

Nurodykite realų diapazoną, o ne fiksuotą sumą. Biudžeto nurodymas dviejų ir trijų dešimčių tūkstančių dolerių ribose parodo pardavėjams orientyrus ir suteikia jiems erdvės siūlyti pakopinius variantus: pagrindinį kūrimą pagal apatinę ribą ir patobulintą versiją pagal viršutinę ribą. Šis skaidrumas lemia geresnius pasiūlymus, nes pardavėjai gali protingai paskirstyti pastangas, o ne spėti dėl apimties. Jei tikrai nežinote, kiek turėtų kainuoti jūsų projektas, tai aiškiai pasakykite ir prašykite pardavėjų pateikti pakopinius pasiūlymus skirtingose kainų taškuose.

Terminų lūkesčiai yra ne mažiau svarbūs. Nurodykite paleidimo terminą ir identifikuokite griežtus apribojimus, konferenciją, produkto startą, fiskalinių metų ribą. Taip pat nurodykite, ar terminai yra lankstūs. Pardavėjas, žinantis, kad turi aštuonias savaites, pasiūlys visiškai kitokį sprendimą nei tas, kuris turi šešis mėnesius. Būkite sąžiningi dėl vidaus tvirtinimo terminų ir suinteresuotųjų šalių prieinamumo, nes tai yra paslėpti „butelko kakleliai“, kurie delsina daugiau projektų nei bet kokia techninė problema.

Techninių reikalavimų skiltis perduoda apribojimus ir preferencijas, kurios formuos jūsų svetainės architektūrą. Mažiausiai, ko reikia, tai turinio valdymo sistema (arba poreikis ją turėti), hostingo aplinka, trečiųjų šalių integracijos (CRM, analitika, mokėjimų procesoriai, marketingo automatizavimas), prieinamumo atitikties lygis (WCAG 2.1 AA yra standartas), veiklos tikslai (puslapio įkrovimo laikas, Core Web Vitals) ir naršyklės bei įrenginių palaikymo lūkesčiai.

Jei turite egzistuojančių sistemų, su kuriomis svetainė turi integruotis, aprašykite jas detaliai. Nurodykite sistemos pavadinimą, integracijos tipą (API, webhook, embed, SSO), duomenų srauto kryptį ir bet kokią prieinamą dokumentaciją. Neaiškūs reikalavimai, pvz., „integruojasi su mūsų CRM“, verčia pardavėjus spėlioti, o konkretūs reikalavimai, pvz., „formos pateikimus siunčia į HubSpot per jų REST API ir sukuria kontakto įrašą su papildomomis savybėmis potencialaus kliento šaltiniui ir užklausos tipui“, leidžia tiksliai įvertinti apimtį.

Jei jūsų komanda turi stiprių nuomonių dėl technologijų, norite WordPress, nes turinio komanda jį moka, arba norite headless CMS, nes programavimo komanda pageidauja React, nurodykite šias preferencijas ir motyvus. Jei esate atviri rekomendacijoms, tai pasakykite. Pardavėjai dažnai gali pasiūlyti sprendimų, kurių jūs neapsvarstėte, ypač jei jie specializuojasi tam tikrame požiūryje. Bendradarbiavimas su patyrusiomis projektinėmis komandomis suteikia prieigą prie tokio strateginio konsultavimo kartu su vykdymu.

Vertinimo kriterijų apibrėžimas prieš gaunant pasiūlymus yra būtinas objektyviam sprendimų priėmimui. Dažni kriterijai apima: atitinkamą portfelio patirtį (ar pardavėjas turi atvejų studijų jūsų pramonėje ar panašaus sudėtingumo projektuose), techninį požiūrį (ar siūloma architektūra yra tvirta ir priežiūros efektyvi), komandos sudėtį (kas realiai dirbs ir koks jų patyrimo lygis), komunikacijos procesą (kaip pardavėjas tvarko pataisas, grįžtamąjį ryšį ir pokyčių užklausas), terminus ir etapus bei bendrąją nuosavybės kainą, įskaitant palaikymą po paleidimo.

Sverkite kriterijus pagal tai, kas yra svarbiausia. Jei esate sveikatos priežiūros įmonė, patirtis atitinkamose reguliacijose gali svirti 30 %. Jei startuojate pagal griežtą terminą, terminų laikymasis gali būti kritiškai svarbus. Jei turite ribotą vidinę techninę komandą, pardavėjo po paleidimo palaikymo pasiūlymas tampa kritinis. Šių svorių paskelbimas pačioje RFP signalizuoja pardavėjams, kas jums svarbiausia, kas pakelia atsakymų kokybę iš viso.

Įtraukite skiltį apie nuorodas ir prašykite tiekėjų pateikti du ar tris klientus, su kuriais galite susisiekti. Pokalbiai su buvusiais klientais parodo dalykus, kurių negali parodyti pasiūlymai: kaip tiekėjas tvarko apimties plėtimąsi, kaip greitai reaguoja projekto metu, ar laiku pristato rezultatus ir kaip veikia santykiai po paleidimo. Tiekėjas, pasitikintis savo darbu, lengvai pateiks nuorodas. Tas, kuris hesituoja arba pateikia tik atsiliepimus vietoj kontaktinių asmenų, yra raudona vėliava.

Dažniausia RFP klaida, reikalavimų rašymas kaip sprendimo aprašymo, o ne problemos. Nurodant „Svetainėje turi būti šoninė juosta su akordeono tipo navigacija“, nurodomas dizaino elementas nepaaiškinant pagrindinės priežasties. O jei parašysite „Naudotojai turi galėti naršyti po trijų šimtų produktų katalogą, suskirstytą pagal kategorijas, su filtravimu pagal kainą ir prieinamumą“, tai apibrėžia problemą ir leidžia tiekėjams pasiūlyti geriausią sprendimą. Skirtumas svarbus, nes patyrę tiekėjai dažnai turi geresnių sprendimų nei tas, kurį numatytumėte jūs.

Kita dažna klaida, per daug tiekėjų kvietimas teikti RFP. Kvietus dešimt ar penkiolikos agentūrų gali atrodyti, kad elgiatės atsakingai, tačiau tai sumažina atsakymų kokybę. Patyrusios agentūros žino, kad kai RFP gauna dvylika tiekėjų, jų laimėjimo tikimybė yra maža, todėl į savo pasiūlymą investuoja mažiau pastangų. Siunčiant RFP trims ar penkioms kruopščiai atrinktomis agentūromis, parodote rimtą ketinimą ir skatinate tiekėjus pateikti geriausius savo darbus.

Galiausiai, daugelis RFP nepateikia aiškumo dėl to, kas nutiks po pasiūlymo pateikimo. Įtraukite aiškią vertinimo proceso grafiką: kada baigiasi pasiūlymų pateikimo terminas, kada vyks papildomi pristatymai, kada priimsite sprendimą ir kada tikėtinas projekto startas. Tiekėjams tai padeda planuoti savo resursus. Neapibrėžtas grafikas signalizuoja netvarką ir gali paskatinti stiprius tiekėjus jūsų projekto prioritetu laikyti žemesniu.

Tinkamai struktūruotas RFP šablonas remiasi šia struktūra: santrauka (kas esate ir ko reikia, dviem pastraipomis), įmonės istorija (pramonės šaka, dydis, auditorija, konkurencinė aplinka), projekto tikslai (verslo tikslai su matuojamais rodikliais), darbo apimtis (būtinos funkcijos, pageidaujamos funkcijos, turinio migravimo poreikiai), techniniai reikalavimai (CMS, hostingas, integracijos, našumo tikslai), dizaino reikalavimai (prekės ženklo gairės, pavyzdinės svetainės, prieinamumas), biudžeto diapazonas ir terminai, vertinimo kriterijai su svoriais, pateikimo formatas ir terminas, bei kontaktinis asmuo klausimams.

Prieš galutinai sudarydami ir išsiųsdami RFP, paprašykite kažką iš projekto komados perskaityti dokumentą aiškumo sumetimais. Vidiniai suinteresuoti subjektai dažnai naudoja žargoną ir daro prielaidas, kurios jiems atrodo akivaizdžios, bet užsienio tiekėjui yra neaiškios. Švieži akių pora pastebės dviprasmybes ir praleistą kontekstą, kuris kitu atveju sukeltų papildomų aiškinimosi klausimų iš kiekvieno respondento. Tikslas, RFP, kurį kvalifikuotas tiekėjas galėtų perskaityti vieną kartą ir tiksliai suprasti, ko jums reikia.

Jei rengiatės skelbti RFP svetainės projektui ir norite antros nuomonės apie savo reikalavimų dokumentą, mielai jį peržiūrėsime. GRADAX mes esame stovėję abiejose RFP proceso pusėse ir suprantame, kas lemia skirtumą tarp dokumento, kuris pritraukia puikius pasiūlymus, ir tokio, kuris pritraukia standartinius atsakymus. Susisiekite su mumis nemokamai RFP peržiūrai, padėsime sutvirtinti jūsų reikalavimus, nustatyti spragas ir įsitikinsime, kad esate pasiruošę rasti tinkamą partnerį savo projektui.