תפסיקו למכור תכונות, תמכרו את המעבר

סיכום

אתר ה-SaaS של הלקוח שלכם לא נכשל כי הוא נראה רע. הוא נכשל כי הוא אף פעם לא עונה על השאלה האחת שחשובה: למה לי לעבור? בעבודה בסוכנות, אי אפשר לבנות מודל שכנוע ייחודי לכל מוצר. במקום זאת, השתמשו באותו אודיט של חמש שאלות כדי למצוא את טריגר המעבר לכל SaaS. אחר כך יישמו את הטריגר הזה בכל דף: תכונות הופכות להוכחה, תמחור הופך לבהירות, שאלות נפוצות הופכות לריסוק התנגדויות, ומסמכי API הופכים לניצחון הראשון של מפתח. המסגרת הזו הופכת עיצוב מחדש חד-פעמי לתהליך שניתן לחזור עליו. התוצאה: מסירה מהירה יותר, פחות תיקונים, ודפים שבאמת ממירים.

ללקוח שלכם אין בעיית עיצוב. יש לו בעיית מעבר. לקונה כבר יש כלי, זרימת עבודה, וצוות ששונא שינויים. הם לא משווים את התכונות של הלקוח שלכם מול דף ריק. הם משווים את הכאב של להישאר עם הכאב של לעזוב. התפקיד של האתר הוא לא לפרט מה המוצר עושה. זה לגרום למעבר להיראות קל ובעל ערך יותר מהסטטוס קוו. אם הוא לא עושה את זה, האתר הוא טפט.

כשעובדים בסוכנות, מרגישים את זה בעוצמה. לוקחים לקוח SaaS, המייסד אומר 'אנחנו צריכים אתר מודרני', וכולם מניחים שהפתרון הוא ויזואלי. הוא לא. אפשר למתוח עיצוב זוכה פרסים על המסר הלא נכון, והוא ימיר בדיוק כמו האתר הישן. אבל מצאו את טריגר המעבר, והמסר עושה את העבודה הקשה. רק צריך למצוא אותו מהר — עבור כל לקוח, כל רבעון, בתעשיות שעוד לא מכירים. לכן אתם צריכים מתודולוגיה שאפשר להריץ כבר ביום הראשון, בלי שלב גילוי של שלושה חודשים.

חשבו מה כרוך במעבר: ייצוא נתונים, הדרכת הצוות, למידת ממשק חדש, שינוי הרגלים. האתר של הלקוח שלכם חייב לגרום לרצף הזה להרגיש בלתי נמנע. רשימת תכונות לא יכולה לעשות זאת. תמונה ברורה של החיים אחרי המעבר יכולה. התמונה הזו היא המסר. כל השאר באתר תומך בו.

הנה המתודולוגיה: הגדירו את המעבר. ואז כפו על כל דף לטעון בעדו.

התנגדות	מה היא באמת מגנה	מה לעשות במקום
'כל לקוח הוא שונה.'	הפחד שלכם מתבניות	מצאו את טריגר המעבר עם אודיט של חמש שאלות
'אנחנו צריכים עוד צילומי מסך.'	הפחד מקטעים ריקים	החליפו צילומי מוצר בהוכחה
'התמחור הוא קדוש.'	החרדה של הסמנכ"ל הכספים	השתמשו בבהירות כדי להפחית את הלם המחיר
'מסמכי API הם בעיה של מפתחים.'	השמירה על הגבולות של צוות הפיתוח	התייחסו למסמכים כאל מדיום משכנע
'השאלות הנפוצות משעממות.'	תיבת הדואר הנכנס המוצפת של התמיכה	השתמשו בשאלות נפוצות כדי לסגור ספקות של הרגע האחרון
'אין לנו זמן להתאמה אישית.'	פרפקציוניזם על פני מסירה	בנו שלד, לא פתית שלג

השתמשו בטבלה הזו כרשימת בדיקה בפגישה הראשונה. כל התנגדות בה אינה חוסם אמיתי. זו בקשה למתודולוגיה אחרת.

'כל לקוח הוא שונה' הוא נכון — ולא רלוונטי

