Kā sastādīt tīmekļa vietnes RFP, lai saņemtu labus piedāvājumus

Piedāvājuma pieprasījums (RFP) ir oficiāls dokuments, kas apraksta jūsu tīmekļa vietnes projekta prasības un aicina aģentūras vai izstrādes komandas iesniegt piedāvājumus. Tas kalpo kā piegādātāju vērtēšanas pamats, nodrošinot, ka katrs pretendents adresē vienu un to pašu prasību kopu, lai jūs varētu salīdzināt piedāvājumus vienādā līmenī. Bez RFP jūs riskējat salīdzināt nesalīdzināmo, viena aģentūra censojas par piecu lapu brošūras vietni, kamēr otra par pilnfunkcionālu tīmekļa lietojumprogrammu, un neviena neatbilst tam, ko jums patiesībā vajag.

Jums nepieciešams RFP, kad jūsu tīmekļa vietnes projekts ir pietiekami sarežģīts, lai nejauša saruna neaptvertu visas prasības. Parasti tas nozīmē projektus ar budžetu virs desmit tūkstošiem dolāru, projektus ar vairākiem ieinteresētajām pusēm, projektus, kas prasa integrāciju ar esošajām sistēmām, vai projektus, kur plānojat vērtēt trīs vai vairāk piegādātājus. Vienkāršākiem projektiem, piemēram, vienas lappuses izveidei, nelielai pārdizainai vai satura atjaunināšanai, parasti pietiek ar detalizētu īsu aprakstu.

RFP process aizsargā arī jūsu organizāciju. Tas izveido dokumentētu prasību vēsturi, nosaka novērtēšanas kritērijus pirms piegādātāju attiecības ievieš priekšstatu un nodrošina jūsu iepirkumu vai juridisko komandu ar dokumentu atsaukšanai visa sadarbības perioda laikā. Jebkurā tīmekļa dizaina projektā, kas prasa nozīmīgus ieguldījumus, RFP izlaišana ir līdzvērtīga būvniecībai bez zīmējumiem: iespējams, jūs iegūsiet funkcionālu risinājumu, bet tas visticamāk nebūs tas, ko plānojāt.

Spēcīga RFP seko paredzamai struktūrai, kas atvieglo piegādātāju pilnīgu un detalizētu atbilžu sagatavošanu. Galvenās sadaļas ietver: uzņēmuma pārskatu, kas sniedz kontekstu par jūsu darbību, projekta aprakstu, kas skaidro, ko veidojat un kāpēc, funkcionālās prasības, kas detalizēti apraksta konkrētās funkcijas un iespējas, tehniskās prasības, kas norāda platformas un integrācijas, dizaina prasības, kas nosaka vizuālās gaidas, budžeta diapazonu un grafiku, novērtēšanas kritērijus un iesniegšanas instrukcijas.

Katrai sadaļai jābūt pietiekami detalizētai, lai vadītu piegādātāju atbildes, bet ne tik noteicošai, lai izslēgtu radošus risinājumus. Piemēram, norādīt, ka nepieciešama satura pārvaldības sistēma, ir piemēroti; bet noteikt, ka tai jābūt tieši WordPress, ja vien nav spēcīga tehniska iemesla šim ierobežojumam, ir pārāk stingri. Labākās RFP dokumentācijās tiek aprakstīts risināmā problēma un vēlamie rezultāti, ļaujot piegādātājam piedāvāt risinājumu. Šī pieeja palīdz identificēt piegādātājus, kuri domā stratēģiski, nevis tos, kuri vienkārši izpilda instrukcijas.

Viena sadaļa, ko daudzas RFP bieži izlaiž, bet kas būtiski uzlabo atbilžu kvalitāti, ir pašreizējās tīmekļa vietnes problēmu apraksts. Paziņojot piegādātājiem, kas nedarbojas pareizi, lēna lapas ielāde, augsts atlēcienu rādītājs mobilajās ierīcēs, apgrūtinoša navigācija, nespēja atjaunināt saturu bez izstrādātāja palīdzības, jūs dodat tiem konkrētus uzdevumus risināšanai savos piedāvājumos. Piegādātāji, kuri reaģē ar specifiskiem risinājumiem jūsu minētajām problēmām, demonstrē iesaistīšanās līmeni, ar kuru nevar salīdzināt vispārīgas atbildes.

