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