SaaS уебсайт диагностиката, която вашата агенция може да преизползва, без да прави клиентите да изглеждат еднакви

Резюме

Колко пъти през това тримесечие сте провеждали точно същото проучвателно обаждане — същите въпроси за продукта, клиента, конкурента — за двама клиенти, които настояваха, че са напълно различни? Вече знаете, че отговорите ще са различни, но задачите, които всеки SaaS сайт трябва да изпълнява, не са. Всеки SaaS продуктен уебсайт е малък набор от машини, които изпълняват едни и същи задачи: обясняват какво прави продуктът, показват колко струва, казват на разработчиците как да интегрират, отговарят на възраженията, които спират покупката, и доказват, че компанията е надеждна. Повторима диагностика, която одитира тези пет задачи, ще оцелее при контакт с всеки клиент, защото задачите не се променят. Системата, която изградите около нея, е това, което ви позволява да преминете от една ангажираност към следващата, без да започвате от нулата. Отнема по-малко време от текущия ви процес на проучване, дава на клиента ясна причина да ви се довери и създава резултат, който не изглежда шаблонен, защото въпросите са стандартни, но отговорите са специфични.

Колко пъти през това тримесечие сте провеждали точно същото проучвателно обаждане — същите въпроси за продукта, клиента, конкурента — за двама клиенти, които настояваха, че са напълно различни? Вече знаете, че отговорите ще са различни, но задачите, които всеки SaaS сайт трябва да изпълнява, не са. Всеки SaaS продуктен уебсайт е малък набор от машини, които изпълняват едни и същи задачи: обясняват какво прави продуктът, показват колко струва, казват на разработчиците как да интегрират, отговарят на възраженията, които спират покупката, и доказват, че компанията е надеждна. Повторима диагностика, която одитира тези пет задачи, ще оцелее при контакт с всеки клиент, защото задачите не се променят. Системата, която изградите около нея, е това, което ви позволява да преминете от една ангажираност към следващата, без да започвате от нулата. Отнема по-малко време от текущия ви процес на проучване, дава на клиента ясна причина да ви се довери и създава резултат, който не изглежда шаблонен, защото въпросите са стандартни, но отговорите са специфични.

„Клиентите ми са твърде различни за една система“

Приложете една и съща петточкова диагностика към всеки клиент, преди да напишете и дума от текста или да отворите инструмент за дизайн. Разликите, които правят клиентите ви специални—индустрия, аудитория, ценови модел—стоят върху обща основа. SaaS за заплати и инструмент за планиране на социални медии нямат нищо общо, освен петте задачи, които всяка страница изпълнява. Ако одитирате за тези задачи, ще откриете същите модели на същите места.

Страница или секция	Какво обикновено иска клиентът ви	Какво всъщност се случва на страницата
Демонстрация на функции	„Покажи всяка функция, която сме създали“	Показва резултата, който потребителят получава, а не само функцията. Визуализации като екранни снимки, GIF или видеоклипове трябва да демонстрират момент, в който продуктът променя начина, по който някой работи.
Ценообразуване	„Направи цените лесни за четене“	Купувачът е принуден да реши кой план е за него. Нивата трябва да се четат като прогресия, която води до избор, а не като плосък списък с цени.
API документация	„Нашите разработчици ще намерят това в документацията“	Често е първият тест, който разработчикът провежда, когато оценява дали продуктът може да му се довери. Яснотата тук е функция, а не приятен бонус.
FAQ секция	„Отговаряйте на въпроси, за да намалеят обажданията за поддръжка“	Последното нещо, което купувачът прочита, преди да кликне върху бутон. То трябва да се справя с ценовите възражения и крайните случаи, а не само с общи фирмени въпроси.
Социално доказателство	„Поставете логата“	Доказателството, че твърденията, направени по-рано, са верни. Логата и препоръките са индикатори за доверие, а не декорация.

Диагностиката не е шаблон. Това е набор от въпроси, които задавате за всяка страница: кара ли купувача да разбере какво прави продуктът, прави ли следващата стъпка очевидна, отговаря ли на възражението, което в момента блокира продажбата? Когато задавате тези въпроси в присъствието на клиент, клиентът ви възприема като човека, който разбира техния пазар, а не като десетата агенция, която е показала слайдове. Изследванията на SaaS уебсайтове посочват компании като HubSpot, Slack и Zendesk като примери за добре организирани FAQ секции, а Stripe, GitHub и Twilio като стандарти за яснота на документацията. Нито една от тези компании не е стигнала до там, третирайки FAQ като купчина от заявки за поддръжка. Те са я третирали като повърхност за конверсия. Това е нагласата, която вашата диагностика трябва да донесе на всеки клиент.

Помислете за клиент, който продава софтуер за инвентар, и друг, който продава софтуер за заплати. Диагностиката често разкрива едни и същи три пропуска: страницата с функции споменава модули вместо резултати, страницата с цени не обосновава скока между плановете, а FAQ отговаря на въпроси за поддръжка, а не на колебания при покупка. Тъй като сте виждали тези пропуски и при двамата, знаете точно какво да поискате на етапа на дизайна. Клиентът вижда процес, който е специфичен, а не общ. Напишете диагностиката като едностраничен PDF с оценка от 1 до 5 за всяка задача и бележка за всяка. Споделете я с клиента преди стартирането на дизайна. Това ви дава общ речник и превръща одита в резултат, за който можете да таксувате. Това е ядрото на повторима система и имаме отделно ръководство за това как да настроите тази система тук.

„Това ще направи работата ни да изглежда като на всички останали“

