מעבר מהצעות מחיר בוורד להצעות מהמערכת נותן מספור, מעקב, המשך אוטומטי לחשבונית ומחירון אחד. מה צריך להגדיר וכמה זמן זה לוקח.
עיקרי הדברים
- המספור הוא מה שהופך הצעה לישות שאפשר לעקוב אחריה.
- מחירון אחד במקום קובץ אישי מונע מחירים סותרים לאותו לקוח.
- המעבר להצעה לחשבונית בלי הקלדה מוחק את מקור הטעויות הנפוץ ביותר.
- ההגדרה הראשונית היא כמה שעות; ההחזר מתחיל בשבוע הראשון.
הצעה שנוצרת במערכת נבדלת מהצעה בוורד בארבעה דברים מדידים: יש לה מספר שמאפשר לעקוב, היא מבוססת על מחירון אחד, אפשר לדעת אם נפתחה, והיא הופכת לחשבונית בלי הקלדה מחדש. ההבדל אינו בעיצוב המסמך אלא במה שקורה אחריו.
מה נשבר בהצעות בוורד
- אין מספור, ולכן אי אפשר לשאול "מה קרה עם ההצעה מהשבוע שעבר" בלי לחפש בקבצים.
- המחיר מועתק מהצעה קודמת, ולכן הנחה שניתנה פעם אחת מתגלגלת לכולם.
- שתי גרסאות של אותה הצעה אצל שני אנשים, ואיש לא יודע מה נשלח.
- אין מעקב - לא ידוע אם הלקוח פתח בכלל.
- הקלדה מחדש בחשבונית, ושם נוצרות רוב הטעויות בסכומים.
- תנאי תשלום שמשתנים בין הצעה להצעה בלי החלטה.
הסעיף החמישי הוא היקר מכולם, כי טעות בחשבונית עולה זמן תיקון, מסמך זיכוי, ולעתים אמון של לקוח.
מה מקבלים כשההצעה יוצאת מהמערכת
| היכולת | מה היא נותנת בפועל |
|---|---|
| מספור אוטומטי | אפשר לעקוב, לחפש ולהתייחס להצעה במספרה |
| מחירון מרכזי | אותו מוצר באותו מחיר לכל הנציגים |
| תוקף להצעה | תזכורת אוטומטית לפני שהיא פגה |
| מעקב פתיחה | ידיעה אם הלקוח ראה, לפני שמתקשרים |
| המרה לחשבונית | אותם נתונים, בלי הקלדה |
| היסטוריה בכרטיס | כל ההצעות ללקוח במקום אחד |
השורה הרביעית משנה את שיחת המעקב עצמה: נציג שיודע שההצעה נפתחה שלוש פעמים מתקשר אחרת מנציג שמנחש.
מה צריך להגדיר לפני שמתחילים?
- מחירון - רשימת המוצרים או השירותים עם מחיר בסיס ויחידת מידה.
- מדיניות הנחות - מי רשאי לתת כמה, בלי לשאול.
- תנאי תשלום ברירת מחדל, ומתי חורגים מהם.
- תוקף ההצעה - כמה ימים, וזה שדה ולא משפט בטקסט.
- נוסח קבוע - מה נכתב בכל הצעה, כולל מה שאינו כלול.
- מי מאשר הצעה מעל סכום מסוים.
סעיף 2 הוא זה שחוסך הכי הרבה ויכוחים פנימיים, וכמעט אף פעם לא כתוב בשום מקום לפני שמגדירים אותו במערכת.
מה כדאי שיופיע בכל הצעה
מעבר למחיר, שלושה דברים משנים את שיעור הסגירה יותר מהעיצוב: מה בדיוק כלול ומה לא - פסקה קצרה שמונעת את רוב הוויכוחים בהמשך; לוח זמנים משוער עם תלות במה שהלקוח צריך לספק; ומה הצעד הבא - משפט אחד שאומר מה קורה כשמאשרים.
הסעיף השלישי נשמע טריוויאלי והוא הסעיף שהכי חסר: הצעות רבות מסתיימות במחיר ומשאירות ללקוח לנחש מה עושים עכשיו. משפט אחד - "לאישור, השיבו למייל הזה ונתאם התחלה בתוך שבוע" - מקצר את זמן הסגירה.
מה שכדאי להשמיט הוא הפוך: פסקאות כלליות על החברה, רשימות יכולות שאינן רלוונטיות לעבודה הזו, ותנאים משפטיים ארוכים בגוף ההצעה. ככל שהמסמך ארוך יותר, כך גדל הסיכוי שהלקוח יקרא רק את השורה התחתונה - ואז כל מה שכתבתם על ההיקף לא נקרא בכלל, וזה בדיוק מה שיצור מחלוקת בהמשך.
מה עם חתימה?
הצעה שמאושרת במייל היא אישור לגיטימי לרוב העסקאות, ועסקים רבים מסתדרים איתו שנים. חתימה אלקטרונית שווה כשהסכומים גדולים, כשיש תנאים מורכבים, או כשהלקוח הוא ארגון שדורש מסמך חתום לתיק שלו.
מה שכן חשוב בכל מקרה: שיהיה תיעוד ברור של מה אושר ומתי - כולל הגרסה המדויקת של ההצעה. הצעה שתוקנה אחרי האישור ולא נשמרה בגרסה נפרדת היא מקור לוויכוח שקשה להכריע.
איך זה מתחבר לשאר המערכות
ההצעה היא נקודת המפגש בין המכירה לכסף, ולכן היא המקום שבו החיבור בין המערכות משתלם ראשון. הזרימה שעובדת: ההצעה נוצרת ב-CRM עם נתוני הלקוח; באישור היא הופכת להזמנה או לחשבונית במערכת שמפיקה מסמכים; והסטטוס חוזר לכרטיס הלקוח. פירוט מלא של החיבור נמצא בחיבור תוכנת חשבוניות ל-CRM.
מה קורה אחרי ששולחים?
רוב העסקים משקיעים בהצעה עצמה ולא במה שאחריה, וזו טעות מדידה: הצעה טובה שאיש לא עוקב אחריה סוגרת פחות מהצעה בינונית עם מעקב מסודר. המעקב שעובד הוא פשוט: תזכורת אוטומטית אחרי מספר ימים קבוע, פנייה קצרה שמציעה עזרה במקום ללחוץ, ושיחה אחת נוספת לפני שההצעה פגה.
זה גם הרגע שבו שדה התוקף מוכיח את עצמו. תוקף אינו איום על הלקוח אלא סיבה לגיטימית לחזור אליו - "ההצעה פגה ביום ראשון, רציתי לוודא שלא נשכח" - וזו פנייה שקל לעשות וקשה להתעלם ממנה.
מה עושים כשההצעה נדחית או משתנה
הצעה שמשתנה צריכה גרסה חדשה, לא עריכה של הקיימת. הסיבה מעשית: כשלקוח שואל בעוד חודשיים "אבל הסכמנו על X", הדרך היחידה להשיב בביטחון היא להצביע על הגרסה המדויקת שנשלחה ומתי. מערכות שמנהלות גרסאות עושות את זה לבד; בוורד זה דורש משמעת שאיש לא שומר עליה.
כשהצעה נדחית, שווה לרשום מה בדיוק נדחה - המחיר, ההיקף, לוח הזמנים או התנאים. ההפרדה הזו משנה את ההצעה הבאה לאותו לקוח, ולעתים קרובות גם את ההצעות לכל השאר: שלוש דחיות ברצף על אותו סעיף הן מידע על ההצעה שלכם, לא על הלקוחות.
כמה זה חוסך בפועל
בעסק שמוציא כמה עשרות הצעות בחודש, החיסכון הישיר הוא זמן ההקלדה - גם בהצעה וגם בחשבונית שאחריה. החיסכון העקיף גדול יותר: פחות טעויות במחיר, פחות הצעות שנשכחות, ופחות שיחות פנימיות על "מה שלחנו ללקוח הזה".
יש גם רווח שקשה למדוד וקל להרגיש: כשהצעה יוצאת תוך שעה במקום למחרת, חלק מהלקוחות פשוט סוגרים לפני שהם מבקשים הצעה נוספת. מהירות התגובה היא לעתים קרובות ההבדל בין זכייה להפסד בעסקאות קטנות ובינוניות, והיא תלויה כמעט לגמרי בשאלה אם בניית ההצעה דורשת עבודה או לחיצה.
מקורות
שאלות נפוצות
אפשר לשמור על העיצוב שלנו?
ברוב המערכות כן - לוגו, צבעים ונוסח קבוע ניתנים להגדרה. מה שבדרך כלל לא ניתן הוא עיצוב חופשי לגמרי לכל הצעה, וזה בסדר: אחידות בהצעות היא יתרון, ולא ויתור.
מה עם הצעות מורכבות עם שלבים ואופציות?
זה תלוי במערכת, ולכן זו בדיוק הדוגמה שכדאי לבקש בהדגמה - עם ההצעה המורכבת ביותר שלכם. מערכת שמתקשה בזה תדחוף אתכם חזרה לוורד להצעות הגדולות, וזה מבטל חלק ניכר מהתועלת.
כמה זמן לוקח להגדיר?
בניית המחירון היא רוב העבודה, ובעסק עם עשרות פריטים מדובר בכמה שעות. ההגדרות האחרות - תוקף, תנאי תשלום, נוסח - הן עניין של שעה. מה שלוקח יותר זמן הוא ההחלטות, לא ההקלדה.
ומה עם מחירים שמשתנים ללקוח?
מחיר מיוחד ללקוח קבוע הוא צורך אמיתי, ורוב המערכות תומכות בו כמחירון ייעודי או כהנחה שמורה. מה שכדאי להימנע ממנו הוא הנחה ידנית שנרשמת בכל הצעה מחדש - זו הדרך שבה נוצרים מחירים סותרים לאותו לקוח.
להמשך קריאה
שירות רלוונטי
מערכת CRM בהתאמה אישית
CRM שנבנה סביב הפייפליין שלכם, מחובר לכלים שאתם כבר עובדים איתם.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.