הפיילוט עם דייב הצליח. עכשיו עולים לאוויר עם כל הסוכנים. לפני זה - אישור הסקופ והשעות לספרינט הקרוב.
הספרינט הראשון הסתיים. רועי יכול לשייך Desk לסוכן בלחיצה, הסוכן מקבל הודעת טלגרם מסודרת, והמערכת עוקבת אוטומטית אחרי מה שקרה. בדקנו את כל זה בלייב עם דייב - וזה עובד.
מהפגישה האחרונה יצאנו עם החלטה ברורה: עולים לאוויר עם כל הסוכנים ומתחילים לעבוד עם המערכת באמת. תוך כדי העבודה היומיומית נבין אילו שיפורים הכי חשובים - אבל יש כמה דברים שצריך לסגור כבר עכשיו כדי שהעבודה תהיה נוחה.
הפיצ'רים שצריך לפני / יחד עם העלייה לאוויר עם כל הסוכנים, ובנוסף חיבור קובץ הדילים. שאר הרעיונות מהפגישה (כרטיסייה נפתחת, מיני-טלגרם מלא, וכו') מרוכזים בהמשך כ"ספרינט הבא" - לא נכללים באישור הזה.
| מונח | פירוש |
|---|---|
| Desk | לקוח / ברוקר ב-network ספציפית. |
| Group | שם אחיד שמאחד מספר Desks שמייצגים את אותה ישות עסקית. |
| Stage | שלב המכירה של ה-Desk (לא שויך, פנייה ראשונה, קיבל מענה, נפתחה קבוצה וכו'). ציר אחד מההתחלה ועד הסגירה. |
| Rejected | מצב צדדי - Desk שנדחה או לא רלוונטי (אפשר מכל שלב), נשמר ולא נמחק. |
| Assign | שיוך של Desk לסוכן ב-network מסוימת. |
אחרי הפגישה ניגשנו ישר לעמודת ה-Group שהופיעה ריקה - וסגרנו אותה. זה כבר עובד בלייב, וזה כלול בעבודה הקיימת (לא נספר בשעות של ההצעה הזו).
מילאנו את ה-Group לכל הלקוחות. כל אחד מ-290 הלקוחות מקבל עכשיו את שם הקבוצה שלו מתוך השיט שלכם. 16 קבוצות מאגדות תחתן כמה Desks (למשל FIDELITY שמאחדת כמה ברוקרים), והשאר עומדים בפני עצמם. תיקנו גם את המיון על העמודה: הקבוצות האמיתיות עולות למעלה לפי א-ב, והשורות הבודדות יורדות לתחתית, כך שקל לראות מי מאוגד תחת מי.
שימו לב שאם השם של הדסק זה גם השם של הגרופ - לא שמתי ערך בגרופ. חשבתי שזה עדיף, אם רוצים אחרת אז אפשר.
7 פיצ'רים, לפי סדר העבודה:
לכל Desk סטטוס אחד שמראה איפה הוא בתהליך, מ"עוד לא שויך" ועד "נסגר":
Unassigned → Pending → Reach out → Got reply → Group Created → Integration → Deal created → Archived
ובנוסף מצב צדדי - Rejected / Not relevant - כש-Desk נדחה או לא רלוונטי (אפשר מכל שלב). עמודה אחת + צביעת שורה לפי שלב + פילטר. המערכת מזהה את השלב לבד מהטלגרם - הסוכן לא מדווח כלום.
הערה חשובה: רוב השלבים מזוהים אוטומטית מהטלגרם כבר מהיום הראשון. פנייה ראשונה = הסוכן שלח DM ליוזר. קיבל מענה = היוזר ענה בחזרה באותה שיחה (תוספת פיתוח קטנה לזיהוי הודעה נכנסת). נפתחה קבוצה = כבר עובד אוטומטית. שני שלבים ממתינים למקורות נתונים: התחברות טכנית דורש הגדרה אתכם מאיפה לוקחים את המידע, ודיל נסגר מתחבר יחד עם קובץ הדילים.
זה כבר חלק מציר השלבים למעלה: "לא שויך" הוא פשוט השלב הראשון (Unassigned). הוספנו כאן רק את הכפתור המהיר "תראה לי את כל מה שעוד לא שייכתי" ואת צביעת הרקע שמבדילה שורות ששויכו. זה הלב של העבודה היומיומית - מנגיש את הפורטפוליו שלא נוצל.
מסך הגדרות לניהול כל אנשי SmartAds: מי העובד, איזה משתמש טלגרם, מס׳ טלפון, סיסמאת 2fa ופרטים נוספים. תמיד מעודכן - בלי שצריך לגעת במסד הנתונים. משם מגיע גם החיבור של הסוכנים וגם הסינון של אנשי הצוות מהיוזרים שבקבוצות. כשעובד חדש מצטרף גם יהיה אפשר להגדיר שם את הנתונים כדי שהמערכת תדבר עם הכל.
כפתורים מוכנים במקום לסנן ידנית כל פעם: "לא שויכו" · "לפי שלב" · "תקוע X ימים" · "לפי סוכן". לחיצה אחת = התצוגה שצריך. (לדעתי תו״כ תנועה נוכל לאפיין ולהבין איזה views רוצים, אז אלו כהתחלה ונוכל להרחיב תמיד)
כאן נכנסת גם התשתית למעקב זמן-בשלב: המערכת מתעדת מתי כל Desk נכנס לשלב הנוכחי, כך ש"תקוע X ימים" מדויק לגמרי. התשתית הזו היא הבסיס לפיצ'ר "חיות שלב" הבא.
חיבור 5-7 הסוכנים למערכת החיה (עד עכשיו רק דייב בפיילוט). התהליך: אתם מוסיפים את הסוכן החדש דרך מסך ההגדרות (SmartAds Directory), ואני מוסיף אותו ידנית עם סיסמה, טלפון וקוד התחברות. כל סוכן מחובר ל-JangoBot ומסונן מרשימות הקונטקטים.
נקודה לוודא בדרך: בפיילוט עבדנו עם סוכן אחד (דייב = session אחד). לפני העלייה לאוויר נוודא שהמערכת מטפלת בכמה סוכנים במקביל - לכל סוכן ה-session/listener שלו, וכל הודעה מיוחסת לסוכן הנכון. - חלק משמעותי בבדיקות ובעליית המערכת לוודא שהכל רץ.
המערכת עוקבת כמה זמן כל Desk יושב בשלב הנוכחי, וצובעת אוטומטית מה שתקוע יותר מדי (למשל אדום מעל 10 ימים בלי תזוזה). ככה רואים במבט מי נתקע ודורש טיפול, בלי לחפש ידנית. זול יחסית כי התשתית כבר נבנתה ב-Views - כאן רק התצוגה והצביעה.
ריחוף על השלב "קיבל מענה" יציג את התגובה שהברוקר שלח - כך רואים במהירות מה ענו בלי להיכנס לטלגרם. ההודעות כבר נשמרות אצלנו, אז זו בעיקר תצוגה. (תצוגת מיני-טלגרם עשירה יותר של כל השיחה - בשלב מאוחר יותר.)
קיבלנו גישה לקובץ ובדקנו אותו (1,601 שורות דילים, 25 עמודות). נעשה שלושה דברים: (1) נסדר את מבנה הקובץ, (2) נוודא שהנתונים תקינים, (3) נחבר סנכרון חד-כיווני מ-Sheets למערכת - אתם ממשיכים לערוך דילים ב-Sheets כרגיל, והמערכת קוראת משם. החיבור מזין את ה-geos (לפי 90 יום) ואת השלב "דיל נסגר".
למה אחרי חיבור הסוכנים: ברגע שכל הסוכנים מחוברים והמערכת קוראת את הקבוצות, יש לנו את מזהה הטלגרם של כל ברוקר - וזה הופך את חיבור הדילים לנקי ומדויק מההתחלה, בלי לבזבז זמן על התאמת שמות חלקית. לכן הסדר הנכון: סוכנים קודם, דילים אחריהם.
בזמן התכנון עלו כמה נקודות שכדאי לסגור מולכם לפני / תוך כדי הבנייה. אף אחת מהן לא חוסמת את ההתחלה - אבל התשובות יחדדו את התוצאה:
הרעיונות הבאים עלו בפגישה ונשמרו לספרינט הבא - לא נכללים באישור הזה:
שבעת הפיצ'רים של הספרינט בטווח של 29.5-45 שעות, ובנוסף חיבור הדילים כפריט נפרד שמגיע אחרי חיבור הסוכנים (6-12 שעות):
| פיצ'ר | שעות |
|---|---|
| Stages - שלבי מכירה, זיהוי אוטומטי, עמודה + צביעה + פילטר | 5-9 |
| Assigned / Not-assigned - כפתור מהיר + צביעה (חלק מהשלבים) | 0.5-1.5 |
| SmartAds Directory - מסך הגדרות לניהול אנשי הצוות | 5-9 |
| Views - תצוגות מוכנות + תשתית מעקב זמן-בשלב | 5-9 |
| חיבור כל הסוכנים - סקריפט חיבור + ריבוי סוכנים + ודאות ייחוס | 9-15 |
| חיות שלב - מעקב תקיעות + צביעה לפי גיל | 2-4 |
| שיקוף התגובה - ריחוף על "קיבל מענה" מציג מה הברוקר ענה | 3-5 |
| סה"כ הספרינט (7 פיצ'רים) | 29.5-45 |
| חיבור קובץ הדילים (נפרד, אחרי הסוכנים) - סדר מבנה + בדיקה + סנכרון חד-כיווני | 6-12 |
כל פיצ'ר מפותח מקצה לקצה - כולל אפיון, בנייה, בדיקות על המערכת החיה, ותיקונים. השעות בטבלה כבר כוללות את כל זה, לא רק כתיבת קוד. טווחי הערכה מבוססים - בדקנו כל פיצ'ר מול הקוד הקיים. השעות שיבוצעו בפועל הן אלו שאחייב עליהן בסוף.
מאשרים את הסקופ והשעות ← אני מתחיל בחיבור הסוכנים ובשלבי המכירה (הדברים הראשונים) ← בונה את שאר הפיצ'רים ← ומתחילים לעבוד עם המערכת בלייב. תוך כדי העבודה נבין אילו פיצ'רים מספרינט הבא הכי דחופים, ונתעדף אותם ביחד.