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

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

מתחילים מהתוצאה שהעסק צריך

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

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

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

שלוש שכבות של עלות

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

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

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

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

שלושה היקפים שונים לדוגמה

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

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

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

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

איך משווים שתי הצעות בצורה הוגנת

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

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

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

מה צריכה לכלול בדיקת קבלה

דוגמה: שתי הצעות שנראות דומות בכותרת

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

מפרידים תכולה, הנחות ותלויות

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

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

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

מגדירים מה ייחשב שינוי תכולה

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

עלויות שימוש שצריך להפריד ממחיר הפיתוח

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

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

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

תנאי קבלה לפני מסירה

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

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

איך להשוות הצעות בלי לאבד את ההבדלים

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

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

שאלות נפוצות

האם אפשר להתחיל בהיקף קטן ולהרחיב?

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

האם תחזוקה נדרשת גם כשהסוכן כבר עובד?

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

מה לשלוח כדי לקבל הצעת פיתוח?

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