מודל ההפעלה של סוכנות שעובדת עם סוכני AI: מי עושה מה, ומתי

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

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

איזה תפקידים צריך בסוכנות כזו?

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

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

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

איך מארגנים את הלקוחות בתוך המערכת

נקודת המוצא היא סביבת עבודה נפרדת לכל לקוח. בְּשַׁגֵּר זה workspace, והסוכן יכול לראות את כולן עם list_workspaces ולפתוח חדשה עם create_workspace. לכל סביבה יש אזור זמן משלה, וברירת המחדל היא ישראל. אפשר גם לקבוע כבר ביצירה שהסביבה דורשת אישור לקוח לפני תזמון.

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

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

שבוע עבודה טיפוסי

הנה שבוע ישראלי, ראשון עד חמישי, כפי שאני ממליץ לבנות אותו:

1. ראשון בבוקר: תכנון. מנהלי הלקוחות ועורכי התוכן מחליטים מה יוצא השבוע לכל לקוח. התוצר הוא בריף קצר לכל קמפיין: מסר, נכסים, קישור יעד, קבוצות חשבונות, תאריכים.
2. ראשון אחר הצהריים: הסוכן מכין. לפי הבריפים, הסוכן מעלה מדיה, כותב וריאציות לכל חשבון ויוצר טיוטות. בסוף היום יש רשימת טיוטות לכל לקוח.
3. שני: בדיקה פנימית. העורך עובר על דגימה מכל קמפיין, לא על כל וריאציה. אם יש בעיה בדפוס, מתקנים את הפרומפט ומריצים שוב, לא מתקנים ידנית שלושים פוסטים.
4. שני אחר הצהריים: אישור לקוח. הסוכן שולח קישור אישור לכל לקוח עם request_approval. הלקוח מאשר בלי להתחבר לשום מערכת. את הקישור אפשר לשלוח במייל או בוואטסאפ.
5. שלישי ורביעי: תזמון ופרסום. מה שאושר מתוזמן עם schedule_post. הפרסום מתפזר אוטומטית בין חשבונות של אותה רשת.
6. כל בוקר: בדיקת מצב. הסוכן מריץ list_posts עם סינון לפי סטטוס FAILED או PARTIALLY_PUBLISHED ומדווח למפעיל מה נכשל ולמה.
7. חמישי: דוח. הסוכן מושך לחיצות לכל חשבון ולכל פוסט עם get_analytics ומכין טיוטת דוח שבועי. מנהל הלקוח מוסיף פרשנות ושולח.

את הדוח השבועי בניתי כתהליך מלא במדריך לדוח לקוח שבועי שסוכן מכין.

מפתחות, הרשאות ואחריות

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

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

פירטתי את נושא המפתחות לעומק במאמר על מפתחות, הרשאות ויומן ביקורת.

איך עובדים עם הלקוח במודל הזה

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

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

חיבור חשבונות. במקום לבקש סיסמאות או להוסיף את הסוכנות כמנהלת בכל עמוד, שולחים ללקוח קישור חיבור. הלקוח מחבר את פייסבוק, אינסטגרם או יוטיוב שלו בעצמו, בלי לפתוח חשבון בְּשַׁגֵּר ובלי למסור סיסמה. הסוכן יכול ליצור את הקישור עם create_connect_link, אחרי שאדם תבע את הסביבה.

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

תהליך האישור עצמו מתואר במדריך לתהליך אישור לקוח בסוכנויות.

מה מודדים כדי לדעת שזה עובד

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

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

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

כמה זה עולה ואיך זה מתמחר

בְּשַׁגֵּר, גישת API, שרת MCP ומספר בלתי מוגבל של משתמשים כלולים בכל המסלולים. ההבדל בין המסלולים הוא מספר החשבונות. סוכנות עם עשרים לקוחות ושלושה חשבונות לכל אחד נכנסת למסלול Agency, שכולל 60 חשבונות. סוכנות עם כמה מאות חשבונות צריכה מסלול גבוה יותר. כל הפרטים בעמוד המחירים.

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

שאלות נפוצות

האם סוכנות קטנה צריכה מפעיל סוכנים במשרה מלאה?

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

האם כל לקוח צריך סביבת עבודה נפרדת?

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

מה קורה כשהלקוח לא מאשר בזמן?

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

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