Pipeline של tickets שלא תואם איך הצוות שלכם באמת עובד ישקר לכם בשקט בכל דוח. המטרה היא לא להוסיף עוד סטטוסים - היא לעצב ticket stages שמשקפים את תהליך התמיכה האמיתי שלכם, כך שה-board ישקף מציאות והמדדים שלכם יאמרו משהו. Pipelines של tickets ב-HubSpot גמישים, וזו בדיוק הסיבה שצוותים בונים אותם עודף. אז ריכזנו לכם את המבט המקצועי על איך מקימים אותם כך שיעזרו, לא יפריעו.
Pipeline של tickets הוא קבוצת ה-stages שבקשת תמיכה עוברת דרכן, מנפתחה ועד נסגרה - וזה מה שכל ה-reporting של התמיכה שלכם בנוי עליו. כל stage מייצג איפה ticket עומד: חדש, מטופל, ממתין ללקוח, נפתר. תסדרו נכון את ה-stages ותוכלו לראות את ה-backlog, זמני התגובה וצווארי הבקבוק במבט אחד. תפספסו אותם ו-tickets ייערמו בדליים עמומים שאף אחד לא בוטח בהם. ה-pipeline הוא לא קישוט - הוא עמוד השדרה של איך אתם מודדים ומנהלים תמיכה.
תמפו את המסע האמיתי ש-ticket עובר דרך הצוות שלכם, ואז תתנו שם לסטטוס לכל handoff או המתנה משמעותיים. תתחילו מאיך העבודה באמת זורמת, לא מתבנית. רוב הצוותים צריכים סטטוס ל-new, in progress, ממתין ללקוח ו-closed - וה-stage של “ממתין ללקוח” חשוב יותר ממה שאנשים מצפים, כי הוא מונע מכם להיענש במדדי time-to-resolution על עיכובים שהם לא שלכם. דוגמה מהשטח: צוות שמערבב “ממתין ללקוח” לתוך “in progress” רואה את זמן הפתרון הממוצע שלו מתנפח ולא מצליח להבחין אם העיכוב הוא בנציג או בלקוח - לפצל את ה-stage הזה לחוד הופך את צוואר הבקבוק לברור.
תבנו אותו בהגדרות תחת Objects ואז Tickets, תוסיפו או תשנו שם ל-stages, ותשתמשו ב-pipelines נפרדים רק כשלצוותים יש תהליכים שונים באמת. ב-HubSpot אתם יכולים לשנות שם לסטטוסים ברירת המחדל, להוסיף חדשים, לסדר אותם מחדש, וליצור pipelines נוספים לצוותים נפרדים - למשל אחד לתמיכת לקוחות ואחד לבקשות IT. תתאפקו מהדחף לתת לכל צוות pipeline משלו; תפצלו רק כשה-stages באמת שונים, כי כל pipeline נוסף הוא עוד דבר לתחזק ולדווח עליו. תשמרו על רשימת ה-stages קצרה מספיק כדי שנציג יוכל לשבץ כל ticket בלי להסס.
תמכנו את המעברים השגרתיים ותגדירו כללים כדי ש-tickets לא ירקבו בשקט בתוך סטטוס. Pipelines נסחפים כשבני אדם צריכים לזכור להזיז כל ticket ביד. תשתמשו באוטומציה כדי לנתב tickets חדשים ל-pipeline ול-owner הנכון, להזכיר לנציגים כש-ticket יושב בלי טיפול, ולעדכן סטטוס בפעולות מפתח. דוגמה מהשטח: ticket בלי תגובה שלושה ימים מפעיל תזכורת פנימית, כך ששום דבר לא נשמט בשקט לתהום. זה אותו סדר שאנחנו מקפידים עליו עם לקוחות - לעצב את ה-stages סביב התהליך האמיתי קודם, ואז לממכן את התנועה כך שה-board יישאר כן בלי שמירה מתמדת.
הצוותים שמפיקים הכי הרבה מ-ticketing של HubSpot הם לא אלה עם ה-pipelines הכי משוכללים - הם אלה שה-stages שלהם תואמים איך העבודה באמת קורית ושהאוטומציה שלהם שומרת על ה-board עדכני. Pipeline נקי ומעוצב היטב הופך תמיכה מקופסה שחורה למערכת שאפשר למדוד ולשפר. המלכודת היא להתייחס לסטטוסים כאל חינמיים; כל אחד נוסף הוא החלטה שנציג צריך לקבל ועמודה שדוח צריך להסביר. פחות stages ואמיתיים יותר מנצחים מפה מסורבלת בכל פעם.
לא בטוחים שה-pipeline של ה-tickets שלכם משקף מציאות? תקבעו אודיט פורטל של 30 דקות - נגיד לכם בדיוק איפה ה-stages והאוטומציה שלכם עובדים נגדכם. לתמונה הרחבה יותר, תראו איך אנחנו ניגשים להטמעה ואופטימיזציה של HubSpot.
כמה סטטוסים של tickets כדאי שיהיו לי?
כמה שתופסים בנקייה את ה-workflow האמיתי שלכם - בדרך כלל ארבעה עד שישה. כל סטטוס צריך לסמן שינוי משמעותי במי אחראי או במה שקורה. יותר מזה ונציגים מהססים וה-reporting מתעמעם.
אפשר שיהיה לי יותר מ-pipeline אחד של tickets ב-HubSpot?
כן. אתם יכולים ליצור pipelines נפרדים לצוותים עם תהליכים שונים באמת, כמו תמיכה ו-IT. תפצלו רק כשה-stages באמת שונים, כי כל pipeline מוסיף תקורת תחזוקה ו-reporting.
כדאי להשתמש בסטטוס של “ממתין ללקוח”?
כמעט תמיד. הוא מפריד בין עיכובים שנגרמו על ידי הלקוח לבין עיכובים שנגרמו על ידי הצוות שלכם, מה ששומר על מדדי זמן-הפתרון כנים ומראה איפה צוואר הבקבוק האמיתי.
אפשר לממכן הזזת tickets בין סטטוסים?
כן. HubSpot מאפשר לנתב tickets, להקצות בעלים, לשלוח תזכורות ולעדכן סטטוס לפי טריגרים, כך ש-tickets לא יושבים נשכחים וה-board נשאר עדכני בלי תחזוקה ידנית.