החלפת טפסים מרובי-שלבים בדיאלוג טבעי היא משימה מרכזית בהזמנת שולחנות או חדרים. משתמש כותב: "שולחן לשניים, מחר בשעה 19:00, ליד החלון, אזור ללא עישון" — והבוט מחלץ מיידית את כל הפרמטרים, בודק זמינות דרך ה-PMS, ומציע משבצת. אין צורך בשלושה בוררים נפרדים. גישה זו מקצרת את זמן ההזמנה ב-30% ומפחיתה פגישות נטושות ב-15%. פרסנו למעלה מ-10 פתרונות כאלה למסעדות ובתי מלון, ואנו מבטיחים ביצועים יציבים תחת עומס. עלות הפיתוח תלויה במורכבות האינטגרציה, אך החיסכון בזמן העובד מחזיר את ההשקעה תוך 3–5 חודשים.
כיצד הבוט מבין את הבקשה ומחלץ פרמטרים
להזמנת שולחן, המשבצות האופייניות הן: תאריך, שעה, גודל קבוצה, העדפת אזור (טרסה, אולם ראשי, בר), אירוע, שם אורח. הבוט חייב לזהות אותן במשפט אחד. אנו משתמשים בשתי גישות.
NLU קלאסי: Dialogflow CX עם ישויות מערכת @sys.date-time ו-@sys.number מכסה מקרים בסיסיים. עבור Rasa, אנו משתמשים ב-duckling כחלץ ישויות בתוספת ישויות מותאמות לסוגי אזורים. דיוק החילוץ בתרחישי בדיקה: 92%.
LLM עם פלט מובנה: כאשר הבקשה מורכבת יותר או נדרש דיוק גבוה, אנו מיישמים מודל עם JSON Schema. לדוגמה, בהתבסס על OpenAI Structured Outputs:
from openai import OpenAI
from pydantic import BaseModel
class BookingSlots(BaseModel):
date: str | None = None # ISO 8601
time: str | None = None # HH:MM
party_size: int | None = None
zone_preference: str | None = None
guest_name: str | None = None
occasion: str | None = None
response = await client.beta.chat.completions.parse(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "Извлеки параметры бронирования из текста пользователя."},
{"role": "user", "content": user_message}
],
response_format=BookingSlots
)
slots = response.choices[0].message.parsed
המודל מחזיר רק את השדות הקיימים בהודעה. הבוט שואל על השדות החסרים אחד-אחד — זה דיאלוג טבעי, לא טופס. עם LLM, הדיוק מגיע ל-97% — 5 נקודות אחוז יותר טוב מגישות קלאסיות. עם זאת, LLM דורש יותר משאבי מחשוב, ולכן לתרחישים פשוטים אנו משתמשים ב-Dialogflow CX.
מדוע בוט יעיל יותר מטופס
טופס עם בוררים מאלץ את המשתמש לבחור כל פרמטר ברצף, מה שמעצבן ומאריך את הזמן. בוט עם NLU מעבד את הבקשה בשלב אחד — ומפחית עומס קוגניטיבי. בפרויקט אחד לרשת בתי קפה, החלפנו טופס בן 5 שלבים בדיאלוג, והמרת ההזמנות עלתה ב-25%. זמן ההזמנה הממוצע ירד מ-45 ל-12 שניות.
בדיקת זמינות בזמן אמת
לפני הצגת משבצת, עלינו לוודא שהיא פנויה. אנו מתממשקים למערכת ההזמנות של המקום:
- מסעדות: iiko, r_keeper, Tillypad — לכל אחת יש API להזמנות.
- בתי מלון: Opera PMS, Fidelio, Apaleo (דרך Channel Manager).
- מערכות מותאמות: REST API עם נקודת קצה למשבצות פנויות.
חשוב להחזיר לא רק "פנוי/תפוס" אלא רשימת חלופות. אם הזמן המבוקש תפוס, הבוט מציע 3–5 משבצות פנויות קרובות. זה מעלה את המרת האישור ב-20%.
כיצד להימנע מהזמנה כפולה?
בין "הצגת המשבצת" ל"אישור המשתמש", עוברות 2–3 דקות. בזמן זה, אורח אחר עלול לתפוס את המשבצת. פתרון: נעילה אופטימית עם TTL קצר. בעת הצגת משבצת, שלח from openai import OpenAI from pydantic import BaseModel class BookingSlots(BaseModel): date: str | None = None # ISO 8601 time: str | None = None # HH:MM party_size: int | None = None zone_preference: str | None = None guest_name: str | None = None occasion: str | None = None response = await client.beta.chat.completions.parse( model="gpt-4o-mini", messages=[ {"role": "system", "content": "Извлеки параметры бронирования из текста пользователя."}, {"role": "user", "content": user_message} ], response_format=BookingSlots ) slots = response.choices[0].message.parsed עם TTL של 3 דקות. בעת אישור, שלח PUT /reservations/hold. אם המשתמש לא מאשר, הנעילה משתחררת אוטומטית.
אנו מציגים טיימר ספירה לאחור: "השולחן שמור ל-3:00" — זה מפחית חרדה ומאיץ את קבלת ההחלטות ב-20% בהשוואה לנעילה ללא טיימר. אנו מיישמים זאת בלקוח הנייד:
// Android: таймер обратного отсчёта
class BookingViewModel : ViewModel() {
private var holdExpiresAt: Long = 0
fun startHoldCountdown(ttlSeconds: Int) {
holdExpiresAt = System.currentTimeMillis() + ttlSeconds * 1000L
viewModelScope.launch {
while (System.currentTimeMillis() < holdExpiresAt) {
val remaining = (holdExpiresAt - System.currentTimeMillis()) / 1000
_holdCountdown.emit(remaining)
delay(1000)
}
_holdExpired.emit(Unit)
}
}
} רכיבי UI לאפליקציה הניידת
| רכיב | אנדרואיד | iOS |
|---|---|---|
| תוכנית קומה (רשת שולחנות) | POST /reservations/confirm ב-Jetpack Compose | // Android: таймер обратного отсчёта class BookingViewModel : ViewModel() { private var holdExpiresAt: Long = 0 fun startHoldCountdown(ttlSeconds: Int) { holdExpiresAt = System.currentTimeMillis() + ttlSeconds * 1000L viewModelScope.launch { while (System.currentTimeMillis() < holdExpiresAt) { val remaining = (holdExpiresAt - System.currentTimeMillis()) / 1000 _holdCountdown.emit(remaining) delay(1000) } _holdExpired.emit(Unit) } } } ב-SwiftUI או UIKit |
| כרטיס אישור | MaterialCardView | SwiftUI Card |
| לוח שנה ומשבצות זמן | Material Calendar | UIKit DatePicker או SwiftUI DatePicker |
| הוספה ללוח שנה | CalendarContract API | EventKit API |
שינוי וביטול הזמנות מתבצעים גם דרך הבוט: המשתמש מקליד "בטל הזמנה" או "קבע מחדש למחר". הבוט מזהה את הפקודה, מוצא את ההזמנה הפעילה לפי החשבון, קורא ל-API ומאשר את השינוי.
מה כלול בעבודה
- ניתוח מערכת ההזמנות של המקום, תיעוד API.
- עיצוב דיאלוג: משבצות חובה ואופציונליות, חלופות כשתפוס.
- פיתוח צד שרת: אינטגרציה עם PMS/API הזמנות, לוגיקת נעילה.
- UI נייד: דיאלוג עם רכיבים מובנים, כרטיס אישור, לוח שנה.
- הגדרת התראות Push לאישור ותזכורות.
- בדיקות מצד המשתמש ובדיקות עומס תחת בקשות מקבילות.
- תיעוד אינטגרציה והדרכת צוות.
- אחריות על קוד למשך 3 חודשים לאחר ההשקה.
הערכות לוחות זמנים
| מורכבות | לוח זמנים |
|---|---|
| בוט בסיסי עם API הזמנות קיים, דיאלוג פשוט | 1–2 שבועות |
| + תוכנית קומה מותאמת, אינטגרציית PMS מורכבת, התראות | 3–5 שבועות |
צרו קשר — נבחן את הפרויקט שלכם ונספק לוחות זמנים מדויקים. הניסיון שלנו: למעלה מ-10 בוטים להזמנות שהושקו בהצלחה למסעדות ובתי מלון. קבלו ייעוץ — נספר לכם כיצד לקצר את זמן ההזמנה ולהעלות את ההמרה.







