קופי איי-איי / Copy.ai

מה זה קופי איי-איי ולמה זה כבר לא כלי כתיבה?

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

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

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

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

הפיצ'רים המרכזיים של קופי איי-איי

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

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

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

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

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

כמה זה עולה?

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

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

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

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

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

קופי איי-איי מול הדרכים האחרות לייצר תוכן בכמות

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

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

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

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

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

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

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

הפיצ'ר שעושה את ההבדל: השער שמחליט מה בכלל יוצא

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

# שער יציאה לפניות שנוצרו בכמות: מה נשלח, מה נחסם ובאיזה קצב
import csv
import json
import re
from datetime import date

SUPPRESSION_FILE = "suppression.txt"   # מי שביקש להסיר, לתמיד ובלי יוצא מן הכלל
DAILY_CAP = 60                          # תקרה יומית לכתובת שליחה אחת
MIN_WORDS, MAX_WORDS = 45, 130

# שאריות תבנית שאסור שיישארו בטקסט שיוצא החוצה
TEMPLATE_LEFTOVERS = ("{{", "}}", "[שם החברה]", "TODO", "כאן ייכנס")
EMAIL_RE = re.compile(r"^[^@\s]+@[^@\s]+\.[a-z]{2,}$", re.I)


def load_suppression(path):
    try:
        lines = open(path, encoding="utf-8").read().splitlines()
    except FileNotFoundError:
        return set()
    return {line.strip().lower() for line in lines if line.strip()}


def has_legal_basis(row):
    # בישראל נדרשת הסכמה מוקדמת לדבר פרסומת. אין הסכמה, אין שליחה
    basis = (row.get("consent_basis") or "").strip().lower()
    if basis in ("explicit_optin", "existing_customer"):
        if row.get("consent_date"):
            return True
    return False


def body_problems(text):
    problems = []
    words = len(text.split())
    if words < MIN_WORDS:
        problems.append("short_body")
    if words > MAX_WORDS:
        problems.append("long_body")
    for marker in TEMPLATE_LEFTOVERS:
        if marker in text:
            problems.append("template_leftover")
            break
    if text.count("!") > 1:
        problems.append("too_many_exclamations")
    return problems


def review_row(row, suppression):
    email = (row.get("email") or "").strip().lower()
    if not EMAIL_RE.match(email):
        return ["bad_email"]
    if email in suppression:
        return ["suppressed"]
    if not has_legal_basis(row):
        return ["no_consent"]
    return body_problems(row.get("body") or "")


def run(rows_path, out_ready="ready-to-send.csv", out_blocked="blocked.json"):
    rows = json.load(open(rows_path, encoding="utf-8"))
    suppression = load_suppression(SUPPRESSION_FILE)
    ready, blocked, seen = [], [], set()

    for row in rows:
        email = (row.get("email") or "").strip().lower()
        if email in seen:
            blocked.append({"email": email, "reasons": ["duplicate_in_batch"]})
            continue
        seen.add(email)

        reasons = review_row(row, suppression)
        if reasons:
            blocked.append({"email": email, "reasons": reasons})
            continue
        ready.append(row)

    # התקרה היומית היא מה ששומר על מוניטין הדומיין. השאר ממתין למחר
    today, waiting = ready[:DAILY_CAP], ready[DAILY_CAP:]

    with open(out_ready, "w", encoding="utf-8-sig", newline="") as f:
        if today:
            writer = csv.DictWriter(f, fieldnames=sorted(today[0].keys()))
            writer.writeheader()
            writer.writerows(today)

    json.dump(blocked, open(out_blocked, "w", encoding="utf-8"),
              ensure_ascii=False, indent=2)

    return {"date": str(date.today()), "received": len(rows),
            "sending_today": len(today), "waiting": len(waiting),
            "blocked": len(blocked)}


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

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

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

חסרונות שאתם צריכים לדעת

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

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

היתרונות שעושים את קופי איי-איי שווה

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

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

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

מתי לבחור קופי איי-איי ומתי לוותר?

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

# עץ החלטה לייצור פניות מותאמות בכמות
שאלה 1: כמה פניות בחודש?
    עד 20                -->  ידנית, איכותי יותר ומהיר יותר
    50 עד 300            -->  תהליך אוטומטי מחזיר את עצמו מיד
    מעל 300              -->  תהליך, ולבדוק תשתית שליחה בנפרד

שאלה 2: מה מצב הרשימה?
    נקייה ומאומתת        -->  אפשר להריץ
    חלקית                -->  לנקות קודם, יום עבודה חוסך נזק
    נקנתה מבחוץ          -->  לעצור, זו בעיה משפטית ולא טכנית

שאלה 3: מה הבסיס לפנייה?
    הסכמה מפורשת        -->  מותר, ולתעד תאריך
    לקוח קיים            -->  לבדוק את גבולות ההיתר
    אין בסיס             -->  לא לשלוח, בשום נפח

שאלה 4: מי קורא לפני שיוצא?
    סקירה של מדגם        -->  מספיק מגודל מאה ומעלה
    סקירה של הכול        -->  נכון בחשבונות גדולים
    אף אחד               -->  לא להריץ, הנזק מהיר מהתועלת

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

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

השורה התחתונה: האם קופי איי-איי שווה?

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

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

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

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