Mērķu sadaļa ir vissvarīgākā jūsu RFP daļa, jo tā nosaka visu turpmāko. Sāciet ar biznesa mērķiem: palielināt potenciālo klientu ģenerēšanu par 30%, samazināt atbalsta biļešu skaitu, aktivizējot pašapkalpošanās kanālu, palaist e-komercijas kanālu, kas pirmajā gadā ģenerē 100 000 ASV dolāru, vai konsolidēt trīs vecās tīmekļa vietnes vienā platformā. Šie mērķi dod piegādātājam nepieciešamo kontekstu, lai ierosinātu risinājumus, kas tiešām virza jūsu biznesu uz priekšu, nevis tikai risinājumus, kas izskatās iespaidīgi prezentācijā.

Pārveidojiet savus biznesa mērķus mērāmās tīmekļa vietnes prasībās. Ja jūsu mērķis ir potenciālo klientu ģenerēšana, jūsu prasības var ietvert vairāku soļu kontakta formu, nolaižamo lapu veidnes reklāmas kampaņām, resursu bibliotēku ar slēgtu saturu un CRM integrāciju. Ja jūsu mērķis ir e-komercija, jums ir nepieciešama produktu kataloga pārvaldība, groza un kases funkcionalitāte, maksājumu vārtu integrācija un pasūtījumu izsekošana. Esiet precīzs attiecībā uz nepieciešamajām funkcijām, bet elastīgs attiecībā uz tehnoloģijām, kas tiek izmantotas to īstenošanai.

Sadaliet savas prasības obligātajās (must-haves) un vēlamos (nice-to-haves). Šī atšķirība palīdz piegādātājiem prioritizēt darbus jūsu budžeta robežās un dod tiem vietu ierosināt alternatīvas. Piegādātājs var ierosināt vienkāršāku pieeju vēlamiem elementiem, kas ļauj ietaupīt budžetu obligātam elementam, kuru jūs bija gatavs izslēgt. Bez šādas prioritizācijas piegādātāji tendēti kvotēt visu maksimālajā apjomā, uzbriedzinot piedāvājumus un padarot salīdzināšanu grūtu.

Viens no vispretrunīgākajiem jautājumiem RFP procesā ir, vai iekļaut budžeta diapazonu. Mūsu stingra rekomendācija: vienmēr iekļaujiet to. Budžeta neslēpšana nedod labāku cenu, tā dod piedāvājumus, kas krasi neatbilst jūsu resursiem. Aģentūra, kas parasti veido 50 000 ASV dolāru vērtas tīmekļa vietnes, iztērēs gan jūsu, gan savu laiku, sagatavojot piedāvājumu projektam, kura budžets ir 15 000 ASV dolāru. Savukārt, nišas komanda, kas būtu ideāli piemērota jūsu apjoma realizācijai, vispār var nereagēt, jo pieņems, ka projekts pārsniedz to kapacitāti.

Sniedziet reālistisku diapazonu, nevis fiksētu summu. Budžeta norādīšana 20 000 līdz 30 000 ASV dolāru robežās informē piegādātājus par aptuveno apjomu un dod tiem vietu ierosināt pakāpeniskus variantus: pamata būvniecību zemākajā robežā un uzlabotu versiju, kas izmanto augšējo robežu. Šī caurskatāmība noved pie labākiem piedāvājumiem, jo piegādātāji var gudri sadalīt pūles, nevis minēt apjomu. Ja jums patiešām nav skaidrs, cik vajadzētu izmaksāt jūsu projekts, norādiet to tieši un lūdziet piegādātājiem sniegt pakāpeniskus piedāvājumus dažādās cenu pozīcijās.

Grafika gaidas ir tikpat svarīgas. Norādiet starta termiņu un identificējiet stingrus ierobežojumus, konferences, produkta startu, fiskālā gada robežas. Arī norādiet, vai grafiks ir elastīgs. Piegādātājs, kuram ir astoņas nedēļas, ierosinās pilnīgi citu risinājumu nekā tas, kam ir seši mēneši. Esiet godīgi attiecībā uz iekšējo apstiprināšanas grafiku un ieinteresēto puču pieejamību, jo tie ir slepenie sašaurinājumi, kas kavē vairāk projektu nekā jebkādas tehniskas problēmas.

