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