CRM לשירות שדה: איך מנהלים טכנאים, קריאות ומלאי ברכב?

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

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

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

מה שובר את היום של טכנאי שירות שדה?

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

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

איך CRM לשירות שדה מסדר את תור הקריאות?

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

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

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

מלאי ברכב: איך יודעים מה נמצא אצל כל טכנאי?

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

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

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

מה הטכנאים צריכים לדווח מהשטח?

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

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

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

מתי ארגון לא צריך מודול שירות שדה?

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

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

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