הנה השינוי: המוצר שונה, השוק שונה, ההתנהגות של הקונה לא. קונים רוצים שלושה דברים: 'האם אני מבין את זה?' 'האם אני יכול לסמוך על זה?' 'האם המעבר זול יותר מלהישאר?' זה אוניברסלי. אז אל תאחדו את העיצוב. אחדו את החקירה.

התחילו עם אודיט של חמש שאלות. רצו אותו בשיחת הגילוי הראשונה. זה לוקח עשרים דקות ועובד לכל SaaS.

• מי המשתמש, ומי הקונה? (הם לעתים רחוקות אותו אדם.)
• מה הם עושים היום במקום להשתמש במוצר של הלקוח שלכם?
• מה הכאב המעצבן היחיד בזרימת העבודה הנוכחית?
• ממה הם חוששים שישבר אם יעברו?
• מה ה'ניצחון' המהיר ביותר שהם יקבלו מיד אחרי המעבר?

עברו על שני לקוחות כדי לראות איך זה עובד.

ראשית, כלי לניהול פרויקטים. המשתמש הוא מנהל צוות, והקונה הוא גם מנהל הצוות. הוא עושה את אותו הדבר כמו המוצר הקיים. הכאב? אף אחד לא יודע מי הבעלים של המשימה הבאה. הפחד? להעביר מאות פרויקטים ולאבד את כל המצב. הניצחון המהיר? דשבורד שמציג בעלות על משימה במבט אחד. הטריגר: 'לעולם אל תרדוף שוב אחרי בעל משימה.' זו הכותרת.

שנית, מערכת מעקב לידים לנדל"ן. המשתמש הוא סוכן, והקונה הוא ברוקר. הכאב? לידים כפולים מופיעים בשלושה מקומות והטובים מתקררים. הפחד? סוכנים לא יכניסו נתונים. הניצחון המהיר? העשרה אוטומטית מרשומות MLS כך שהסוכנים מסיימים בשתי לחיצות. הטריגר: 'לעולם אל תאבדו ליד פעמיים.'

אותן חמש שאלות. שני מוצרים שונים. עכשיו יש לכם את המסר המרכזי לדף הבית, הפסקה הראשונה של קטע התכונות, ושורת הנושא לרצף המיילים. טריגר המעבר הוא משאב מתחדש: כל דף, כל קטע, כל כותרת משנה יכולים לטעון בעדו. זו נקודת ההתחלה שלכם.

אותו טריגר גם נותן לכם את מפת האתר. הדף שמסביר את הטריגר הוא דף הבית. הדף שמוכיח את הטריגר הוא קטע התכונות. הדף שמסיר את הפחד הוא השאלות הנפוצות. הדף שמראה את עלות המעבר הוא דף התמחור. פתאום לכל האתר יש נרטיב אחד במקום ועדה של דף-דף.

אפשר גם לבצע ניתוח תחרותי על ידי שאילת אותן חמש שאלות על האתר של המתחרה. זו דרך זולה להראות ערך בשיחה הראשונה. תמצאו את טריגר המעבר החסר של המתחרה, והלקוח שלכם יהפוך לאלטרנטיבה המובהקת.

מה אם המוצר הוא 'נחמד שיש', לא משכך כאבים? אז טריגר המעבר גדול יותר: כסף שנחסך, סיכון שנמנע, או מעמד שהושג. לכלי ציות, הטריגר הוא 'הימנעו מקנס.' לכלי אבטחה, הטריגר הוא 'עברו את הביקורת.' למתזמן מדיה חברתית, הטריגר הוא 'קבלו שעתיים בחזרה בכל שבוע.' האודיט עדיין מוצא אותו. חלק מהטריגרים פחות רגשיים.

צילומי מסך הם ההוכחה בעלת הערך הנמוך ביותר בדף

קחו את השורה הבודדה ביותר בטבלת התכונות של הלקוח שלכם: 'תמיכה ב-OAuth 2.0.' איזו רגש זה מעורר? כלום. זה פריט רשימה למפתח שלא הוא הקונה. ובכל זאת, כשאתם מבקשים מהלקוח את דף התכונות, הם נותנים לכם קיר של כאלה. מלאו את הדף בצילומי מסך ואתם עושים משהו נפוץ עוד יותר: מראים את המוצר במקום את התוצאה.