Стандартизирайте въпросите, които задавате, а не отговорите, които доставяте. Диагностиката ви дава критерии за оценка, а не оформление. Изследванията на SaaS витрините с функции показват, че те използват визуализации като екранни снимки, GIF или видеоклипове—но съдържанието на тези визуализации е различно за всеки продукт. Функцията за отчитане на заплати в HR инструмент и функцията за сканиране на баркодове в софтуера за инвентар никога няма да изглеждат еднакво. Това, което остава постоянно, е въпросът, който задавате на стратегическия си ум: „Тази страница показва ли резултата или само функцията?“

Формулярът за приемане на пациент не прави всички диагнози еднакви; той прави лекаря надежден. Вашата рамка е формулярът за приемане. Клиентът все пак получава персонализиран уебсайт, но вие получавате диагностика, която е повторима. Нещото, което всъщност ще направи работата ви да изглежда обща, е липсата на диагностика—защото без нея се връщате към същото hero изображение, същото триколонно оформление на функции, същата структура на началната страница, която сте използвали за последния проект, само за да се движите бързо. Диагностиката ви принуждава да обосновете структурата от доказателствата, така че всеки сайт да е структурно различен там, където трябва.

На практика това означава, че диагностиката може да ви каже да започнете страницата с функции на един клиент с видео на съветник за импортиране, а на друг с GIF на конструктор на отчети чрез плъзгане и пускане. Структурата на страницата остава същата, но активите, текстовете и темпото са уникални. Клиентът вижда персонализирана работа; вие виждате повторим процес. Когато представяте диагностиката на клиент, вие демонстрирате, че знаете какво трябва да прави всеки SaaS сайт. Това е по-силно предложение от „ще създадем уникален дизайн“. Дизайнът е следствие от диагнозата, а не отправна точка.

„Нямаме време да одитираме всяка страница“

Направете фокусираната 90-минутна версия, а не пълен одит. Повечето процеси на агенциите за проучване вече са одит, просто неструктуриран. Прекарвате четиридесет и пет минути в разговор за проучване, който покрива предистория, конкуренти и „какво искате от това“, след което прекарвате седмици в реагиране. Диагностиката обръща това: оценявате петте задачи, изброявате корекциите с най-голям ефект и преминавате към дизайн. Това спестява време, защото спирате да преработвате работа след първия преглед на дизайна. Най-евтините корекции са тези, които правите, преди някой да види пиксели.

Ето конкретно разпределение на 90-те минути: блок първи (30 минути) преглежда началната страница и страницата с функции за петте задачи. Блок втори (30 минути) преглежда страницата с цени и FAQ. Блок трети (15 минути) проверява дали API документацията отговаря на „мога ли да извадя данните“, а последните 15 минути изброяват основните корекции и отговорника за всяка. Не е нужно да четете всяка страница отгоре до долу; трябва да откриете дали задачата се изпълнява. Ако страницата с цени няма FAQ, дизайнът ще бъде одобрен по-бързо, ако забележите това, преди да създадете четвъртата колона с цени. Ако API документацията е написана според вътрешен стандарт, а не според стандарта на разработчика, ще знаете това, преди да инструктирате копирайтъра.

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

„Моят нетехнически клиент не се нуждае от API документация“

Използвайте дърво на решенията, а не контролен списък: ако продуктът има публичен API или интеграционна история, API документацията е основна страница; ако не, съзнателно я пропуснете. Изследванията на API документацията са категорични: компании като Stripe, GitHub и Twilio задават стандарта за яснота на документацията, защото техните разработчици са реално купувачите. Ако вашият клиент има интеграция, ориентирана към разработчици, документацията не е удобство за разработчика; тя е инструмент за доверие, който стои до страницата с цени. Нетехнически клиент може никога да не я погледне, но разработчикът, който оценява покупка, определено ще я погледне.

Дървото на решенията е част от системата. Когато клиентът каже „нямаме аудитория от разработчици“, задайте един въпрос: „изисква ли някаква част от въвеждането в експлоатация разработчик да свърже продукта с друга система?“ Ако да, документацията остава. Ако не, я пропускате и влагате усилия във FAQ и социалното доказателство. Приложете същата логика към социалното доказателство: за един клиент ред от лога е достатъчен; за друг се изисква подробна препоръка с измерими резултати. Диагностиката ви казва кое, вместо да се спирате на всяко лого, което можете да съберете. Този избор прави рамката повторима, без да е твърда. Ако трябва да разберете какво означава „яснота“ на практика, това ръководство за API документация преминава през структурата.

„Но клиентът ми иска списък с функции, а не резултати“

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

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

Диагностиката също ви дава защитима причина да откажете разширяване на обхвата. Когато клиент поиска да добави още един ред функции на началната страница, можете да посочите таблицата и да кажете „работата на тази страница е да показва резултати, а не да каталогизира функционалности“. Обикновен конструктор на страници може да генерира мрежа от функции, но не може да реши дали мрежата трябва да бъде заменена с видео или FAQ. Това решение е истинският продукт и е причината рамката да не комодизира работата ви.

„Вече имаме вътрешен процес“

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

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

„Клиентът казва, че настоящият сайт е наред“

Диагностиката работи дори ако клиентът иска само освежаване. Тя ви дава базова линия. Оценявате настоящия сайт и показвате, че определена страница се проваля в определена задача. Можете да кажете: „Вашата FAQ страница е организирана, но не отговаря на въпроса, който вашият търговски екип чува всяка седмица“, и това е основана на факти причина за промяна, а не естетическо предпочитание. Това често е най-деликатният начин да започнете редизайн: не казвате на клиента, че сайтът му е грозен, казвате му, че една задача не се изпълнява.

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

Диагнозата е продуктът

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

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