פיתוח אתר למרפאת שיניים: היכן נשברת ההרשמה המקוונת
אתר של מרפאת שיניים כמעט תמיד נתקע בדבר אחד — ההרשמה המקוונת. כל עוד זה טופס בקשה פשוט, הכול עובד; ברגע שהוא אמור להציג חלונות פנויים אמיתיים של תורים ולסגור אותם עבור המטופל, מתחילה אי-התאמה בין מה שהמבקר רואה באתר לבין מה שקורה במרפאה.
הכשל הטיפוסי הראשון — לוח הזמנים חי בשני מקומות: ביומן של המנהל ובבסיס הנתונים של האתר. עד הסנכרון הקרוב החלונות לא תואמים, והרשמה לרופא דרך האתר מובילה לתור שכבר הועבר או תפוס בטלפון. הרופא ממתין למטופל שלא יגיע, והמטופל מגיע לדלת סגורה.
השני — אובדן בקשות. טופס ב-1С-Битрикс נשלח כמייל לתיבה כללית: אם הוא נופל לספאם או לא מטופל עד סוף המשמרת, זה אומר שהאדם כבר נרשם למרפאה אחרת. צרה נפרדת — הזמנה כפולה, כששניים בוחרים אותו זמן, כי החלון לא נחסם למשך מילוי הפרטים.
השלישי — עבודה ידנית. נתוני המטופל מועברים למערכת החשבונאית של המרפאה ביד: שם, טלפון, סוג תור, רופא, הערה. מכאן שגיאות הקלדה בשמות משפחה, כרטיסים כפולים ושעות עבודה של המנהל במקום עבודה עם אלה שכבר הגיעו.
לרוב ההרשמה המקוונת במרפאת שיניים נשברת לא בגלל חוסר בפונקציות, אלא בגלל שהאתר ומערכת החשבונאות חיים בנפרד. בפיתוח אתר למרפאת שיניים זה מטופל בחיבור ליומן תורים אמיתי — נפרט איך זה נסגר.
מה משתנה אחרי השקת האתר מחדש של המרפאה
להשקת אתר המרפאה מחדש יש משמעות לא כשהאתר נהיה מסודר יותר, אלא כשההרשמה לתור מפסיקה ללכת לאיבוד בין שיחות לטבלאות. חודש אחרי העלייה לאוויר עוברים עם המרפאה על אותה רשימה — היא גם משמשת קריטריון לקבלה.
- שיעור ההרשמות שהושלמו עד אישור. בודקים היכן הבקשה נושרת: בבחירת רופא, זמן או הזנת פרטי קשר.
- מהירות ההרשמה המקוונת. סופרים מספר שלבים וזמן הרשמה מהטלפון: המטרה — להספיק לפני שהמטופל מתחרט.
- טפסי הרשמה נטושים. מנתחים טפסים שלא הושלמו: הסיבה בדרך כלל בשדות חובה נסתרים ובסלוטים תפוסים שמוצגים בכל זאת.
- זמן תגובה לבקשה. הבקשה מגיעה למנהל מיד ועם הקשר — מתעדים את הזמן משליחת הטופס עד השיחה למטופל.
- עומס על המנהלים. סופרים את שיעור ההרשמות שנוצרו בלי שיחה ושאלות הבהרה — אלה הידיים שהתפנו בקבלה.
- לוח הזמנים של הרופאים באתר. משווים את רשת התורים, החופשות וההחלפות עם המצב בפועל: קבוצת השגיאות נסגרת בכך שהאתר לוקח את לוח הזמנים ממערכת החשבונאות של המרפאה, ולא מקובץ נפרד. פרויקט על 1С-Битрикс מושך אותו מאותו מקור שממנו מושכות עמדות העבודה של המנהלים.
אם לפחות סעיף אחד לא תואם, מנתחים את הסיבה לפני שסופרים את העבודות כנמסרו: תיקונים במקומות כאלה עולים פחות מהשקה מחדש חוזרת.
פורמטים של מימוש: ענן, התקנה עצמית, היברידי
את מצב האחסון בוחרים לא לפי נוחות הפיתוח, אלא לפי היכן נמצאים נתוני המטופלים ומי אחראי על הזמינות. אתר מרפאה בענן עולה מהר יותר ולא דורש מהמרפאה חדר שרתים, אבל הפרטים האישיים עוברים לצד של ספק שירותי האחסון. גרסת הקופסה של האתר משאירה הכול בתוך ההיקף, אבל מעבירה את העדכונים, הגיבויים והגנת ההיקף למרפאה.
בכל שלושת המצבים לוח הזמנים של הרופאים, גלריית העבודות ומודול ההרשמה המקוונת נבנים מאותם בלוקים — משתנה רק שכבת האחסון. לכן מעבר בין פורמטים אפשרי מאוחר יותר, בלי לכתוב את האתר מחדש: מועברים בסיס הנתונים והגדרות הסביבה, הפריסה ולוגיקת ההרשמה נשארות.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| ענן | סניף אחד או שניים, אין מערך מחשוב עצמאי, ההרשמה נדרשת מהר | נתוני המטופלים אצל ספק שירותי האחסון; גם ההגדרה העמוקה של הסביבה מנוהלת על ידו |
| גרסת קופסה של האתר על שרת המרפאה | יש מנהל מערכת עצמאי ודרישות להחזיק נתונים רפואיים בהיקף סגור | עדכונים, גיבויים והגנה — אזור המרפאה; זמן ההשקה ארוך יותר |
| תוכנית אחסון היברידית | האתר וההרשמה בענן, וכרטיסי המטופלים והחיבור למערכת הרפואית — בפנים | שני היקפים, נדרשים ערוצים מאובטחים ותקנון סנכרון |
אנחנו לא כופים מצב אחד: סופרים את מספר הסניפים, קיום מנהל מערכת והדרישות לאחסון נתונים רפואיים — ומציעים את זה שיחזיק את העומס על ההרשמה.
שלבי ההטמעה: מביקורת ועד מסירת גישות
מבצעים את העבודות באיטרציות — אחרי כל שלב המרפאה רואה תוצאה בסביבת בדיקה: ההרשמה נפתחת, לוח הזמנים נבדק, ביטולים מטופלים. להלן הסדר שבו הפרויקט הולך מהבדיקה הראשונה ועד מסירת הגישות.
- ביקורת אתר המרפאה. מנתחים את האתר הנוכחי ואת מערכת החשבונאות: מאיפה מגיע לוח הזמנים של הרופאים, איך נוצרים שירותים ומחירים, היכן כפילויות. בסיום — מפת קשרים ורשימת צווארי בקבוק לפי עדיפות.
- תכנון הקשרים. קובעים מקור אמת ללוח הזמנים ולתפוסה, אופן החלפת נתונים בין האתר למערכת החשבונאות, כללי ביטול והעברה. את הסכמה מתעדים בכתב לפני תחילת ההגדרה.
- הגדרת ההרשמה המקוונת. בונים בחירת רופא, שירות וסלוט, אישורים והתראות. קובעים כללים: כמה סלוטים זמינים אונליין, מה המטופל רואה כשהמקום תפוס, איך נרשמים לכמה תורים.
- העברת לוח הזמנים של הרופאים. טוענים ספרי עזר ולוחות זמנים, משווים תפוסה מול מערכת החשבונאות, מפעילים מצב מקביל כדי שהרשמות קיימות לא יאבדו.
- בדיקה בעומס. מריצים הרשמה בשיא, פניות בו-זמנית, ביטול דקה לפני התור, אי-זמינות של מערכת חיצונית. בודקים מה המטופל רואה ומה מגיע למנהל.
- קבלת העבודות. עוברים על רשימת הבדיקות: תרחישי הרשמה, התראות, ייצוא, הרשאות גישה, התנהגות בתקלות. אי-התאמות מתקנים עד לחתימה.
- מסירת גישות. מוסרים את התצורה, סכמת הקשרים, התקנונים וההרשאות למנהלי המרפאה; מראים איך לשנות לוח זמנים ושירותים בלי מפתח.
מה נשאר למרפאה: מסמכים, סכמות, גישות
אחרי ההשקה נשאר למרפאה לא רק אתר עובד, אלא גם ערכה שלפיה הצוות שלה עובד באופן עצמאי. מוסרים בקבצים ובסכמות, לא בסיפור מחדש: מנהל חדש נכנס לעבודה בערב אחד, במקום לפרק לוגיקה זרה לפי סימנים עקיפים.
- תצורת האתר: מבנה בלוקי המידע, תבניות עמודים, הגדרות טופס ההרשמה המקוונת וכללי הצגת הגלריה — מה אפשר לשנות ומה נוגע בפריסה.
- סכמת האינטגרציה עם 1С והמערכת הרפואית: אילו נתונים ובאיזה כיוון עוברים, תקופת ההחלפה, התנהגות כשאין מקור, היכן לראות יומן.
- מדיניות גישה ותפקידים: מנהל, רופא, מנהל תוכן, קבלן — לכל אחד סט הרשאות משלו, בלי חשבונות משותפים.
- תקנון המנהל: פרסום מחירון, הוספת רופא, עדכון לוח זמנים וגלריה, סדר פעולות בתקלת טופס הרשמה.
- סדר עדכוני הליבה והמודולים של 1С-Битрикс: סביבת בדיקה, חלון תחזוקה, בדיקת תרחישי מפתח, חזרה למצב הקודם.
- גיבויים וגישות: מה ובאיזו תדירות מגובים, איך משחזרים לתאריך מסוים, למי הועברו מחדש אחסון האתר, הדומיין, הדואר והאנליטיקה.
במסמך נפרד נמצא יומן השינויים: מי ומתי שינה את התצורה, אילו עבודות בוצעו בסביבת העבודה. הוא זה שמאפשר להמשיך עם האתר בלי תדריך מצוות קודם.
מקרה בוחן: החזרנו את ההרשמה המקוונת לרשת מרפאות שיניים
מה היה לפני העבודות
רשת מרפאות שיניים קיבלה הרשמות בטלפון: מנהלים איחדו ידנית את לוח הזמנים של הרופאים, ובקשות מהאתר נשלחו כמייל לתיבה כללית. בשעות שיא — בוקר ואחרי העבודה — הקו לא עמד בזה: עד שליש מהפניות אבדו, חלק מהסלוטים עמדו ריקים בגלל ביטולים שהמרפאה גילתה בדיעבד.
מה שינו
האתר הועבר ל-1С-Битрикс וחובר למערכת החשבונאות של המרפאות: לוח הזמנים של הרופאים, החדרים ומשך התורים נמשכים לטופס ההרשמה בזמן אמת. המטופל בוחר סניף, מומחה וסלוט פנוי, אישור נשלח למייל ולמסנג'ר, והעברה או ביטול משחררים את הזמן מיד — אין יותר הזמנות כפולות.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הרשמות מאושרות | ~55% | 92% |
| אישור בקשה | עד 3 שעות | עד 5 דקות |
| הרשמות בשעות לא פעילות | אין | כשליש |
| פניות שאבדו בשיא | עד 30% | פחות מ-3% |
בשעות שיא טופס ההרשמה והיומן מחזיקים עומס הודות למטמון של לוח הזמנים ותור בקשות: בזינוק מבקרים התגובה נשארת יציבה, והבקשה לא אובדת. ביטולים והעברות מטופלים בזרם נפרד, לכן פעילות שיא לא חוסמת את יומן הרופא. אחרי ההשקה המנהלים הפסיקו להיות צוואר בקבוק — האישור עבר למצב אוטומטי.
מה לעשות אם האתר כבר קיים, אבל אין דרכו הרשמה?
כפתור "הירשם" באתר לעיתים כבר קיים, אבל זה רק טופס: הוא שולח מייל למנהל, והזמן הפנוי לא נבדק מול שום דבר. לוח הזמנים חי במערכת החשבונאות של המרפאה, והבקשות — במייל ובמסנג'רים. מכאן הזמנות כפולות לאותו זמן ופניות שאף אחד לא רואה עד הבוקר.
לחבר את ההרשמה ללוח הזמנים פירושו להפוך את לוח התורים הפעיל למקור אמת, ואת האתר לחלון ראווה של סלוטים פנויים. הסלוטים מחושבים מתפוסת הרופא, משך השירות והחדר, והזמן התפוס נסגר מיד לשאר המבקרים. הרשמה מאושרת חוזרת למערכת החשבונאות ומופיעה ביומן המנהל בלי הקלדה חוזרת.
אפשר להטמיע את זה באתר עובד בלי השקה מחדש מלאה. קודם מנתחים את המבנה הנוכחי: עמודי שירותים ורופאים, פריסה, כתובות, טפסים שכבר אוספים נתונים. מודול ההרשמה שמים כבלוק נפרד בעמודים הקיימים — ניווט, כתובות ופריטים שנצברו נשמרים, האתר עצמו נשאר אותו דבר.
העברת לוח הזמנים נעשית עם כללים שמתאימים לעבודה אמיתית של המרפאה: חוצץ לעיבוד סניטרי בין תורים, משך שונה לפי סוגי שירותים, מגבלות לרופא ולסניף מסוים, תרחישים נפרדים לביטול ולהעברה.
את החיבור בודקים בתקופת בדיקה, משווים נתונים בין האתר למערכת החשבונאות, ורק אחרי זה מעבירים את ההרשמה למצב עבודה.
שאלות טכניות לפני תחילת העבודות
ספקות טכניים עולים בדרך כלל בפגישה הראשונה — לפני דיון בעיצוב: איך ההרשמה תיכנס ללוח הזמנים של הרופאים, מה המטופל רואה בזמן עדכון, האם כל סניף צריך אתר נפרד, מי אחראי על הפרטים האישיים ומה יהיה אחרי מסירת הפרויקט. להלן תשובות קצרות, כדי להמשיך לדבר על לוחות זמנים והיקף עבודות.
ההרשמה המקוונת תתחבר ללוח הזמנים של הרופאים?
אם במרפאה כבר מנוהלת מערכת תורים, מגדירים חילופי נתונים: סלוטים פנויים נמשכים לטופס ההרשמה, וביקור מאושר חוזר ללוח הזמנים. בלי מערכת חשבונאית הבקשות נאספות בפאנל המנהל עם ייצוא לטבלה.
מה המטופל רואה בזמן שיוצא עדכון?
הבנייה מוכנה בנפרד ומועלית אחרי בדיקה בעותק של בסיס הנתונים. ברגע ההעלאה העמודים מוגשים מהגרסה המוכנה, לכן המבקר לא נתקל בשגיאות, והחזרה לבנייה הקודמת נמשכת דקות.
למרפאה יש כמה סניפים — כמה אתרים צריך?
בדרך כלל אחד: קטלוג שירותים משותף וטופס אחד, שבו המטופל בוחר סניף ורופא. לוחות הזמנים, הכתובות והטלפונים של הסניפים נפרדים, והתוכן מתעדכן במקום אחד. אתרים נפרדים מוצדקים רק כשההתמחות שונה.
איך מוגנים הפרטים האישיים של המטופלים?
נתונים מטופס ההרשמה מגנים עליהם כנתונים רפואיים: העברה בערוץ מאובטח, אחסון עם הפרדת גישות, יומן פעולות של מנהלים. עובד רואה רק את הפרטים שנדרשים לו להרשמה.
מי תומך באתר אחרי ההשקה?
מוסרים את הפרויקט עם תיעוד וגישות, אבל לרוב המרפאה נשארת בליווי: עדכוני פלטפורמה, גיבויים, בקרת זמינות ותיקוני תוכן הולכים לפי תקנון, והתגובה לתקלה — לפי רמת הקריטיות.
נדון במשימה: מה להכין לשיחה
לשיחה אין צורך להכין מצגת או לכתוב מחדש את המחירון — מספיקים נתוני פתיחה שכבר יש למנהל ולרופא הראשי. ככל שנתוני המקור מדויקים יותר, כך ההערכה ותוכנית העבודה מדויקות יותר: רואים את היקף קטלוג השירותים, מורכבות ההרשמה המקוונת ואילו אינטגרציות יהיה צריך לעשות. להלן רשימה של מה שכדאי להחזיק ליד.
- רשימת שירותים ותחומים: טיפול, השתלות, אורתודונטיה, קבלת ילדים — ממנה תלויים מבנה המדורים, המסננים ולוגיקת בחירת הרופא.
- נתונים על המומחים: התמחות, ניסיון, השכלה, תמונה, לוח זמנים — הבסיס לכרטיסים ולכללי חלוקת ההרשמות.
- איך הרשמות מתקבלות עכשיו: טלפון, שירות צד שלישי, יומן מנהל — כדי שבהעברה לא לאבד את זרימת המטופלים.
- לאן הבקשות צריכות להגיע: מערכת מידע רפואית, מערכת חשבונאית של המרפאה, מייל או מסנג'ר של המנהל.
- כללי ההרשמה המקוונת: צעד הסלוט, שיוך לרופא מסוים, מועד ביטול, הרשמה לתור ראשון וחוזר.
- חומרים לגלריה ולבלוקי אמון: תמונות של המרפאה והחדרים, רישיונות, ביקורות, מסמכים על הסמכה.
- מגבלות לוחות זמנים ומצב האתר הנוכחי: מה כבר נעשה, מה מעבירים, מה משאירים בצורה הקודמת.
תארו את המשימה בצורה נוחה — נחזור עם הערכה ותוכנית עבודה, נציע סדר הכנה להתחלה ונבהיר נתוני פתיחה שחסרים. ניתוח נתוני הפתיחה לפרויקט אורך שיחה אחת, ולא חודשים של התכתבות.