בלוג

הפלייבוק החוזר למסירת מוצרים דיגיטליים

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

סיכום

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

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

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

מהי השקר הכי גדול בעצות על מוצרים דיגיטליים?

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

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

האם כל לקוח לא שונה?

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

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

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

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

האם כדאי לבחור פלטפורמה שונה לכל לקוח?

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

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

מה אם ללקוח כבר יש חנות פעילה?

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

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

איך אני יודע שתהליך הוא באמת ניתן לחזרה?

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

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

במה כדאי לתקן קודם?

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

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

מה באמת צריך להפוך לאוטומטי?

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

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

מה צריך להישאר ידני?

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

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

הלקוח אומר "רק תביא אותי למכירות" — מאיפה מתחילים?

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

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

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

מה אם הלקוח רוצה פורטל מותאם אישית, אתר חברות ואפליקציה מובייל?

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

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

מה עם תמחור?

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

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

מה עם תנועה ושיווק?

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

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

איך מציגים את זה ללקוח בלי להישמע כמו יועץ?

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

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

מה אם ללקוח אין עדיין מוצר?

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

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

מה כדאי למדוד?

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

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

מה הדבר האחד שכדאי לעשות מחר?

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

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

Sources (5)