לצילומי מסך יש מקום. GIF טוב של המוצר בעבודה הוא הוכחה. אבל רוב צילומי המסך הם פורטרטים של המוצר. קונים צריכים סיפור של לפני ואחרי. קטע התכונות הוא המקום הטוב ביותר לספר אותו. השתמשו בנוסחת תכונה-תועלת-הוכחה (FBP). תנו שם לתכונה, חברו אותה לתועלת, ואז הוכיחו עם עובדה, תהליך או דמו קטן. בלי מספרים מומצאים — השתמשו בתוצאות ניתנות לצפייה כמו 'עובד עם Google Workspace' או 'מוגדר תוך פחות מדקה.'

בלוק מקורי מהלקוח:

• תמיכה ב-OAuth 2.0
• בקרת גישה מבוססת תפקידים (RBAC)
• אספקת SCIM

שלוש נקודות של ז'רגון ספקים. עכשיו העבירו כל אחת דרך FBP.

תכונה: תמיכה ב-OAuth 2.0.
תועלת: התחברות אחת לכל הצוות. אין יותר קריאות IT.
הוכחה: עובד עם Google Workspace ו-Microsoft Entra.

תכונה: בקרת גישה מבוססת תפקידים.
תועלת: העניקו לאדמינים, לעורכים ולצופים בדיוק את ההרשאות שהם צריכים.
הוכחה: הענקת גישת צפייה בלבד לקבלן תוך פחות מדקה.

תכונה: אספקת SCIM.
תועלת: הוספה והסרה אוטומטית של משתמשים ממערכת משאבי האנוש שלכם.
הוכחה: מסתנכרן עם Okta ו-Rippling.

התכונות לא השתנו. השכנוע כן. הלקוח שלכם יגיד, 'אבל קונים ארגוניים מצפים לראות את המילים OAuth ו-SCIM.' נכון. הוסיפו שורת משנה טכנית למפתחים שבודקים את הדף. אבל שימו את השורה הזו באותיות קטנות מתחת לתועלת. הקהל הראשון הוא הקונה שמחליט אם לקבוע פגישה. הקהל השני הוא המפתח שבודק את התאים. בנו את תצוגת התכונות סביב הוכחה, לא סביב צילומי מוצר, ותפסיקו לעצב חומר מילוי.

כשאתם כן משתמשים בצילום מסך, גרמו לו להראות תוצאה, לא מסך. עבור לקוח ניהול הפרויקטים, צילום מסך של לוח שבו לכל משימה יש בעלים ברור הוא הוכחה. עבור לקוח הנדל"ן, צילום מסך של רשומת איש קשר נקייה אחת עם נתונים מועשרים אוטומטית הוא הוכחה. צילום מסך של מצב ריק בדשבורד הוא נכס עיצובי, לא נכס שכנוע.

שימו את המפרטים הטכניים בקטע מתקפל או בטאב משאבים למפתחים. המשתמש רואה את התועלת; המפתח יכול להיכנס לעומק. זה שומר על הדף נקי ועל הבודק מרוצה.

מבחן טוב לכל טענת תכונה: האם קונה יחזור עליה לבוס שלו? 'התחברות אחת' היא ניתנת לחזרה. 'תמיכה ב-OAuth 2.0' לא. אם דף התכונות של הלקוח שלכם לא עובר את מבחן מקרר המים, הוא עדיין לא משכנע.

דפי תמחור הם שדה מוקשים. בדיוק בגלל זה כדאי לגעת בהם

תשמעו, 'אל תיגעו בתמחור. זה ככה כבר שנים.' מה שהם באמת אומרים זה 'אנחנו מפחדים.' דף תמחור מבלבל לא מגן על הכנסות; הוא מדליף אותן. התפקיד שלכם הוא להפוך את הדף ממשא ומתן על עלות להצהרת בהירות.

