אפיון תהליך הוא תיאור כתוב של איך תהליך בעסק אמור לעבוד, לפני שבונים אותו במערכת. מה מתחיל אותו, אילו פרטים חייבים להיות, מה קורה בכל שלב, מי אחראי, ומה עושים כשמשהו חורג מהמסלול הרגיל. בדרך כלל זה מסמך של עמוד או שניים, ואפשר להתחיל אותו עם דף ועט.
בלי השלב הזה, גם הכלי הכי טוב יבנה את הדבר הלא נכון. במאמר הזה תמצאו את השאלות שאני שואל באפיון, תבנית שאפשר להעתיק, ודוגמה מלאה של תהליך מליד ועד עסקה.
למה לא מתחילים מהכלי
הרבה עסקים מתחילים מהצד השני. קונים רישיון ל-monday, מחברים בוט, פותחים חשבון ב-Make, ורק אחר כך מנסים להבין מה בעצם צריך לקרות. אחרי כמה שבועות יש עוד מערכות ואותו בלגן.
טכנולוגיה מגבירה את מה שכבר קיים. תהליך עקום שהופך לאוטומטי נשאר עקום, רק מהר יותר ובכמות גדולה יותר. ככה נראות התקלות שאני פוגש:
- מערכת CRM שאנשי המכירות לא ממלאים, כי יש בה עשרים עמודות ואף אחד לא החליט אילו מהן באמת נחוצות.
- דיוורים שיוצאים ללקוחות הלא נכונים, למשל לקוח שכבר רכש וממשיך לקבל מבצע למצטרפים חדשים.
- תרחיש ב-Make שנעצר כל כמה ימים, כי אף אחד לא הגדיר מה קורה כשלליד חסר מספר טלפון.
- כפילויות: אותו לקוח מופיע שלוש פעמים, כי הוא מילא טופס, שלח הודעה באינסטגרם והתקשר.
כל אחת מהבעיות האלה נפתרת בשורה אחת במסמך אפיון. אחרי שהמערכת כבר רצה, התיקון לוקח הרבה יותר.
אני בא מניהול תפעול, ומשם למדתי שרוב הבעיות בארגון נובעות מזה שלא ברור איך המידע זורם בו. מי שבונה מערכת יכול לחבר כל API, אבל השאלה "האם השלב הזה בכלל נחוץ?" שייכת לאפיון.
ארבעת השלבים: מאפיון ועד מערכת שעובדת
- מיפוי המצב הקיים. פורסים את התהליך כמו שהוא קורה היום, מהרגע שליד נכנס ועד שהכסף בבנק. מחפשים את המקומות שבהם מידע נעלם, מישהו מעתיק משהו ידנית, או שמחכים לאדם אחד שיזכור.
- תכנון הזרימה הרצויה. לפני שנוגעים בתוכנה, כותבים איך התהליך אמור לעבוד: איזה מידע עובר מאיפה לאיפה, מה הכללים העסקיים, ומה קורה בכל מקרה חריג.
- בנייה וחיבורים. רק כאן פותחים את הכלים: בונים את הלוחות ב-monday, את התרחישים ב-Make ואת הבוטים. בגלל שהאפיון כבר קיים, הבנייה רק מתרגמת אותו למערכת.
- הרצה ושיפור. מריצים על נתוני בדיקה, אחר כך על לקוחות אמיתיים, ומתקנים לפי מה שקורה בשטח. האפיון מתעדכן יחד עם המערכת.
השאלות שאני שואל באפיון
אלה השאלות שאני עובר עליהן עם בעל העסק, תהליך אחרי תהליך. אפשר לענות עליהן גם לבד.
על התהליך עצמו: - מה מתחיל את התהליך? טופס, הודעה, שיחה, תשלום, תאריך? - מאילו מקורות נכנסות פניות? אתר, פייסבוק, אינסטגרם, וואטסאפ, טלפון? - מה הסוף של התהליך? מתי אפשר להגיד שהוא נגמר? - האם יש שלב שאפשר פשוט לבטל?
על המידע: - אילו פרטים חייבים להיות כדי להתקדם? (שם, טלפון, סוג שירות) - מה עושים כשאחד מהם חסר? - איך מזהים לקוח שכבר קיים במערכת? לפי טלפון, מייל, או שניהם? - איפה המידע נשמר, ומי צריך לראות אותו?
על אנשים: - מי אחראי על כל שלב? - מי מקבל התראה כשמשהו נתקע, ותוך כמה זמן הוא צריך לטפל? - מה איש המכירות צריך לראות על המסך כדי לסגור עסקה, ומה אפשר להסתיר ממנו?
על מקרי קצה: - מה קורה כשאותו אדם פונה פעמיים? - מה קורה כשלקוח מבטל, דוחה או לא עונה? - מה קורה כשלקוח קיים פונה שוב, הפעם על שירות אחר?
תבנית אפיון שאפשר להעתיק
זה המבנה שאני משתמש בו לכל תהליך. מעתיקים למסמך, ממלאים שורה אחרי שורה, ואם משהו לא ברור, זה בדיוק המקום לעצור ולהחליט לפני שבונים.
- שם התהליך: (למשל: ליד חדש מהאתר)
- מטרה: מה צריך לקרות בסוף, במשפט אחד.
- טריגר: האירוע שמתחיל את התהליך.
- מקורות: מאיפה מגיע המידע.
- שדות חובה: מה חייב להיות כדי להתקדם, ומה עושים כשהוא חסר.
- זיהוי כפילויות: לפי מה בודקים אם הרשומה כבר קיימת.
- שלבים: רשימה ממוספרת של מה קורה, בסדר הנכון.
- אחראים: מי מטפל בכל שלב.
- מקרי קצה: ביטול, אי-מענה, פנייה כפולה, מידע שגוי.
- התראות: מי מקבל הודעה כשמשהו נכשל, ואיפה (מייל, וואטסאפ, monday).
- מערכות: אילו כלים מעורבים, ומה עובר ביניהם.
- איך נדע שזה עובד: משהו שאפשר לבדוק, כמו "כל ליד מקבל מענה תוך חמש דקות".
דוגמה מלאה: מליד חדש ועד עסקה
כך נראה אפיון של תהליך מכירה בעסק שירות קטן, שמקבל פניות מהאתר ומאינסטגרם, מנהל לקוחות ב-monday ושולח דיוורים ב-Smoove. החיבורים בין המערכות עוברים דרך Make.
| שלב | טריגר | פעולה | מקרה קצה |
|---|---|---|---|
| ליד נכנס | טופס באתר, או הודעה באינסטגרם דרך ManyChat | Make בודק אם הטלפון כבר קיים ב-monday. אם כן, מעדכן את הכרטיס הקיים. אם לא, פותח כרטיס חדש | חסר טלפון: הכרטיס נפתח בסטטוס "חסרים פרטים" ונשלחת למישהו משימה להשלים |
| מענה ראשון | כרטיס חדש נפתח | הליד מקבל הודעה שהפנייה התקבלה, ונפתחת משימה לאיש המכירות לחזור אליו | פנייה בשעה מאוחרת: ההודעה יוצאת מיד, המשימה מתוזמנת לבוקר |
| הצעת מחיר | סטטוס משתנה ל"נשלחה הצעה" | נפתחת משימת מעקב לעוד שלושה ימים | הלקוח ביקש לחזור אליו בעוד חודש: מעדכנים תאריך, והמשימה זזה |
| הצעה אושרה | סטטוס משתנה ל"הצעה אושרה" | נפתח פרויקט בלוח הפרויקטים, נוצרת משימה לתפעול, והלקוח מקבל מייל תודה עם השלבים הבאים | ההצעה אושרה בטלפון ולא בכתב: הסטטוס לא משתנה עד שיש אישור כתוב |
| לקוח פעיל | הלקוח שילם | Make מעביר אותו ב-Smoove לרשימת לקוחות ומוציא אותו מסדרת המיילים למתעניינים | הלקוח נרשם בעבר לניוזלטר במייל אחר: הזיהוי נעשה לפי טלפון |
שימו לב לעמודה האחרונה. רוב העבודה באפיון נמצאת שם. את המסלול הרגיל כל אחד יודע לתאר. מה שמפיל מערכות הוא הליד בלי טלפון, הלקוח שפנה פעמיים, והלקוח שכבר רכש וממשיך לקבל מבצע הצטרפות.
שלב "הצעה אושרה" הוא דוגמה טובה למה שאפיון נותן. בלי אפיון, איש המכירות מעדכן סטטוס, ואז צריך לזכור לפתוח פרויקט, להודיע לתפעול ולשלוח ללקוח מייל. עם אפיון, ההחלטה מה קורה ברגע הזה התקבלה פעם אחת, וכל לקוח מקבל את אותו טיפול בלי קשר למי שעבד באותו יום.
כמה זמן לוקח אפיון, ומה מקבלים בסוף
זה תלוי בגודל. תהליך אחד, כמו קליטת לידים מהאתר, אפשר לאפיין בשיחה אחת מסודרת. מערכת שלמה, עם מכירות, תפעול, חשבוניות ודיוור, לוקחת יותר, כי כל תהליך נוגע בתהליכים אחרים.
בסוף האפיון יש מסמך שמתאר כל תהליך לפי התבנית שלמעלה, עם תרשים זרימה. המסמך הזה שימושי גם אם תבנו לבד, גם אם תעבדו עם מישהו אחר, וגם בעוד שנה, כשתרצו להבין למה המערכת עובדת כמו שהיא עובדת.
אצלי, אפיון הוא השלב הראשון בכל פרויקט של אוטומציה לעסקים ושל מערכת CRM לניהול לקוחות. אם אתם רק מתחילים להכיר את התחום, כדאי לקרוא קודם את המדריך למה זו אוטומציה עסקית, ואחר כך את הטעויות הנפוצות בהטמעת מערכת חדשה, שרובן מתחילות בדילוג על השלב הזה.
אם יש לכם תהליך שאתם רוצים לאפיין ולא בטוחים מאיפה להתחיל, אפשר לכתוב לי בוואטסאפ ונעבור עליו יחד.
