מעבר מערכת תורים: איך עוברים בלי לאבד נתונים?

10 דקות קריאה

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

בקצרה

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

איך מתחילים מעבר מערכת תורים בלי לסכן את המידע?

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

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

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

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

אילו נתונים מגבים, ומה בודקים בקובצי הייצוא?

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

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

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

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

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

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

איך מתאימים את הנתונים למערכת החדשה?

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

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

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

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

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

דוגמה: מחיר אישי לעומת מחיר של ביקור קודם

נניח, לדוגמה, שמחיר שירות היום הוא 180 ש״ח, ללקוחות מסוימים הובטח מחיר של 160 ש״ח, וביקור ישן עלה 150 ש״ח. אלה שלושה נתונים שונים. בבדיקה מוודאים שהמחירון החדש לא דורס את המחיר האישי, ושמחירי ביקורים קודמים אינם מתעדכנים בדיעבד.

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

איך מנהלים את יום המעבר בלי תורים והודעות כפולים?

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

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

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

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

  • 1. קובעים שעת מעבר ומערכת קובעת לכל שלב.
  • 2. משלימים את השינויים שנעשו מאז הייצוא.
  • 3. בודקים סנכרון יומנים וחסימות זמינות.
  • 4. מוודאים מאיזו מערכת נשלחות הודעות לכל תור.
  • 5. מחליפים קישורים ובודקים הזמנה דרך הקישור החדש.

איך בודקים שהמידע עבר נכון?

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

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

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

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

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

מה עושים כשמגלים רשומה חסרה או שעה שגויה?

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

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

איך מגנים על המידע ומה מודיעים ללקוחות?

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

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

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

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

נוסח לדוגמה להודעת מעבר

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

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

מה כדאי לבדוק כשעוברים ל-Li-Tor?

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

לקוחות מזמינים דרך קישור אישי במבנה /your-business, בוחרים שירות, תאריך ושעה, והבקשה ממתינה לאישור העסק. אימות הטלפון נעשה בקוד שנשלח ב-WhatsApp. קיימות הודעות WhatsApp אוטומטיות על הזמנה, אישור וביטול, תזכורות לפני תורים ותזכורות להזמנה חוזרת, עם תבניות שניתן לערוך. בזמן המעבר בודקים שהנוסחים מתאימים לעסק ושאותו תור אינו מקבל הודעות משתי מערכות.

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

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

  • תקופת הניסיון היא 30 יום ללא תשלום, ואפשר לנצל אותה לבדיקת תהליך העבודה לפני החלפת הקישור.
  • בתכנון עלות המעבר אפשר לבחור בין תשלום חודשי של 119 ש״ח ללא התחייבות לבין מסלול שנתי בעלות 1,188 ש״ח, המקבילה ל-99 ש״ח בחודש. לשני המחירים יש להוסיף מע״מ.
  • לקראת השימוש במערכת החדשה אפשר להתאים את מראה האפליקציה לשם העסק ולצבעיו, לבחור מתוך שמונה פלטות צבעים ולהתקין אותה במסך הבית בטלפון.

מתי אפשר לסגור את המערכת הישנה?

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

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

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

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

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

שאלות נפוצות

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

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

האם לקוחות צריכים להזמין מחדש תורים קיימים אחרי מעבר מערכת תורים?

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

איך מונעים תזכורות כפולות משתי מערכות תורים?

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

כמה עולה להעביר נתונים ל-Li-Tor?

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

מה עושים עם מקדמות שנגבו במערכת הקודמת?

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

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

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

עוד מדריכים בנושא מערכת ניהול תורים