התחילו ברישום השאלות שצוות המכירות שלכם עונה עליהן כל שבוע. כתבו אותן מילה במילה. 'האם אתם גובים למשתמש?' 'מה קורה אם אני מוריד גרסה?' 'האם יש דמי התקנה?' 'האם אפשר לנסות בלי כרטיס אשראי?' 'מהי מדיניות ההחזרים?' שימו אותן בדף. קונה לא צריך לקבוע פגישה כדי לדעת אם אתם דורשים כרטיס אשראי לניסיון.

לאחר מכן, קחו את שלוש התוכניות של הלקוח: Basic, Pro, Enterprise. תנו להן שמות לפי המצב של הלקוח. מה כל תוכנית בעצם עושה למישהו? Solo, Team, Organization. או Creator, Studio, Enterprise. השם הוא לא קישוט; זה הרגע הראשון של בהירות.

הנה דוגמה קונקרטית לטבלת תוכניות ששמותיהן שונו:

תוכנית ישנה	תוכנית חדשה	ההבטחה
Basic	Solo	לאדם אחד שצריך זרימת עבודה פשוטה
Pro	Team	לצוות שצריך שיתוף פעולה ודשבורדים
Enterprise	Org	לחברה שצריכה אבטחה, SSO ותמיכה

אז בנו את טבלת ההשוואה. שברו את הדפוס של הפלת כל תכונה לתוך כל שורה. הובילו כל שורה עם השאלה של המשתמש שהיא עונה עליה. 'כמה משתמשים?' 'את מי אפשר להזמין?' 'אילו תכונות אבטחה אנחנו מקבלים?' הקונה קורא טבלה כדי לחפש 'האם אני מתאים.' הפכו את החיפוש הזה לקל.

לבסוף, הוסיפו שאלות נפוצות לתמחור. ענו על השאלה המכוערת: 'מה קורה לנתונים שלי אם אני עוזב?' כתבו את התשובה כמו בן אדם: 'ייצאו הכל בלחיצה אחת לפני שתיגמר המנוי. בלי עמלות, בלי נעילה.' זה שובר האמון של המעבר. רוב הלקוחות לא יכתבו את זה כי זה מרגיש כמו הזמנה לעזוב. זה לא. זו רשות לקנות בלי פחד.

לסוכנות שלכם יש יתרון מובנה כאן: כבר עשיתם את אודיט חמש השאלות, אז אתם יודעים מה הפחד. שימו את הפחד בשאלות הנפוצות. אם אתם צריכים תבנית להתחיל, מדריך ההמרה לדף תמחור הוא התבנית.

אל תתנו ללקוח להסתיר את התמחור. דף 'צור קשר' הוא קיר. המעבר צריך מספר כדי להשוות אליו. אם המחיר גבוה, הדף צריך להסביר מה כלול ולמה זה שווה. אם המחיר נמוך, עגנו אותו מול העלות של הסטטוס קוו. לכלי לניהול פרויקטים, הסטטוס קוו הוא שלושה כלים נפרדים: אפליקציית משימות, אפליקציית צ'אט וגיליון אלקטרוני. המחיר של המעבר לא נראה גבוה כשמשווים אותו לעלות החודשית של שלושתם. הפכו את ההשוואה הזו למפורשת בדף.

כשאתם כותבים את השאלות הנפוצות לתמחור, אל תשתמשו בשפת ספק. אמרו 'אתם' ו'הנתונים שלכם.' דף תמחור שמשתמש כל הזמן ב'אנחנו מציעים, אנחנו מספקים' מרגיש כמו חוברת חברה. הפכו את זה ל'אתם יכולים, הצוות שלכם.' זה המעבר שמתרחש בדקדוק.

אפשר לבדוק את שאלות התמחור הנפוצות באותה דרך שבודקים כל דבר אחר: הקריאו אותן בקול. אם זר מעבר לשולחן היה נרגע, זה טוב. אם הוא היה מרים יד כדי לדבר עם איש מכירות, הוספתם חיכוך.

המסמכים שאתם מתעלמים מהם סוגרים (או הורגים) עסקאות

