סוכן AI למייל עסקי: למה מתחילים בטיוטות ולא בשליחה

# סוכן AI למייל עסקי: למה מתחילים בטיוטות ולא בשליחה החיבור הראשון של סוכן AI למייל לא צריך לאפשר לו לשלוח הודעות. הוא צריך לאפשר לו להכין טיוטות טובות, עם ההקשר הנכון, ולהניח אותן במקום שבו אדם יכול לבדוק ולאשר. זה נשמע זהיר מדי. הרי אם ממילא צריך לעבור על הטיוטה, מה בדיוק חסכנו? התשובה נמצאת בעבודה שלפני הלחיצה על "שליחה": קריאת השרשור, איתור פרטי הלקוח, חיפוש מסמך, בדיקת התחייבויות קודמות, ניסוח תשובה ותיעוד הפעולה. ברוב המקרים, הלחיצה עצמה היא החלק הקצר. לכן הדרך הנכונה לחבר סוכן AI למייל עסקי היא לבנות מסלול טיוטות לפני מסלול שליחה. הסוכן קורא רק את התיבות והשרשורים שנחוצים לתפקיד, אוסף הקשר ממקורות מאושרים, מכין תשובה ומציג לאדם גם את המקורות שעליהם הסתמך. שליחה אוטומטית מגיעה מאוחר יותר, ורק לסוגי הודעות שהעסק כבר למד למדוד. ## שליחה היא הרשאה קטנה עם השלכות גדולות מבחינה טכנית, יצירת טיוטה ושליחת הודעה נראות כמו שתי פעולות סמוכות. מבחינה עסקית יש ביניהן תהום. טיוטה שגויה עדיין נמצאת בתוך העסק. אפשר לתקן שם, למחוק אותה או להבין שחסר מידע. הודעה שגויה כבר הגיעה ללקוח, לספק או לעובד. היא יכולה לקבוע מחיר לא נכון, להתחייב למועד שאין אפשרות לעמוד בו, לצרף מסמך של לקוח אחר או פשוט לייצר שיחה מביכה שאי אפשר להחזיר לתיבה. גם ממשקי המייל עצמם מתייחסים לטיוטה ולשליחה כפעולות נפרדות. ב־Gmail API אפשר ליצור הודעת טיוטה ורק לאחר מכן לשלוח אותה. ב־Microsoft Graph אפשר ליצור הודעה כטיוטה, לעדכן אותה, ואז לבצע פעולת שליחה נפרדת. ההפרדה הזאת אינה רק פרט של מפתחים. היא מאפשרת לעסק להציב אישור אנושי בדיוק בין הכנת התשובה לבין הפעולה החיצונית. מכאן נגזר כלל פשוט: בגרסה הראשונה, הסוכן מקבל יכולת לנסח. האדם שומר את סמכות השליחה. ## מה הסוכן צריך להכין מלבד נוסח יפה טיוטה שימושית אינה פסקה מנומסת שנכתבה לפי ההודעה האחרונה. מייל עסקי חי בתוך שרשור, והשרשור חי בתוך מערכת יחסים. נניח שספק מבקש אישור להזיז אספקה מיום רביעי ליום חמישי. תשובה של "אין בעיה, תודה על העדכון" עשויה להישמע מצוין. היא עדיין עלולה להיות טעות אם ההתקנה אצל הלקוח נקבעה לחמישי בבוקר. לפני ניסוח התשובה צריך לקרוא את השרשור, לבדוק את ההזמנה, לראות את מועד ההתקנה ולזהות שהשינוי דורש החלטה של מנהל תפעול. לכן כל טיוטה צריכה להגיע עם מעטפת בדיקה קצרה: * מה מבקש השולח, במשפט אחד * אילו פרטים נמצאו בשרשור ובמערכות המאושרות * מה חסר או סותר מידע אחר * מי צריך לאשר את התשובה * על אילו מקורות נשען הנוסח המעטפת חשובה יותר מעוד ליטוש סגנוני. היא מאפשרת למאשר להבין למה הסוכן כתב את מה שכתב, בלי לפתוח ארבע מערכות ולשחזר את החיפוש בעצמו. ## ארבעה מסלולים שונים בתוך אותה תיבה אחת הטעויות הנפוצות היא להגדיר "טיפול במייל" כמשימה אחת. תיבת דואר עסקית מכילה פעולות עם רמות סיכון שונות, ולכן צריך לחלק אותה למסלולים. המסלול הראשון הוא מיון בלבד. הסוכן מזהה סוג פנייה, לקוח, דחיפות ובעל תפקיד, מוסיף תווית או מעביר לתור. הוא לא מנסח ולא שולח. במסלול השני הסוכן מכין תקציר ומשימה. למשל, בקשת ביטול מגיעה לשירות, והסוכן מרכז את מספר ההזמנה, מועד הרכישה והסיבה שנכתבה. אדם מחליט מה לעשות. המסלול השלישי הוא טיוטה לאישור. כאן כבר יש תשובה מוצעת, אך היא נשארת בתיבה עד שאדם מאשר אותה. זה המקום הנכון להתחיל עם שאלות שירות, תיאום מול ספקים ומענה פנימי שחוזר על עצמו אך עדיין דורש הקשר. המסלול הרביעי הוא שליחה אוטומטית. הוא מתאים רק להודעות שהן צפויות, הפיכות מבחינה תפעולית ואינן יוצרות התחייבות חדשה. אישור קבלת מסמך יכול להתאים. שינוי מחיר, תשובה משפטית או התחייבות למועד אינם מועמדים טובים. אותה תיבה יכולה להשתמש בכל ארבעת המסלולים. ההחלטה מתקבלת לפי סוג ההודעה, לא לפי ההתלהבות מהמערכת. ## תיבת טיוטות טובה צריכה להראות גם מתי לא לענות סוכן שמודד את עצמו לפי מספר הטיוטות יכתוב יותר מדי. הוא יכין תשובות גם כשהפנייה כפולה, כשהלקוח כבר קיבל מענה בערוץ אחר או כשהשרשור מחכה בכלל למסמך פנימי. היכולת החשובה היא זיהוי מצב שבו לא נכון לנסח עדיין. למשל: * חסר מספר הזמנה ואי אפשר לזהות את העסקה * יש שתי גרסאות שונות למחיר או למועד * ההודעה כוללת נושא רגיש שלא הוגדר במסלול * אדם אחר כבר מטפל בשרשור * הקובץ המצורף אינו ניתן לקריאה או נראה שייך ללקוח אחר במקרים כאלה הסוכן צריך לסמן את החוסר, להפנות לבעל התפקיד ולהימנע מטיוטה שנראית שלמה. טקסט בטוח בעצמו הוא לא תחליף למידע. ## כך נראה פיילוט שאפשר ללמוד ממנו מתחילים בתיבה אחת ובסוג הודעה אחד. לא מחברים ביום הראשון את כל המייל של החברה, ולא נותנים לסוכן לחפש בכל תיקייה ארגונית "ליתר ביטחון". אפשר לבחור, למשל, בקשות תיאום מספקים. אוספים כמה עשרות שרשורים קודמים, מוחקים מידע שאינו נחוץ לבדיקה ומסמנים לכל שרשור מה הייתה התוצאה הנכונה: תשובה, שאלה משלימה, העברה למנהל או המתנה. לאחר מכן מגדירים את מקורות ההקשר. ייתכן שהסוכן צריך לקרוא את השרשור ואת שורת ההזמנה ב־CRM. הוא כנראה לא צריך גישה לתיבת השכר, לחוזים של כל הלקוחות או לכל הקבצים בדרייב. הרשאה רחבה אינה הופכת את הטיוטה לחכמה יותר. היא רק מגדילה את שטח הטעות. בשלב ההרצה הסוכן מכין טיוטות בלי לשלוח. המאשר מסמן לכל טיוטה אחת מארבע תוצאות: אושרה בלי שינוי, אושרה אחרי תיקון, הוחזרה בגלל מידע חסר או נפסלה כי לא היה צריך לענות. רצוי לשמור גם את סיבת התיקון. "לא טוב" אינו חומר ללמידה. "המועד נלקח מהמייל ולא מהיומן התפעולי" כבר אומר מה צריך לתקן. ## המדד אינו כמה מהר נכתבה הטיוטה זמן הכנה הוא מדד נוח, אבל הוא לא השאלה המרכזית. אם הסוכן מכין טיוטה בתוך שניות והאדם צריך לחקור אותה במשך חמש דקות, לא נוצר קיצור אמיתי. כדאי למדוד את זמן האישור הכולל: מהרגע שהטיוטה מוכנה ועד שהמאשר יכול לשלוח או לקבל החלטה אחרת. לצד הזמן בודקים כמה טיוטות אושרו ללא שינוי מהותי, אילו סוגי תיקונים חזרו, כמה פעמים הסוכן עצר בצדק וכמה פעמים פספס סיבה לעצור. יש גם מדד פחות אלגנטי, אבל שימושי מאוד: כמה פעמים המאשר פתח מערכת נוספת כי לא סמך על ההקשר שהוצג לו. אם זה קורה שוב ושוב, הבעיה אינה בהכרח בניסוח. ייתכן שחסר מקור, שהמקור אינו עדכני או שהמעטפת אינה מסבירה מאיפה הגיע כל פרט. רק אחרי שהעסק רואה דפוס יציב בסוג הודעה מסוים, אפשר לשקול שליחה אוטומטית. גם אז מתחילים בנתיב צר, עם תיעוד ודרך ברורה לעצור אותו. ## ומה עם החיסכון אם אדם עדיין מאשר? זו ההתנגדות הרצינית, והיא מוצדקת. אם המאשר קורא מחדש את כל השרשור, מחפש את ההזמנה ומנסח חצי מהמייל, קיבלנו עוד מסך בדרך ולא אוטומציה. הפיילוט צריך להוכיח שהאישור נעשה קצר יותר משום שעבודת ההכנה כבר בוצעה והוצגה בצורה שאפשר לבדוק. אם אין קיצור, לא משחררים שליחה. מתקנים את איסוף ההקשר, מצמצמים את סוגי הפניות או מודים שהתהליך אינו מתאים כרגע. מצד שני, אישור אנושי אינו כישלון זמני שחייבים להעלים. יש הודעות שבהן הוא יהיה המודל הקבוע: הצעת מחיר חריגה, שינוי חוזי, תלונה רגישה או התחייבות לספק. הסוכן יכול לחסוך את עבודת ההכנה ולהשאיר לאדם את ההחלטה. חלוקת עבודה כזאת הגיונית גם כשהיא אינה אוטונומית לחלוטין. ## ההחלטה הראשונה היא איזה מייל לא יישלח לבד לפני שבוחרים מודל, חיבור או ניסוח, פותחים את התיבה ומסמנים גבול. אילו הודעות לעולם אינן נשלחות בלי אישור? אילו מקורות רשאים לקבוע מחיר ומועד? מי מאשר כשיש סתירה? ומה הסוכן עושה כשהוא לא מצליח לזהות לקוח בוודאות? אחרי שהגבול כתוב, אפשר לבנות מסלול טיוטות צר ולמדוד אותו. זאת התחלה פחות מרשימה מהדגמה שבה המיילים עפים לבד. היא גם הרבה יותר קרובה לעסק שאפשר להפעיל ביום שני בבוקר. אם אתם רוצים לבחון חיבור של סוכן AI למייל, בחרו סוג הודעה אחד והביאו עשרה שרשורים מייצגים לפגישת [גילוי אוטומציה](https://aibuddy.co.il/automation-discovery). ב־AI BUDDY נמפה אילו מקורות נדרשים לטיוטה, מי צריך לאשר אותה ומה ייחשב סיבה טובה לא לנסח בכלל. ### מקורות * [Gmail API: יצירה וניהול של טיוטות](https://developers.google.com/workspace/gmail/api/guides/drafts) * [Gmail API: היקפי הרשאה](https://developers.google.com/workspace/gmail/api/auth/scopes) * [Microsoft Graph: יצירת הודעת טיוטה](https://learn.microsoft.com/en-us/graph/api/user-post-messages?view=graph-rest-1.0) * [Microsoft Graph: שליחת הודעת טיוטה](https://learn.microsoft.com/en-us/graph/api/message-send?view=graph-rest-1.0)