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

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

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

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

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

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

בהמשך נפרט ממה מורכב פורטל כזה והיכן בדיוק מתפנה הזמן של מחלקת המכירות.

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

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

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

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

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

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

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

אפשרויות מימוש: פלטפורמה, הרחבה, פיתוח עצמאי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה שינינו

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

נתוני הנכסים סונכרנו עם наш.дом.рф: הצהרות תכנון ודוחות צילומיים נמשכים אוטומטית, וההזנה הידנית שלהם הוסרה.

מדדים לפני ואחרי

איחוד הסטטוסים הצטמצם מ-5–6 שעות ל-15–20 דקות ביום, ושיעור הפעולות הידניות בעסקה ירד בערך פי שלושה. הזמנות כפולות נעלמו כליל: הנעילה על היחידה אינה מאפשרת לשני מנהלים למכור את אותה דירה בו-זמנית, והיסטוריית השינויים מראה מי ומתי ביטל הזמנה.

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

במה נבדל לוח מכירות עצמאי מאינטגרציה עם מערכת מכירות?

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

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

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

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

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

שאלות נפוצות על לוח המכירות, ההזמנה והאזור האישי של הרוכש

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

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

כיצד בנויים הייצואים למערכות חיצוניות?

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

מה קורה לנתונים עם החלפת ספק?

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

כיצד מופרדות הרשאות העובדים?

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

האם המערכת תעמוד ביום פתיחת המכירות?

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

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

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

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

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

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