Tehnisko prasību sadaļa komunikē ierobežojumus un vēlmes, kas veidos jūsu tīmekļa vietnes arhitektūru. Minimāli jāaplūko satura pārvaldības sistēma (vai tā ir nepieciešama), hostinga vide, trešo pušu integrācijas (CRM, analītika, maksājumu procesori, mārketinga automatizācija), pieejamības atbilstības līmenis (WCAG 2.1 AA ir standarts), veiktspējas mērķi (lapas ielādes laiks, Core Web Vitals) un pārlūkprogrammu un ierīču atbalsta gaidas.

Ja jums ir esošas sistēmas, ar kurām tīmekļa vietnei ir jāintegrējas, aprakstiet tās detalizēti. Norādiet sistēmas nosaukumu, integrācijas veidu (API, webhook, embed, SSO), datu plūsmas virzienu un pieejamo dokumentāciju. Neskaidras prasības, piemēram, „integrējas ar mūsu CRM”, piespiež piegādātājus minēt, savukārt konkrētas prasības, piemēram, „nosūta formas iesniegumus uz HubSpot, izmantojot to REST API, un izveido kontaktpersonas ierakstu ar pielāgotām īpašībām potenciālā klienta avotam un vaicājuma tipam”, ļauj precīzi noteikt apjomu.

Ja jūsu komandai ir stingri uzskati par tehnoloģijām, vēlaties WordPress, jo satura komanda to pazīst, vai vēlaties headless CMS, jo jūsu izstrādes komanda dod priekšroku React, norādiet šīs preferences un to pamatojumu. Ja esat atvērts rekomendācijām, teiciet to. Piegādātāji bieži var ierosināt risinājumus, kurus jūs neesat apsvēruši, it īpaši, ja viņi specializējas konkrētā pieejā. Sadarbība ar pieredzējušām projektu komandām dod jums piekļuvi šādam stratēģiskam padomam kopā ar izpildi.

Novērtēšanas kritēriju definēšana pirms piedāvājumu saņemšanas ir būtiska objektīvai lēmumu pieņemšanai. Izplatīti kritēriji ietver: attiecīgo portfeļa pieredzi (vai piegādātājam ir gadījumu studijas jūsu nozarē vai ar līdzīgu projekta sarežģītību), tehnisko pieeju (vai ierosinātā arhitektūra ir stabila un uzturama), komandas sastāvu (kas faktiski veiks darbu un kāds ir to pieredzes līmenis), komunikācijas procesu (kā piegādātājs apstrādā labojumus, atsauksmes un izmaiņu pieprasījumus), grafiku un posmus, un kopējās īpašumtiesības izmaksas, tostarp pēcstarta atbalstu.

Sveriet kritērijus atbilstoši tam, kas ir svarīgākais. Ja esat veselības aprūpes uzņēmums, pieredze atbilstībā ar normatīvajiem aktiem varētu veidot 30% no svara. Ja jūs startējat ar stingru termiņu, grafika uzticamība var būt primāra. Ja jums ir ierobežota iekšējā tehniskā komanda, piegādātāja pēcstarta atbalsta piedāvājums kļūst kritisks. Šo svaru publicēšana pašā RFP signalizē piegādātājiem, kas jums ir visvairāk svarīgs, kas paaugstina atbilžu kvalitāti kopumā.

Iekļaujiet sadaļu par atsauksmēm un lūdziet piegādātājus sniegt divus līdz trīs klientus, ar kuriem varat sazināties. Sarunas ar pagātnes klientiem atklāj lietas, ko piedāvājumi nevar: kā piegādātājs rīkojas ar apjoma izplešanos, cik reaģētspējīgi viņi ir projekta laikā, vai viņi ievēro termiņus un kā darbojas attiecības pēc starta. Piegādātājs, kurš ir pārliecināts par savu darbu, brīvprātīgi sniegs atsauksmes. Viņš, kas kavējas vai sniedz tikai testamenteja rakstus, nevis kontaktējamus klientus, ir sarkans karogs.

