Как да напишете RFP за сайт, което получава отлични предложения

Заявка за предложение, или RFP, е официален документ, който очертава изискванията на вашия проект за сайт и кани агенции или екипи за разработка да подадат предложения за работата. Той служи като основа за оценка на доставчиците, като гарантира, че всеки участник отговаря на един и същ набор от изисквания, така че да можете да сравнявате предложенията при равни условия. Без RFP в крайна сметка сравнявате ябълки с круши, една агенция дава оферта за сайт брошура от пет страници, докато друга дава оферта за пълнофункционално уеб приложение, и нито една не отговаря на това, което всъщност ви е нужно.

Нуждаете се от RFP, когато проектът ви за сайт е достатъчно сложен, че неформален разговор няма да обхване всички изисквания. Това обикновено означава проекти с бюджети над десет хиляди долара, проекти с множество заинтересовани страни, проекти, изискващи интеграция със съществуващи системи, или проекти, при които планирате да оцените три или повече доставчика. За по-прости проекти, целева страница, малка преработка, актуализация на съдържание, подробно задание обикновено е достатъчно.

Процесът на RFP също защитава организацията Ви. Той създава документална следа от изисквания, установява критерии за оценка, преди взаимоотношенията с доставчици да внесат пристрастие, и дава на екипа Ви по доставки или правния Ви екип документ за справка през целия ангажимент. За всеки проект за уеб дизайн, който включва значителна инвестиция, пропускането на RFP е като строеж без чертежи, може да получите нещо функционално, но вероятно няма да е това, което сте си представяли.

Добрата RFP следва предвидима структура, която улеснява доставчиците да отговорят изчерпателно. Основните раздели включват: преглед на компанията, който дава контекст за бизнеса Ви; преглед на проекта, който обяснява какво изграждате и защо; функционални изисквания, които описват конкретни функции и възможности; технически изисквания, които уточняват платформи и интеграции; изисквания за дизайн, които предават визуалните очаквания; бюджетен диапазон и срокове; критерии за оценка; и инструкции за подаване.

Всеки раздел трябва да бъде достатъчно подробен, за да насочва отговорите на доставчиците, но не толкова предписващ, че да елиминирате творческите решения. Например, да заявите, че се нуждаете от система за управление на съдържание, е уместно; да уточните, че трябва да бъде WordPress, освен ако нямате силна техническа причина за това ограничение, е прекалено предписващо. Най-добрите RFP описват проблема, който трябва да бъде решен, и желаните резултати, след което оставят доставчика да предложи решението. Този подход изважда на повърхността доставчиците, които мислят стратегически, а не тези, които просто изпълняват инструкции.

Един раздел, който много RFP пропускат, но който значително подобрява качеството на отговорите, е описание на проблемите на текущия Ви уебсайт. Да кажете на доставчиците какво не работи, бавно зареждане на страници, висок процент на отпадане на мобилни устройства, объркваща навигация, невъзможност за обновяване на съдържание без разработчик, им дава конкретни проблеми, които да адресират в предложенията си. Доставчиците, които отговарят с конкретни решения на посочените от Вас проблеми, демонстрират ниво на ангажираност, което генеричните отговори не могат да достигнат.

Разделът с цели е най-важната част от Вашата RFP, защото оформя всичко останало. Започнете с бизнес целите: увеличаване на генерирането на потенциални клиенти с 30%, намаляване на обема на тикетите за поддръжка чрез самообслужване, стартиране на канал за електронна търговия, който генерира сто хиляди долара през първата си година, или обединяване на три наследени уебсайта в една платформа. Тези цели дават на доставчиците контекста, от който се нуждаят, за да предложат решения, които наистина движат бизнеса Ви напред, а не просто решения, които изглеждат впечатляващо в презентация.

Превърнете бизнес целите си в измерими изисквания за уебсайта. Ако целта Ви е генериране на потенциални клиенти, изискванията Ви може да включват многостъпков контактен формуляр, шаблони за целеви страници за рекламни кампании, библиотека с ресурси със защитено съдържание и интеграция с CRM. Ако целта Ви е електронна търговия, имате нужда от управление на продуктов каталог, функционалност за количка и плащане, интеграция с платежен шлюз и проследяване на поръчки. Бъдете конкретни относно функциите, от които се нуждаете, но гъвкави относно технологията, използвана за предоставянето им.

