פיתוח פורטל לסוכנות חתונות

פיתוח פורטל לסוכנות חתונות: איפה נשבר ניהול הפניות

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

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

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

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

מה משתנה אחרי ההשקה: מהירות הטיפול וסוגי הכשלים

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

זמן הטיפול בפנייה

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

עומס המנהלים ופעולות ידניות

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

משימות באיחור ופניות חוזרות

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

אפשרויות הרכבה: ליבה מוכנה, בונה אתרים, מימוש נפרד

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

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

איך מתנהלת העבודה: מראיונות ועד מסירת הניהול

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

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

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

מה אנחנו מוסרים: קונפיגורציות, הרשאות גישה, תקנונים וסכמות

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

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

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

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

איך זה היה

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

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

מה שינו ומה נהיה

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

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

במה שונה קטלוג הספקים מהאזור האישי של הזוג

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

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

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

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

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

ספקות טכניים: אינטגרציות, עומס, מיגרציה

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

הפורטל יעמוד בעונה?

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

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

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

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

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

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

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

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

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

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