למה כל SaaS צריך יומן שינויים ציבורי (ואיך זה משפר שימור)
שחררתם ארבעים שיפורים ברבעון האחרון. לקוח שולח מייל ושואל אם עדיין עובדים על המוצר.
זו אינה תקלה נדירה. זו התוצאה שמתקבלת כברירת מחדל. תוכנה משתפרת באופן בלתי נראה — הבאג שתיקנתם הוא כעת פשוט היעדר בעיה, והיכולת שהוספתם היא פריט תפריט שאיש לא פתח במקרה. אלא אם תספרו לאנשים מה השתנה, החוויה הכנה של שימוש במוצר שלכם היא ששום דבר לא משתנה לעולם.
יומן שינויים הוא הפתרון הזול ביותר לכך, והוא עושה הרבה יותר מאשר להכריז על גרסאות.
מה יומן שינויים באמת קונה לכם
הוא מוכיח שהמוצר חי. לכל מי שבוחן אתכם, יומן שינויים ציבורי עם רשומות מהחודש הזה עונה על שאלה שהוא ממילא עמד לשאול. זה ההבדל בין דף נחיתה לבין ראיה.
הוא סוגר את מעגל המשוב. מי שביקש משהו לפני שישה שבועות אינו יודע שזה שוחרר. לספר לו זה הרגע שבו הוא לומד שדיבור אתכם מניב תוצאות — וזה מה שגורם לו לעשות זאת שוב.
הוא מחזיר אנשים שהתרחקו. מי שהפסיק להשתמש במוצר שלכם עשה זאת מסיבה כלשהי. אם הסיבה הייתה יכולת חסרה, הודעה שאומרת שהיכולת הזו קיימת עכשיו היא ההודעה הרלוונטית ביותר שתשלחו לו אי פעם. לא ניוזלטר. לא קמפיין החזרה. עובדה בשורה אחת על הדבר שהוא רצה.
הוא מפחית תמיכה. רשימה גלויה של שינויים אחרונים בולעת חלק אמיתי מפניות "האם זה נשבר?" ו"האם זה חדש?" עוד לפני שנכתבו.
איך לכתוב רשומות שאנשים קוראים
פתחו במה שהמשתמש יכול לעשות עכשיו. לא "שוכתב צינור הייצוא" אלא "הייצוא כולל כעת פריטים בארכיון ומסתיים בשניות במקום בדקות." דיוק פנימי אינו המטרה; הניתנות לזיהוי היא. הקורא צריך להיות מסוגל לומר בארבע מילים אם הרשומה הזו נוגעת אליו.
תייגו כל רשומה. שלוש קטגוריות מספיקות: חדש לדברים שלא היו קיימים, שופר לדברים שהשתפרו, תוקן לדברים ששבורים היו. הקוראים סורקים אחר התווית שחשובה להם, ומי שמעניינים אותו רק באגים יכול למצוא את הבאגים.
שמרו על רשומות קצרות ופצלו אותן. רשומה אחת לכל שינוי, שלושה משפטים כל אחת, עדיפה על פוסט חודשי אחד שמכסה הכול. אפשר לקשר לרשומות קצרות בנפרד, לצטט אותן בתשובת תמיכה ולדלג עליהן בלי לאבד את החוט.
הראו כשזה חזותי. צילום מסך או קליפ של חמש שניות עושים יותר מפסקה לכל דבר שמערב מסך. דלגו על זה בעבודת שרת — תמונה של כלום גרועה יותר מאין תמונה.
כתבו למי שלא השתמש ביכולת. הניחו שאין הקשר. נקבו בשם המסך. אם נדרשת הגדרה, אמרו איפה.
אל תאגדו מתוך מבוכה. רשומות קטנות אינן חולשה. יומן שינויים עם אחד-עשר פריטים צנועים בחודש האחרון נקרא כתנופה. פוסט אחד מעוצב בכבדות לרבעון נקרא כחברה שמשחררת אחת לרבעון.
הביאו את זה מול עיני אנשים
יומן שינויים שאיש אינו מבקר בו הוא יומן אישי. ההפצה היא רוב הערך:
- מנויי מייל. תנו לאנשים להצטרף ושלחו בעת הפרסום. זה הערוץ שמגיע למשתמשים שנשרו, כי הוא לא דורש מהם לפתוח קודם את האפליקציה שלכם.
- RSS. זול להציע, וקהל המפתחים באמת עדיין משתמש בו.
- בתוך המוצר. קישור בתפריט או תגית לא פולשנית בתפריט החשבון תופסים משתמשים פעילים ברגע שבו הם יכולים לנסות את הדבר.
- הודיעו ספציפית למבקשים. ההודעה בעלת הערך הגבוה ביותר אינה השידור — היא זו שמספרת לאחד-עשר האנשים שהצביעו עבור משהו שזה קיים עכשיו.
איפה SupDesk נכנסת
SupDesk מספקת מודול יומן שינויים בפורטל שלכם, בדומיין משלכם אם תרצו.
- תוויות חדש / שופר / תוקן בכל רשומה, כך שהעמוד נשאר סריק ככל שהוא גדל.
- מנויי מייל ופיד RSS. פרסום רשומה שולח מייל למנויים שלכם, עם טיפול בהסרה מהרשימה עבורכם.
- הודעה אוטומטית למבקשים. קשרו רשומת יומן שינויים לפוסטי המשוב שהיא פותרת, וכל מי שהצביע לפוסטים האלה יקבל הודעה בעת הפרסום. זה המעגל שנסגר בלי שתנהלו רשימה.
- תרגום מכונה. אפשר לתרגם רשומות לשפות שאתם תומכים בהן באמצעות Cloudflare Workers AI, והתרגום שלכם לבדיקה ולעריכה לפני שהוא עולה לאוויר — מהירות מכונה, מילה אחרונה אנושית.
- מיקוד קהל. פרסמו רשומה לכולם, או רק לתוכנית הבטא שלכם, כששינוי עדיין אינו כללי.
הערה כנה אחת על היקף: רשומות מתפרסמות כשאתם מפרסמים אותן. אין שליחה מתוזמנת, כך שגרסה שיוצאת ב-6 בבוקר עולה ליומן השינויים כשאתם לוחצים על הכפתור, לא לפני.
ההרגל הוא החלק הקשה
המכניקה של יומן שינויים לוקחת אחר צהריים אחד. המשמעת של כתיבת שלוש שורות בכל פעם שאתם מפרסמים היא מה שבאמת מייצר את אפקט השימור, והיא החלק שנשמט ראשון.
הפכו את זה לחלק מהשחרור ולא למשימה שאחריו. הרשומה נכתבת בזמן שאתם עדיין זוכרים מדוע השינוי היה חשוב, וזה גם הזמן שבו הכי קל לכתוב אותה.
הגדירו את יומן השינויים שלכם, רשמו את המשתמשים הראשונים ותנו לגרסה הבאה להכריז על עצמה. התחילו ב-supdesk.app