Разделете изискванията си на задължителни и желателни. Това разграничение помага на доставчиците да подредят приоритетите в рамките на бюджета Ви и им дава възможност да предложат алтернативи. Доставчик може да предложи по-опростен подход към желателна функция, който спестява бюджет за задължителна функция, която сте били на път да отрежете. Без това приоритизиране доставчиците са склонни да остойностят всичко при максимален обхват, което надува предложенията и затруднява сравнението.

Един от най-обсъжданите въпроси в процеса на RFP е дали да се включи бюджетен диапазон. Нашата категорична препоръка: винаги включвайте такъв. Скриването на бюджета Ви не Ви носи по-добра цена, носи Ви предложения, които са напълно несъответстващи на ресурсите Ви. Агенция, която обикновено изгражда уебсайтове за петдесет хиляди долара, ще пропилее както Вашето, така и своето време, подавайки предложение за проект, за който сте предвидили петнадесет хиляди долара. Обратно, бутиков екип, идеален за Вашия обхват, може изобщо да не отговори, защото предполага, че проектът е по-голям от капацитета им.

Посочете реалистичен диапазон, а не фиксирана цифра. Посочването на бюджет от двадесет до тридесет хиляди долара казва на доставчиците ориентировъчната стойност и им дава възможност да предложат поетапни опции, основна разработка в долната граница и разширена версия, която използва горната граница. Тази прозрачност води до по-добри предложения, защото доставчиците могат да разпределят усилията интелигентно, вместо да гадаят обхвата. Ако наистина не знаете колко трябва да струва проектът Ви, кажете го изрично и помолете доставчиците да предоставят поетапни предложения на няколко ценови точки.

Очакванията за сроковете са също толкова важни. Посочете крайния си срок за стартиране и идентифицирайте всички твърди ограничения, конференция, пускане на продукт, граница на финансовата година. Посочете също дали срокът е гъвкав. Доставчик, който знае, че разполага с осем седмици, ще предложи много различно решение от такъв, който разполага с шест месеца. Бъдете честни относно вътрешните срокове за одобрение и наличността на заинтересованите страни, защото това са скритите тесни места, които забавят повече проекти от всеки технически проблем.

Разделът с технически изисквания съобщава ограниченията и предпочитанията, които ще оформят архитектурата на уебсайта Ви. Като минимум адресирайте системата за управление на съдържание (или дали изобщо Ви е необходима), хостинг средата, интеграциите с трети страни (CRM, аналитика, платежни процесори, маркетинг автоматизация), нивото на съответствие за достъпност (WCAG 2.1 AA е стандартът), целите за производителност (време за зареждане на страница, Core Web Vitals) и очакванията за поддръжка на браузъри и устройства.

Ако имате съществуващи системи, с които уебсайтът трябва да се интегрира, опишете ги подробно. Посочете името на системата, типа интеграция (API, webhook, embed, SSO), посоката на потока от данни и наличната документация. Неясни изисквания като „интегрира се с нашия CRM“ принуждават доставчиците да гадаят, докато конкретни изисквания като „изпраща подадените формуляри към HubSpot чрез техния REST API и създава контакт със персонализирани свойства за източник на потенциалния клиент и тип запитване“ позволяват точно определяне на обхвата.

Ако екипът Ви има силни мнения относно технологията, искате WordPress, защото екипът Ви по съдържание го познава, или искате headless CMS, защото екипът Ви за разработка предпочита React, посочете тези предпочитания и причините зад тях. Ако сте отворени към препоръки, кажете го. Доставчиците често могат да предложат решения, които не сте обмисляли, особено ако са специализирани в определен подход. Работата с опитни екипи на проектен принцип Ви дава достъп до такова стратегическо ръководство заедно с изпълнението.

Дефинирането на критериите Ви за оценка, преди да получите предложенията, е от съществено значение за обективно вземане на решения. Обичайните критерии включват: подходящ опит в портфолиото (има ли доставчикът казуси във Вашата индустрия или с подобна сложност на проекта), технически подход (разумна и поддържаема ли е предложената архитектура), състав на екипа (кой всъщност ще свърши работата и какво е нивото му на опит), процес на комуникация (как доставчикът се справя с ревизии, обратна връзка и заявки за промени), срокове и етапи и обща цена на притежание, включително поддръжка след стартиране.

