אפליקציית מובייל למוסך — תורים, סטטוסים, התראות פוש

אפליקציית מובייל למוסך רכב: איפה נקרעת קביעת התור

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

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

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

הסיבה אינה משמעת — בין הלקוח, הקבלה והעמדה אין מצב תור אחיד: החלון חי ביומן אחד, העבודה ביומן אחר, והסטטוס בראש שלישי.

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

מה משנה ההשקה: קביעת תורים, סטטוסים, ביקורים חוזרים

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

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

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

פורמט המוצר: חוצה-פלטפורמות, נייטיב, ווב

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

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

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

איך אנחנו מובילים את הפרויקט: מניתוח תהליכים ועד שחרור

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

1. ניתוח תהליכים ותפקידים. אנחנו בודקים איך מקבלים רכב, מי מעביר תור, מה עושים כשהלקוח מסרב — ומתעדים זאת כסכמת סטטוסים של הפנייה, אחידה לאפליקציה ולמערכת הניהול.
2. סכמת נתונים ונקודות אינטגרציה. קובעים אילו ישויות נשארות מקור האמת במערכת הניהול, מה נשמר במטמון באפליקציה ומה נשלף במקום.
3. אב-טיפוס להחלפה. מרכיבים מעגל מינימלי: יצירת פנייה, אישור חלון, שינוי סטטוס. בודקים אידמפוטנטיות — שליחה חוזרת בעת ניתוק קשר לא אמורה ליצור רשומת תור שנייה.
4. הרכבת חלק הלקוח. קביעת תורים, היסטוריית טיפולים, סטטוסי תיקון, התראות push על מוכנות. מצב הסנכרון גלוי למשתמש: הפנייה נשלחה, התקבלה, אושרה.
5. בדיקת תרחישי קביעת תור. מריצים קונפליקטים של חלונות, הזמנות כפולות, ביטול שעה לפני הביקור, עבודה ללא רשת. על עותק אנונימי של מסד הנתונים של המוסך, ולא על נתונים מומצאים.
6. פיילוט בסניף אחד. מסתכלים על זרימה חיה: כמה פניות מגיעות בלי שיחה מהמנהל ואיפה נשבר החיבור עם מערכת הניהול.
7. מסירת הפרויקט ללקוח. קונפיגורציות, סכמת אינטגרציה, נוהל הוצאת עדכונים והדרכת צוות המוסך לעבודה עם פניות.

מה נשאר אצל המוסך: קוד, הרשאות, נהלים

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

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

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

מקרה בוחן: רשת מוסכים — קביעות תור בלי שיחה וסטטוסים

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

מה שינינו

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

סטטוס העבודות משתנה בצד המוסך: "התקבל", "בעבודה", "מוכן למסירה" — ומגיע ללקוח בהודעת push. התור מתווסף ליומן הטלפון (Google Calendar) בלחיצת כפתור אחת.

מה הראו המדדים

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

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

מה לעשות אם למוסך כבר יש מערכת ניהול?

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

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

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

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

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

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

שאלות טכניות לפני תחילת הפיתוח

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

איך יוצאים עדכונים?

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

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

האפליקציה עובדת בלי רשת?

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

התראות עוברות דה-דופליקציה: אירוע אחד — הודעה אחת, גם אם היא הגיעה גם בערוץ הנתונים וגם בפתיחת האפליקציה.

למי שייכות הזכויות באפליקציה?

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

נדון במשימה: קביעת תורים, סטטוסים, התראות

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

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

• איך אתם מנהלים קביעת תורים עכשיו: שיחה, מסנג'ר, גיליון או מערכת ניהול — ובאיזה שלב פנייה הולכת לאיבוד הכי часто.
• מלוא מערך סטטוסי ההזמנה: התקבל, בעבודה, ממתין לחלק, מוכן, נמסר — ומי מהעובדים מחליף אותם ידנית.
• אילו תרחישי קביעת תור נדרשים: בחירת עמדה ומכונאי, חלונות פנויים, העברה וביטול ביקור, פנייה חוזרת לאותו רכב.
• מה ולמי נשלח בהתראות: ללקוח — אישור ומוכנות הרכב, למכונאי — תור חדש, למנהל — עומס יומי.
• הנתונים שאתם עובדים איתם: היסטוריית ביקורים, מספרי רכב ומותגים, האם צריך למשוך אותם מהמערכת הקיימת או להזין מחדש.
• מי בצד שלכם מקבל את התוצאה ועל מה בודקים: חשבונות בדיקה, רשימת תרחישים, הרשאות למערכת קביעת התורים.
• מגבלות שאי אפשר להזיז: תאריך השקה, מספר נקודות שירות, תפקידי עובדים עם הרשאות שונות.

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