הנה מפתחת מול מחשב נייד. היא מעריכה את ה-API של הלקוח שלכם. הבוס שלה שאל, 'האם אנחנו יכולים לשלב עם זה?' היא רוצה דבר אחד: הוכחה שהצוות שלה לא יבזבז שבוע. היא לא מתחילה במסמכי הייחוס. היא מתחילה במדריך ההתחלה המהירה.

חברות כמו Stripe, GitHub ו-Twilio מציבות את הסטנדרט למסמכי API. הסוד הוא לא שהן מתעדות כל נקודת קצה בצורה יפה. זה שהן גורמות לריצה הראשונה לארוך חמש דקות. הן מציגות תוצאה קטנה שנראית כמו הצלחה. זה טריגר המעבר למפתח: התקדמות מיידית וקונקרטית.

מסמכי ה-API של הלקוח שלכם הם הדף הראשון שקונה טכני קורא אחרי דף הבית. אם זה נקרא כמו ספר טלפונים, העסקה מתה בשקט. המסמכים הם נכס שיווקי, לא מטלה טכנית. אז עשו כך:

שימו את ההתחלה המהירה לפני הכל. זמן דוגמה. הלקוח שלכם בונה API לאוטומציה של מסמכים. הייחוס הוא תוכן עניינים צפוף שנמשך אלפי שורות. מפתח נוחת, רואה 'אימות' ומתייאש.

בנו מחדש את החלק העליון של המסמכים:

1. כתבו תיאור של שלושה משפטים באנגלית פשוטה. 'שלחו חוזה, קבלו עותק מבוצע בחזרה. ה-API הזה הופך תבניות ונתונים ל-PDF חתומים.'
2. הדביקו דוגמת קוד להעתקה-הדבקה שקוראת לנקודת קצה של סביבת ארגז חול. הציגו את תגובת ה-JSON הראשונה שמוכיחה הצלחה.
3. הוסיפו מקרה שימוש אחד, 'חשבוניות שמרכיבות את עצמן,' וקשרו לנקודות הקצה הספציפיות המעורבות.

העבירו את הייחוס המלא למטה. המפתח שמעתיק את הקטע הראשון הופך לאלוף פנימי. האלוף מבקש סקירת אבטחה, לא דחייה. הלקוח שלכם נוחת לפני שיחת המכירה. מדריך מסמכי ה-API עובר על אותו תהליך.

מקרה שימוש הוא הבטחה עם מסלול. עבור לקוח האוטומציה של מסמכים, כתבו 'חשבוניות שמרכיבות את עצמן: שלחו מספר הזמנת רכש וקבלו חשבונית מעוצבת, שורות פריט ו-PDF בחזרה בקריאה אחת.' זה לא דף מסמכים; זה דף מכירות שבמקרה מכיל קוד.

כללו מפתח API מוטמע לסביבת ארגז החול. ברגע שמפתח יכול להדביק ולראות הצלחה, המעבר הופך לאמיתי. אין צורך בשיחת מכירה.

דף המסמכים גם מזין SEO. מפתחים מחפשים הודעות שגיאה מדויקות ושמות אינטגרציה. כתבו דפים עבור השאילתות האלה: פסקה לכל קוד שגיאה, דף לכל אינטגרציה. כך המסמכים הופכים לערוץ.

השתמשו בסרגל צד קבוע עם כפתור 'נסו עכשיו'. הוסיפו סרגל חיפוש שמאנדקס דוגמאות קוד. ככל שהחיפוש חלק יותר, כך החברה נראית מיומנת יותר. ואל תשכחו סרטון קצר של פחות מ-90 שניות שמראה דוגמה עובדת, לא סקירה כללית של החברה.

השאלות הנפוצות אינן תוכן תמיכה. הן המרה של המשוכה האחרונה

'אף אחד לא קורא שאלות נפוצות' — את זה תשמעו עד שתזכרו מי כן: קונה בחדר שקט, מהסס לשאול שאלה. השאלות הנפוצות הן הדף שבו עסקאות נסגרות בפרטיות. התייחסו אליו כך.