Претеглете критериите си според това кое е най-важно. Ако сте компания в сферата на здравеопазването, опитът със съответствие може да носи 30% от тежестта. Ако стартирате в твърд срок, надеждността на графика може да е от първостепенно значение. Ако имате ограничен вътрешен технически екип, предлагането на поддръжка след стартиране от доставчика става критично. Публикуването на тези тежести в самата RFP сигнализира на доставчиците какво е най-важно за Вас, което повишава качеството на отговорите като цяло.

Включете раздел с референции и помолете доставчиците да предоставят двама до трима клиенти, с които можете да се свържете. Разговорът с предишни клиенти разкрива неща, които предложенията не могат: как доставчикът се справя с разширяването на обхвата, колко отзивчив е по време на проекта, спазва ли сроковете и как работи връзката след стартирането. Доставчик, който е уверен в работата си, ще предостави референции без колебание. Такъв, който се колебае или предоставя само отзиви вместо референции за контакт, е предупредителен знак.

Най-честата грешка при RFP е да се описват изисквания, които описват решение, вместо проблем. Твърдението „сайтът трябва да има странична лента с акордеонна навигация“ предписва дизайнерски модел, без да обяснява основната нужда. Твърдението „потребителите трябва да могат да навигират в каталог от триста продукта, организирани по категории, с филтриране по цена и наличност“ описва проблема и позволява на доставчиците да предложат най-доброто решение. Разликата е важна, защото опитните доставчици често имат по-добри решения от това, което бихте предписали.

Друга честа грешка е изпращането на RFP до твърде много доставчици. Изпращането до десет или петнадесет агенции може да изглежда като дължима грижа, но всъщност намалява качеството на отговорите. Опитните агенции знаят, че когато RFP отиде при дузина доставчици, шансовете им за победа са малки, затова влагат по-малко усилия в отговора си. Изпращането до три до пет внимателно подбрани доставчици сигнализира за истинско намерение и мотивира доставчиците да вложат най-добрата си работа в предложението.

И накрая, много RFP не уточняват какво се случва след подаването на предложението. Включете ясен график за процеса на оценяване: кога се подават предложенията, кога ще проведете последващи презентации, кога ще вземете решение и кога очаквате проектът да стартира. Доставчиците оценяват тази структура, защото им позволява да планират капацитета си. Оставянето на графика отворен сигнализира за дезорганизация и може да накара силните доставчици да деприоритизират проекта ви.

Добре структурираният шаблон за RFP следва тази схема: резюме за ръководството (кой сте и какво ви е необходимо в два параграфа), информация за компанията (индустрия, размер, аудитория, конкурентна среда), цели на проекта (бизнес цели с измерими показатели), обхват на работата (задължителни функции, желателни функции, нужди от миграция на съдържание), технически изисквания (CMS, хостинг, интеграции, цели за производителност), изисквания за дизайн (бранд указания, референтни сайтове, достъпност), бюджетен диапазон и график, критерии за оценка с тежести, формат и краен срок за подаване и лице за контакт за въпроси.

Преди да финализирате и изпратите RFP, нека някой извън екипа на проекта да го прочете за яснота. Вътрешните заинтересовани страни често използват жаргон и правят предположения, които са очевидни за тях, но неясни за външен доставчик. Свежият поглед ще улови двусмислия и липсващ контекст, които иначе биха генерирали кръг от уточняващи въпроси от всеки участник. Целта е RFP, който квалифициран доставчик може да прочете веднъж и да разбере точно какво ви е необходимо.

Ако се подготвяте да издадете RFP за проект за сайт и искате второ мнение за документа с изисквания, ще се радваме да го прегледаме. В GRADAX сме били от двете страни на процеса на RFP и разбираме какво прави разликата между документ, който привлича отлични предложения, и такъв, който привлича шаблонни текстове. Свържете се с нас за безплатен преглед на RFP, ще ви помогнем да стегнете изискванията си, да идентифицирате пропуски и да се уверите, че сте готови да намерите правилния партньор за проекта си.