מוווטסאפ למערכת הזמנות מסודרת

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

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

איך תהליך ההזמנה עבד בפועל

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

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

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

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

טעויות הופכות לחלק מהתהליך

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

כל הזמנה מטופלת בנפרד

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

אותו המידע מוזן מחדש במערכות אחרות

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

אותה תצוגה משמשת צרכים שונים

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

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

גמישות בשליטת המשתמשת

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

שימוש חוזר בהגדרות קיימות

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

המידע ממשיך לעבוד אחרי ההזמנה

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

התצוגה נקבעת לפי המשימה

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

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

כל מוצר מגדיר את המידע שהוא צריך

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

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

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

רמות מחיר שנבנות אחת על השנייה

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

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

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

הגדרות משותפות בין מוצרים

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

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

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

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

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

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

פחות טעויות בהזמנות

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

פחות עבודה כפולה

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

פחות עבודה אדמיניסטרטיבית

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

יותר שליטה בתהליך

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

הובלתי את הפרויקט מקצה לקצה: מהתצפית הראשונית ומיפוי ה-Workflow, דרך הגדרת הבעיה, הדרישות והעקרונות המוצריים, ועד לתכנון ה-UX/UI, מבנה המידע, פיתוח ה-Frontend וה-Backend והאינטגרציה עם Morning. אחד האתגרים המשמעותיים היה לתכנן מערכת שתומכת במוצרים דינמיים מאוד, עם סוגי שדות, רמות מחיר, אפשרויות וקטגוריות שמשתנים ממוצר למוצר. למדתי עד כמה חשובה כאן הגמישות, אבל גם שהמורכבות הזו צריכה להישאר מאחורי הממשק. מבחינת אילה, הפעולות צריכות להישאר פשוטות: להגדיר מוצר, לבחור איזה מידע נדרש ולנהל את ההזמנות בלי לחשוב על המבנה שמאפשר את זה מאחורי הקלעים. הפרויקט גם המחיש לי שעסק קטן ומערכת עם משתמשת אחת עדיין יכולים לדרוש חשיבה מוצרית ומערכתית עמוקה. גמישות במוצרים, הרשאות, שמירה על מידע, תרחישי קצה והיכולת להמשיך לפתח את המערכת לאורך זמן דורשים תכנון מראש, גם כשהמוצר עצמו צריך להרגיש פשוט מאוד למשתמשת. בסופו של דבר, תהליך שהתבסס על הודעות ווטסאפ, זיכרון והעברה ידנית של מידע - מתנהל היום מתוך מקור מידע אחד שמלווה את ההזמנה משלב איסוף הפרטים ועד להכנה, התשלום והקבלה.