Visbiežākā RFP kļūda ir prasību formulēšana, kas apraksta risinājumu, nevis problēmu. Teikums „tīmekļa vietnei jābūt sānjoslai ar akordeona tipa navigāciju” nosaka dizaina shēmu, nepaskaidrojot pamatvajadzību. Savukārt teikums „lietotājiem jāspēj pārvietoties katalogā ar trīs simtiem produktu, kas sakārtoti pa kategorijām, ar filtrēšanu pēc cenas un pieejamības” apraksta problēmu un ļauj piegādātājiem piedāvāt labāko risinājumu. Šī atšķirība ir nozīmīga, jo pieredzējuši piegādātāji bieži vien piedāvā labākus risinājumus nekā tos, ko Jūs varētu paredzēt.

Vēl viena bieža kļūda ir RFP nosūtīšana pārāk daudziem piegādātājiem. Nosūtīt to desmit vai piecpadsmit aģentūrām var šķist kā pienācīga rūpība, taču tas faktiski samazina atbilžu kvalitāti. Pieredzējušas aģentūras zina, ka, kad RFP tiek nosūtīta divpadsmit piegādātājiem, viņu uzvaras iespējas ir zemas, tāpēc tās iegulda mazāk pūļu savā atbildē. Nosūtīt to trim līdz piecām rūpīgi atlasītām aģentūrām norāda uz patiesu nodomu un motivē piegādātājus iesniegt savu labāko darbu piedāvājumā.

Visbeidzot, daudzos RFP nav noteikts, kas notiek pēc piedāvājuma iesniegšanas. Iekļaujiet skaidru novērtēšanas procesa grafiku: kad piedāvājumi ir jāiesniedz, kad tiks veiktas sekojošās prezentācijas, kad tiks pieņemts lēmums un kad Jūs sagaidāt projekta uzsākšanu. Piegādātāji novērtē šo struktūru, jo tā ļauj plānot savu kapacitāti. Atstāt grafiku bez termiņa norāda uz neorganizētību un var liecināt spēcīgajiem piegādātājiem prioritizēt Jūsu projektu zemāk.

Labi strukturēta RFP veidne seko šādai struktūrai: izpilddirektora kopsavilkums (kas Jūs esat un ko vajag divos teikumos), uzņēmuma vēsture (nozare, lielums, auditorija, konkurentu ainava), projekta mērķi (uzņēmējdarbības mērķi ar mērāmamiem rādītājiem), darbības apjoms (obligātās funkcijas, vēlāmās funkcijas, satura migrācijas vajadzības), tehniskās prasības (CMS, hostinga pakalpojumi, integrācijas, veiktspējas mērķi), dizaina prasības (zīmola vadlīnijas, atsauces vietnes, pieejamība), budžeta diapazons un grafiks, novērtēšanas kritēriji ar svariem, iesniegšanas formāts un termiņš, kā arī kontaktpersona jautājumiem.

Pirms RFP galīgās apstiprināšanas un nosūtīšanas lūdziet kādu ārpus projektā iesaistīto personu izlasīt to skaidrībai. Iekšējie ieinteresētie pusi bieži lieto žargonu un dara pieņēmumus, kas ir acīmredzami tiem pašiem, bet neskaidri ārējam piegādātājam. Svaiga skata pāris ieraudzīs neprecizitātes un trūkstošo kontekstu, kas citādi ģenerētu papildu precizēšanas jautājumus no katras atbildētājpuses. Mērķis ir RFP, ko kvalificēts piegādātājs var izlasīt vienu reizi un saprast tieši to, ko Jūs nepieciešams.

Ja gatavojaties izdot RFP tīmekļa vietnes projektam un vēlaties otro viedokli par savām prasībām, mēs priecāsimies to apskatīt. GRADAX ir bijusi abās RFP procesa pusēs, un mēs saprotam, kas rada atšķirību starp dokumentu, kas piesaista lieliskus piedāvājumus, un tādu, kas piesaista standarta tekstus. Sazinieties ar mums par bezmaksas RFP apskatu, mēs palīdzēsim Jums precizēt prasības, identificēt spraugas un pārliecināties, ka Jūs esat gatavi atrast pareizo partneri savam projektam.