HubSpot, Slack ו-Zendesk עושים את זה נכון. קטעי השאלות הנפוצות והעזרה שלהם מאורגנים, ניתנים לחיפוש ותמציתיים. המבנה הזה הוא הנקודה. הוא מאותת על מיומנות. שאלות נפוצות ניתנות לחיפוש גורמות לקונה לחשוב: האנשים האלה חשבו על הבעיה שלי.

הנה השיפור הזול ביותר שאפשר לעשות לאתר של כל לקוח היום: ארגנו מחדש את השאלות הנפוצות הקיימות לארבע קטגוריות של שלב הרכישה: מתחילים, תמחור וחיוב, אבטחה וציות, מעבר והגירה. ואז כתבו מחדש תשובה אחת לכל קטגוריה.

בואו נעשה את קטגוריית המעבר. התשובה הנוכחית ל'כמה קשה ההגירה?' אומרת: 'כלי הייבוא שלנו תומך ב-CSV וב-API.' זו רשימת תכונות. כתבו אותה מחדש כהבטחה ורשימת צעדים:

'אנחנו נייבא את הנתונים שלכם. שלחו CSV, אנחנו רצים ריצת ניסיון, אתם מאמתים מדגם, ואנחנו מבצעים את המעבר בחלון של 30 דקות. אם משהו נראה לא נכון, אנחנו חוזרים לאחור מיידית.'

עכשיו השוו בין שתי התשובות. איזו מהן סוגרת את העסקה? הראשונה מתארת מנגנון; השנייה מתארת תהליך בטוח. זה אותו מבנה כמו דף התכונות: תועלת פלוס הוכחה.

לכו רחוק יותר: שלפו כל שאלה שהתמיכה עונה עליה פעמיים בשבוע וכתבו את התשובה לפני שהקריאה נוצרת. זה מקור אינסופי לתוכן נחיתה. ברגע שהשאלות הנפוצות מפסיקות להיות מזבלה ומתחילות להיות כלי שכנוע, כל הסיפור נשאר מאוחד. זה חלק מהגישה מבפנים החוצה שבה אתם משתמשים לכל דבר אחר.

ארגנו עם חיפוש בראש. שאלות נפוצות שניתנות לחיפוש ומוצאות את התשובה בהקשה אחת מרגישות כמו תכונת מוצר. זה בדיוק אות המיומנות שאתם רוצים.

אל תגרמו לקונים לפתוח מרכז עזרה נפרד. שימו את השאלות הנפוצות בדף שעורר את השאלה. אם שאלת תמחור מופיעה בדף התמחור, ענו עליה שם. אם שאלת אבטחה מופיעה בדף התמחור, ענו עליה שם גם כן. התשובה שייכת לנקודת הספק.

קטגוריית האבטחה היא המקום שבו ה-IT מחליט לחסום את הכלי. ענו על דברים כמו 'איפה מאוחסנים הנתונים?' עם פרטים. אם אתם אומרים 'באיחוד האירופי', תגידו את האזור. אם אתם אומרים 'מוצפן במנוחה', תנו שם לתקן. תשובה תמציתית חזקה יותר מקישור לנייר לבן.

כל תשובה בשאלות נפוצות צריכה להיות קצרה ככל האפשר ולהסתיים בצעד הבא: 'הירשמו עם חשבון ארגז חול' או 'דברו עם התמיכה.' תשובה בלי צעד הבא היא דרך ללא מוצא.

אין זמן? בנו שלד, לא פתית שלג

ההתנגדות האחרונה היא כזו שאתם בטח מרגישים עכשיו: 'אבל יש לי ארבעה לקוחות ודדליין ביום שני.' הוגן. תתייחסו לכל פרויקט כאל פורטרט מותאם אישית ותמיד תמהרו. במקום זאת, בנו תפוקה אחת לשימוש חוזר: תזכיר המעבר. זה לוקח 90 דקות למלא, וזה מתווה כל דף.

תזכיר מעבר — עמוד אחד, שש שורות:

1. פיצול משתמש/קונה: מי מגיע, מי משלם.
2. התנהגות נוכחית: מה הם עושים היום במקום.
3. הכאב היחיד: משפט אחד, המטרד.
4. הפחד: מה הם חוששים שישבר במעבר.
5. הניצחון המהיר: השיפור הנראה הראשון אחרי המעבר.
6. ההוכחה: לוגואים, תוצאות או עמדות אבטחה שמסירות פחד.

