פיתוח אפליקציית מובייל לתחנות דלק (תדלוק)

אפליקציית מובייל לתחנות דלק: היכן נשבר תרחיש התדלוק

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

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

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

ככל שיש יותר פעולות ידניות במסלול הלקוח, כך עולה הסיכוי שלאחר ניסיון כושל ראשון האפליקציה просто תימחק ולא יחזרו אליה.

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

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

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

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

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

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

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

איך זה משפיע על עבודה ללא רשת

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

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

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

שלבי ההטמעה: מביקורת תרחישים ועד מסירה לצוות

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

איך בנויה הרצף

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

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

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

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

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

מקרה בוחן: איך רשת של עשר נקודות הסירה את התור בקופה

מה היה לפני הפיילוט

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

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

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

הטמעת פיילוט ומדדים

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

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

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

מה לעשות אם ספק אחר כבר מטמיע את הפתרון?

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

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

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

ספקות טכניים לפני התחלה: בקצרה ולעניין

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

מה יקרה אם בתחנת הדלק תיעלם הקליטה?

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

אפשר להשיק לא הכול בבת אחת?

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

איך מתבצעת קבלת העבודה?

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

מה עם תמיכה אחרי ההשקה?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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

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

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