הביאו את זה לשיחת הגילוי הראשונה. מלאו אותו תוך כדי שאלת חמש השאלות. עד שתחזרו לשולחן, יש לכם את מסגרת המסר. כותרת דף הבית היא הניצחון המהיר. פתיח דף התכונות הוא הכאב. העמודה האמצעית בטבלת התמחור היא הקונה. השאלות הנפוצות הן רשימת הפחדים. ההתחלה המהירה במסמכי ה-API היא הניצחון המהיר למפתחים.

השלד הזה לא גורם לכל אתר להיראות זהה. הוא גורם לכל אתר להיות משכנע באותה צורה. אתם עדיין מעצבים לפי הקול של כל לקוח, אבל אתם מפסיקים לתכנן חסר את המסר. אם המסר כבר מוסכם, אפשר להפיק את הטיוטה הראשונה של כל דף ביום אחד. המוצר האמיתי של הסוכנות הוא התהליך, לא הפיקסל.

הנה השינוי: אתם כבר לא מעצבים אתרים מחדש. אתם ממקמים אותם מחדש. ובגלל שמסגרת המעבר שורדת בין תעשיות, אפשר לגבות כסף על אסטרטגיה, לספק אותה בצורה ניתנת לחזרה, ולמסור נכסים שבאמת ממירים. הקיקאוף הבא שלכם צריך להתחיל באודיט של חמש שאלות, לא בלוח מצב רוח.

השתמשו בתזכיר כדי להגדיר ציפיות מוקדם. המייסד רואה שהאתר הוא לא פרויקט אמנות; הוא מסמך שכנוע. זה מונע את הפידבק 'רק תגרמי לזה לקפוץ' ומפנה את השיחה לתוצאות. שתפו את התזכיר עם צוות השיווק הפנימי של הלקוח כדי שיוכלו לכתוב דפים חדשים מאוחר יותר מבלי להמציא את המסר מחדש.

כשאתם מציגים את האתר, התחילו עם תזכיר המעבר, לא עם העיצוב. לקוחות מאשרים אסטרטגיה מהר יותר מאשר הם מאשרים אסתטיקה. תקבלו פחות בקשות 'אפשר להגדיל את הלוגו' כי נתתם להם סיבה להעריך את הדף לפי המסר.

המעבר הוא האסטרטגיה. כל השאר הוא קישוט.

קחו דבר אחד מזה: אל תזמינו עוד עיצוב מחדש עד שעניתם על שאלת המעבר. רוב אתרי ה-SaaS נכשלים כי המבקרים אף פעם לא מוצאים סיבה לנטוש את זרימת העבודה הנוכחית שלהם. האתר לא נכשל כי הלוגו קטן מדי או שהגרדיאנט מיושן.

שיחת הקיקאוף הבאה שלכם צריכה להיות אודיט חמש השאלות. אם המייסד לא יכול לנסח את המעבר, דחפו אותו. אם אתם יכולים לנסח אותו, אז לכל דף יש תפקיד: דפי תכונות מוכיחים אותו, דפי תמחור מצדיקים אותו, דפי שאלות נפוצות מגנים עליו, ומסמכי API מדגימים אותו. תספקו מוצר טוב יותר מהר יותר. ותהיה לכם מסגרת שתוכלו להריץ על כל לקוח, לנצח.

אתר ממוסגר סביב מעבר גם משתפר עם הזמן. עכשיו יש לכם השערה — הטריגר — ואפשר לבדוק אותה במפות חום, הקלטות סשן או בדיקות A/B. המסגרת הופכת עיצוב מחדש מאירוע לניסוי.

אתם לא צריכים מצגת אסטרטגיה בת 40 עמודים. אתם צריכים שש שורות ונכונות לומר לא לדפים שלא משרתים את המעבר. הבהירות הזו היא מה שלקוחות משלמים לכם עליו.

תפסיקו למכור תכונות. תמכרו את המעבר. זו כל האסטרטגיה.