בשיח המקצועי מתחיל להופיע מונח חדש בשם AAIO (ראשי תיבות של Agentic AI Optimization).
המונח מתאר התאמה של אתרים ומערכות לעבודה מול סוכני AI שפועלים בשם המשתמשים: מחפשים, משווים, בודקים ולעיתים גם מבצעים פעולות בפועל.
שנה שעברה פורסם מחקר של Luciano Floridi ועמיתיו שממסגר את AAIO כפרדיגמה חדשה, בדומה לאופן שבו SEO עיצב את האופן שבו אתרים נבנים עבור מנועי חיפוש.
המדריך הבא לא מנסה להגדיר את AAIO מחדש, אלא להתמקד ביוזקייס מאוד מסוים בתוכו: מה קורה כשהפעולה שהסוכן צריך לבצע היא קנייה ואיך חנות איקומרס צריכה להיות בנויה כדי לאפשר לסוכן להשלים רכישה מתוך הצ׳אט?
אז בואו ניזכר רגע בתהליך האיקומרס הקלאסי: עד היום היינו עושים SEO לחנות הוירטואלית כדי להביא טראפיק של קונים מגוגל, ואז הגולשים נכנסים לאתר וקונים.
בעידן ה-Agentic Commerce הסיפור מתפצל ל-2 שלבים שונים:
- איך להיכנס לשיחה: איך לגרום לזה שהמותג והמוצרים שלכם יופיעו בתוך התשובה של מודל ה-AI אחרי שהמשתמשים תיארו צורך.
- איך למכור מתוך השיחה: איך לאפשר לסוכן לבצע את הרכישה בפועל בתוך הצ׳אט, בלי לשלוח את המשתמש לאתר שלכם.
המדריך הבא עוסק בשלב השני, איך למכור בתוך השיחה.
על השלב הראשון אני לא נכנס כאן לעומק, אבל אם אתם רוצים להבין איך מגדילים סיכוי להופיע בתוך תשובות AI, כתבתי בעבר מדריך מקיף על GEO שעוסק בדיוק בשלב הראשון.
רק כדי לתת כיוון, הדברים שבדרך כלל משפיעים על שלב ״איך להיכנס לשיחה״:
- עד כמה האתר והתוכן שלכם בנויים בצורה שה-AI מצליח להבין.
- עד כמה אתם נתפסים כמקור אמין גם מחוץ לאתר שלכם.
- ספציפית לאיקומרס: עד כמה הנתונים שלכם עקביים וברורים (מפרטים, מדיניות משלוחים והחזרות, זמינות).
- עד כמה יש לכם נוכחות חיצונית שמחזקת אמון (ביקורות, השוואות, אזכורים).
נקודה חשובה לפני שממשיכים: למה בכלל לקרוא לשלב השני ״אופטימיזציה״ אם אין כאן קידום או דירוגים כמו שאנחנו מכירים מ-SEO ו-GEO?
הסיבה היא שברגע שחנות מחוברת לעולם האג’נטי ויש כמה מוצרים, כמה חנויות, וכמה סוכנים, מתחיל משחק של העדפה. לדוגמה:
- איזה מוצרים אתה בכלל מאפשר ל-enable_checkout?
- איך אתה מנסח תיאורים כך שסוכן יבין יתרון אמיתי?
- איזה שדות אתה ממלא ואיזה לא?
- כל כמה זמן אתה מעדכן מלאי ומחיר?
- איך אתה מטפל בהחזרות, זמני משלוח, חריגים?
- האם הנתונים עקביים בין האתר, הפיד והמערכות החיצוניות?
זו לא אופטימיזציה למיקומים כמו שאנחנו מכירים, אלא אופטימיזציה לקבלת החלטות של סוכן AI ומכאן בדיוק מגיע השם (הדמיוני) ACO 🙂
אגב, אני בשום אופן לא ממליץ להפסיק לעשות SEO לחנות הוירטואלית שלכם. מדובר באפיק חדש שמתפתח עכשיו, ולא ברור איזה נתח שוק הוא יתפוס מהמכירות. בקיצור, לא נוגעים במה שעובד.
מה זה Agentic Commerce?
כדי להבין איך מסחר אג׳נטי עובד, צריך רגע לשכוח איך התרגלנו לקנות אונליין בעשור האחרון.
כפי שכתבתי בהתחלה, עד היום תהליך ההמרה בחנות מהחיפוש האורגניים נראה ככה: משתמש מחפש משהו בגוגל, נכנס לאתר, משווה, קורא ביקורות, ולבסוף מחליט אם לקנות. כל עולם האיקומרס, ה-SEO וה-CRO נבנו סביב הרעיון הזה: איך להביא בן אדם לאתר, ואיך לגרום לו להמיר.
לעומת זאת, בעולם ה-Agentic Commerce מי שמבצע את תהליך החיפוש, ההשוואה והבחירה הוא לא המשתמש עצמו, אלא סוכן AI. המשתמש רק מתאר את הצורך.
תקראו רגע את המשפט הקודם שוב כי זהו הבסיס לכל התחום הזה.
דמיינו שהמשתמש כותב בצ׳ט את הצורך הבא: “אני מחפש נעלי ריצה טובות למרחקים ארוכים, לא יקרות מדי, עם אפשרות החזרה ומשלוח מהיר”. זהו, מכאן והלאה הוא יוצא מהתמונה.
הסוכן מנתח את הבקשה, משווה בין מוצרים, קורא ביקורות, בודק זמינות, מדיניות החזרות, מחירים, ולפעמים גם משלים את הרכישה בעצמו, הכל מתוך ממשק השיחה. בלי לעבור דרך האתר שלכם בכלל.
זו נקודה קריטית: המשתמש כבר לא “גולש” בחנות. הוא מנהל שיחה, וה-AI הוא זה שמקבל את ההחלטות בפועל. וכאן בדיוק נוצרת ההזדמנות.
ברגע שה-AI הוא הקונה, כל מה שהכרנו סביב חוויית משתמש, עמודי קטגוריה, עמודי מוצר וטראפיק, מפסיק להיות המרכז. ומה שכן מקבל פוקוס זה איך החנות שלכם “מדברת” עם סוכני AI בצורה מובנית, כדי שהרכישה תוכל לקרות בתוך הצ׳אט.
כדי לאפשר את זה, נכנסים לתמונה שני פרוטוקולים מרכזיים: אחד של OpenAI ואחד של גוגל.
הם מגדירים איך חנויות מעבירות נתונים מסחריים בצורה שהסוכן יכול לצרוך, ואיך נראית זרימת רכישה מאובטחת מתוך השיחה.
פרוטוקול ACP של OpenAI: איך קנייה מתבצעת בפועל בתוך ChatGPT
כדי ש-Agentic Commerce באמת יעבוד, צריך תשתית טכנולוגית שמחברת בין סוכני AI לבין חנויות איקומרס אמיתיות וכאן נכנס לתמונה ACP (ראשי תיבות Agentic Commerce Protocol).
בפשטות, זה הפרוטוקול שמאפשר ל-ChatGPT לא רק להמליץ על מוצרים, אלא גם לבצע רכישה בפועל בצורה מסודרת, מאובטחת, ובלי לזרוק את המשתמש לאתר חיצוני.
ה-ACP פותח בשיתוף פעולה עם חברת התשלומים Stripe, והוא בנוי כך שהסוחר נשאר בשליטה מלאה: על המחיר, על המלאי, על תנאי המשלוח, על ההחזרים ועל שירות הלקוחות. OpenAI לא הופכת לסוחר, אלא רק למתווך שמאפשר לסוכן לבצע פעולה.
חשוב להבין שה-ACP הוא לא מוצר ולא פיצ׳ר אלא סט של מפרטים טכניים פתוחים, תחת רישיון Apache 2.0, שכל חנות יכולה ליישם כדי לאפשר לסוכני AI לקנות אצלה.

שלושת החלקים שמרכיבים המסחר האג’נטי ב-ACP
ה-ACP בנוי משלושה חלקים, כאשר כל אחד מהם מטפל בשלב אחר בתהליך הקנייה.
1. גילוי מוצרים: פיד המידע שה-AI מסתמך עליו
מפרט פיד המוצרים (Product Feed Spec) הוא התשתית של כל תהליך הגילוי בתוך ChatGPT. זה המקום שבו החנות שלכם ״מציגה את עצמה״ לסוכן ה-AI.
הפיד האג’נטי דורש רמת פירוט גבוהה במיוחד, ועדכניות כמעט בזמן אמת. OpenAI מצפה לעדכונים בערך כל 15 דקות.
הסיבה פשוטה: אם סוכן AI ימליץ על מוצר שאזל ממנו המלאי או יציג מחיר לא עדכני, האמינות שלו מול המשתמש נפגעת, וזה קו אדום מבחינת OpenAI. אם נעשה אנלוגיה לעולם ה-SEO, זה כמו שנכתוב במטא טייטל שרואים בתוצאות החיפוש ״משלוח חינם״ ואז כשמשתמשים נכנסים לאתר ומגלים שהמשלוח לא חינם הם ישר יוצאים החוצה (הבאונס רייט הגבוה מאותת לגוגל שיש בעיה עם תוצאת החיפוש).
מעבר לשדות הבסיסיים, הפיד כולל שני דגלים קריטיים (Flags), שלא קיימים בפידים מסורתיים:
- enable_search: קובע אם המוצר רשאי להופיע בתוצאות בתוך ChatGPT.
- enable_checkout: קובע אם ניתן לרכוש את המוצר ישירות בתוך ממשק השיחה.
אם enable_checkout מוגדר כ־true, חייב להיות גם enable_search במצב true, אין אפשרות לעקוף את זה.
בנוסף, הפיד כולל שדות ייחודיים כמו:
- popularity_score: ציון פופולריות
- return_rate: שיעור החזרות
השדות האלו מאפשרים לסוכן ה-AI לנמק לעצמו וגם למשתמש למה מוצר מסוים עדיף על אחרים. לא רק מה המוצר עושה, אלא איך הוא מתפקד בפועל בעולם האמיתי.
2. זרימת הקנייה: צ’ק אאוט בלי לצאת מהשיחה
ברגע שהמשתמש מחליט לקנות, נכנס לפעולה מפרט הצ’ק אאוט האג’נטי (Agentic Checkout Spec).
בשלב הזה ChatGPT יוצר Checkout Session מול השרת של הסוחר (אתם), כלומר המערכת שלכם היא זו ששולטת בתהליך.
המערכת של החנות מחשבת מיסים, עלויות משלוח וזמינות מלאי סופית, ומחזירה ל-ChatGPT מצב עגלה (Authoritative Cart State), זה בדיוק המידע שמוצג למשתמש בתוך הצ’אט.
כדי שזה יעבוד, הפרוטוקול מחייב את הסוחר להטמיע חמש נקודות קצה מרכזיות באמצעות REST API:
- פתיחת סשן: POST /checkout_sessions
- עדכון פרטים כמו כתובת או קופון: POST /checkout_sessions/{id}
- אישור הרכישה וסיום ההזמנה: POST /checkout_sessions/{id}/complete
- שליפת מצב הסשן: GET /checkout_sessions/{id}
- ביטול עסקה במקרה של חרטה: POST /checkout_sessions/{id}/cancel
כפי שאפשר לראות, הצ’ק אאוט כולו מתרחש בתוך שיחה.
3. תשלום מאובטח: סליקה בלי חשיפת כרטיס אשראי
השלב האחרון הוא התשלום, וכאן נכנס לפעולה האלמנט Delegated Payment Spec, שפותח בעיקר על ידי ענקית התשלומים Stripe.
המטרה שלו היא לאפשר תשלום מאובטח בלי ש-OpenAI תיחשף לפרטי כרטיס האשראי.
המנגנון מבוסס על “טוקן תשלום משותף” (Shared Payment Token – SPT) והוא עובד באופן הבא: סוכן ה-AI מכין בקשת תשלום חד פעמית עם סכום מקסימלי וזמן תפוגה, וספק התשלומים מחזיר טוקן מאובטח שמועבר לסוחר. הסוחר משתמש בטוקן זה בתוך מערכת הסליקה הקיימת שלו, מה שמאפשר לו לשמור על תאימות לתקני PCI מבלי לשנות את ספק הסליקה שלו (עוד על SPT באתר של Stripe).
מבחינתכם זה נראה כמו תשלום רגיל. מבחינת המשתמש, הכל קורה בתוך הצ’אט.
דוגמה למבנה רשומה בפיד ACP בפורמט JSONL
עבור סוחרים המעוניינים להטמיע את ACP באופן עצמאי, הפורמט המועדף על ידי OpenAI הוא jsonl.gz.1 להלן דוגמה הממחישה את הנתונים הנדרשים כדי שסוכן ה-AI יוכל “להבין” את המוצר ולהמליץ עליו בביטחון:
{
“id”: “SKU-9988-IL”,
“gtin”: “7290001234567”,
“title”: “נעלי ריצה שטח לנשים – TrailMaster Pro 2026”,
“description”: “נעליים עמידות למים עם סוליית Vibram לאחיזה מקסימלית בתנאי בוץ וסלע. אידיאליות לרצות שטח המחפשות יציבות במסלולים טכניים ובלימת זעזועים מתקדמת.”,
“price”: “550.00 ILS”,
“availability”: “in_stock”,
“inventory_quantity”: 42,
“enable_search”: “true”,
“enable_checkout”: “true”,
“popularity_score”: 94,
“return_rate”: 0.03,
“material”: “Gore-Tex, Rubber”,
“shipping”: “IL:all:Standard:29.00 ILS”,
“seller_privacy_policy”: “https://www.myshop.co.il/privacy”
}
ה-AI לא רק “קורא” את המידע אלא מסיק ממנו מסקנות. אם בדוגמא הזו בשדה material מופיע Gore-Tex, ואם בתיאור מצוינת עמידות למים, סוכן ה-AI יודע לענות בביטחון למשתמש שמחפש נעליים לריצה בגשם, וגם להסביר למה הדגם הזה מתאים בדיוק לצורך שלו.
לסיכום, הטבלה הבאה מציגה את השוואה בין המודל המסורתי למודל האג’נטי בתוך אקו-סיסטם של OpenAI:
| מאפיין | מסחר מסורתי (Web-Based) | מסחר אג’נטי ב-ACP |
| נקודת המגע (Touchpoint) | אתר אינטרנט או אפליקציית מובייל | ממשק שיחתי (LLM) או עוזר קולי |
| תהליך הגילוי | חיפוש מילות מפתח וסינון ידני | שיחה בשפה טבעית וסינון מבוסס הקשר |
| תפקיד הבינה המלאכותית | המלצות מוצרים בתחתית הדף | סוכן רכש המבצע השוואה, בחירה וסליקה |
| מקור האמת (Source of Truth) | דף ה-HTML המוצג למשתמש | פיד נתונים מובנה ב-JSON/CSV בזמן אמת |
| מהירות העסקה | תלויה בניווט המשתמש וריבוי לחיצות | Instant Checkout, רכישה בלחיצה אחת |
| נאמנות הלקוח | נאמנות למותג או לפלטפורמת המסחר | נאמנות לסוכן ה-AI ולדיוק המלצותיו |
פרוטוקול UCP של גוגל: האקוסיסטם הרחב והקשר עם המשתמש
לפני שבועיים כתבתי על ההשקה הרשמית של פרוטוקול UCP והוא עדיין נמצא בשלבים מוקדמים מאוד של הטמעה. גוגל הציגה אותו כחלק מהחזון שלה למסחר אג’נטי בתוך Gemini ובשילוב עם AI Mode, כולל שיתופי פעולה עם שותפים אסטרטגיים מהשורה הראשונה. בפועל, מדובר בפרוטוקול חדש שצפוי עוד להתפתח ולעבור לא מעט שינויים והתאמות.
אם ACP של OpenAI מתמקד בעיקר ברגע הקנייה עצמו, ה-UCP של גוגל מגיע מזווית אחרת לגמרי.
גוגל לא ניסתה ״להעתיק״ את המודל של ChatGPT, אלא לבנות שכבה רחבה יותר שמכסה את כל מסע הלקוח, מגילוי ראשוני בתוך Gemini, דרך הרכישה, ועד לניהול הזמנה ותמיכה אחרי הקנייה.
לשם כך היא השיקה את UCP, בשיתוף עם קמעונאיות ענק כמו Walmart ו-Target, ועם פלטפורמות מסחר כמו Shopify ו-Etsy. המטרה ברורה: ליצור פרוטוקול אחד שיכול לעבוד על פני כל האקוסיסטם של גוגל.
אחד הרעיונות המרכזיים ב-UCP הוא ה-Business Agent.
זהו סוכן AI ממותג שפועל בתוך Gemini ותוצאות החיפוש, ועונה על שאלות בשם העסק. המשמעות היא שגם בסביבה אוטונומית, שבה סוכן AI מנהל את האינטראקציה, גוגל מאפשרת למותגים לשמור על קול מותגי ברור ולא להפוך לישות גנרית וחסרת זהות.

איך עובד פרוטוקול UCP?
כדי להבין את UCP, צריך לשחרר לגמרי את המושג של “משפך מכירות”.
במודל הקלאסי, המשתמש מתקדם בצורה יחסית ליניארית: דף נחיתה –> דף מוצר –> עגלה –> צ׳ק-אאוט.
ב-UCP זה לא עובד ככה.
המערכת פועלת כ-State Machine (מכונת מצבים), שבה מתקיים דיאלוג רציף בין סוכן ה-AI לבין השרת של הסוחר. כל שינוי בכוונת המשתמש, כתובת משלוח, אמצעי תשלום או תנאי רכישה, מעביר את המערכת למצב חדש שמחושב בזמן אמת.
עוד הבדל חשוב הוא ש-UCP מוגדר כ-Server-selects. כלומר, השרת של העסק הוא זה שמצהיר בכל רגע נתון:
- אילו יכולות הוא תומך בהן
- איזו גרסת פרוטוקול פעילה
- אילו שיטות תשלום זמינות
הגישה הזו מבטיחה שהסוחר נשאר ה-Merchant of Record, ולא ״נבלע״ בתוך הפלטפורמה. עבור מותגים גדולים זה קריטי, כי זה מונע את הפחד להפוך לספק סחורה חסר זהות בתוך מערכת של גוגל.
הטבלה הבאה מפרטת את 4 הישויות המרכזיות ב-UCP:
| ישות | תפקיד במערכת | אינטראקציה עיקרית |
|---|---|---|
| Platform | הסוכן או האפליקציה (Gemini) | גילוי יכולות הסוחר וניהול הממשק מול המשתמש |
| Business | שרת הסוחר וה-API שלו | אספקת נתוני מוצרים, חישוב עלויות וביצוע ההזמנה |
| Credential Provider | ספקי אמצעי תשלום (Google Pay) | הנפקת טוקנים מאובטחים לביצוע העסקה |
| Payment Service Provider | ספקי סליקה (Stripe, Adyen) | עיבוד התשלום בפועל וסליקת הכספים |
ההפרדה הזו מאפשרת לגוגל להיות המתווך החכם, בלי להיות הסוחר עצמו.
Google Merchant Center
מבחינה פרקטית, הצעד הראשון עבור כל חנות שרוצה להופיע ב-Gemini הוא הגדרה מדויקת ב-Google Merchant Center.
פיד המוצרים הוא הבסיס שעליו הסוכן נשען כדי להבין אם מוצר רלוונטי לבקשת המשתמש. אבל ב-UCP נוספו מאפיינים חדשים שדורשים תשומת לב מיוחדת.
המאפיין הקריטי ביותר הוא native_commerce.
כאשר הערך שלו מוגדר כ-true, גוגל מבינה שהמוצר כשיר לתהליך Native Checkout מלא.
אם הוא חסר או מוגדר כ-false, המוצר עדיין יכול להופיע בתוצאות, אבל הסוכן לא יוכל להשלים עבורו רכישה אוטונומית.
בנוסף, UCP מציב דרישות מחמירות. הסוכן מחויב להציג אזהרות משפטיות או בטיחותיות לפני רכישה, ולכן יש להגדיר מאפיינים כמו:
- consumer_notice_type למשל safety_warning
- consumer_notice_message טקסט מפורש של האזהרה, עד 1,000 תווים
בנוסף, בעולם האג׳נטי המשתמש לא מחפש בעצמו דף שאלות נפוצות. לכן מדיניות החזרות חייבת להיות מוגדרת בצורה מפורטת ב-GMC, כולל עלות החזרה, חלון זמן וקישור למדיניות המלאה.
גילוי היכולות: פרופיל העסק
אחד החלקים המעניינים ב-UCP הוא מנגנון הגילוי.
הסוחר נדרש לפרסם ״פרופיל עסק״ בנתיב מוסכם:
/.well-known/ucp/
זהו מסמך JSON שמאפשר לסוכן ה-AI להבין מי אתם, מה אתם מציעים ואילו פעולות אפשר לבצע מולכם, בלי להכיר מראש את מבנה האתר.
הפרופיל כולל:
- רשימת Services
- Capabilities פונקציונליות כמו dev.ucp.shopping.checkout או dev.ucp.shopping.discount
- הגדרות תשלום, כולל Merchant ID ומנגנוני טוקניזציה
זו נקודת המפגש הראשונה בין הסוכן לעסק.
מימוש הרכישה: Native Checkout מול Embedded Checkout
ב-UCP גוגל מאפשרת לבחור בין שני מסלולי רכישה, בהתאם למורכבות המוצר והלוגיקה העסקית:
- Native Checkout: זהו המסלול המועדף, הוא מאפשר למשתמש להשלים רכישה בתוך Gemini, בלי לצאת לממשק חיצוני. כדי שזה יעבוד, הסוחר צריך לממש חמישה Endpoints מרכזיים:
- POST /checkout-sessions: יצירת סשן רכישה ראשוני.
- PUT /checkout-sessions/{id}: נקודת הקצה הקריטית ביותר. מופעלת בכל שינוי של כתובת או שיטת משלוח. השרת חייב לחשב מחדש מיסים ומשלוח ולהחזיר תשובה בזמן אמת. תגובה איטית כאן עלולה לגרום לנטישת עגלה.
- POST /checkout-sessions/{id}/complete: קבלת טוקן התשלום, אימות מול ספק הסליקה ויצירת ההזמנה במערכות העסק.
- GET /checkout-sessions/{id}: שליפת מצב הסשן.
- DELETE /checkout-sessions/{id}: סגירת הסשן במקרה של ביטול.
- Embedded Checkout: מיועד למקרים מורכבים יותר, למשל התאמה אישית של מוצר, בחירת תאריך בלוח שנה או דרישות רגולטוריות מיוחדות. כאן גוגל מציגה IFrame של דף הצ׳ק-אאוט של הסוחר בתוך ממשק ה-AI. המימוש מבוסס על Embedded Checkout Protocol, כולל Two Handshakes ותקשורת באמצעות postMessage, תוך הסתרת אלמנטים מיותרים כדי לשמור על רצף הרכישה.
השוואת Google UCP מול OpenAI ACP
בסופו של דבר, עבור בעל חנות איקומרס השאלה היא לא ״איזה פרוטוקול יותר חכם״, אלא איפה נכון להשקיע משאבי פיתוח עכשיו, בהתאם ליעדים העסקיים ולפלטפורמות שבהן הלקוחות שלו כבר נמצאים.
גם OpenAI ACP וגם Google UCP מבוססים על קוד פתוח ושואפים לייצר סטנדרט אחיד למסחר אג’נטי, אבל הגישות שלהם שונות מהותית, כמעט פילוסופית.
בצד של OpenAI, ה-ACP מתמקד במטרה אחת ברורה: לאפשר קנייה מיידית ומהירה מתוך ChatGPT.
היתרון הגדול כאן הוא זמן הגעה לשוק. החיבור ל-ChatGPT, יחד עם Stripe ושותפים כמו Salesforce, מאפשר לסוחרים להתחבר יחסית מהר לסביבת רכישה שבה הדיאלוג הוא לב החוויה. ChatGPT נתפס כ”מוח הקניות” שמלווה את המשתמש, מייעץ לו, משווה עבורו, ואז גם מבצע את הרכישה.
בצד של גוגל, ה-UCP משחק משחק אחר לגמרי.
גוגל לא מתמקדת רק ברגע הקנייה, אלא בונה שפה משותפת לכל מסע הלקוח: מגילוי בתוך Gemini, דרך ההחלטה, ועד לניהול הזמנה ותמיכה אחרי רכישה. היתרון הגדול שלה הוא ההקשר.
לגוגל יש גישה למידע היסטורי עמוק על המשתמש: חיפושים קודמים, מיילים, מיקומים, לוחות זמנים, הרגלים. החיבור הזה מאפשר להציע הצעות קנייה שהן הרבה יותר קונטקסטואליות, לא רק ״איזה מוצר מתאים״, אלא ״איזה מוצר מתאים למשתמש הזה, ברגע הזה״.
גם ברמת התשלומים ובמנגנון הגילוי יש הבדל.
| מאפיין | OpenAI ACP | Google UCP |
|---|---|---|
| שותפים ודחיפה | OpenAI, Stripe, Salesforce | Google, Shopify, Walmart, Visa |
| מיקוד מרכזי | קנייה מיידית (Instant Checkout) מהירה | שפה משותפת לכל שלבי המסע (גילוי עד תמיכה) |
| יתרון תחרותי | מהירות הגעה לשוק ואינטגרציה ל-ChatGPT | הקשר משתמש עמוק (Gmail, Maps, Calendar) |
| תשלומים | מבוסס SPT של Stripe (גמיש לכל PSP) | אינטגרציה עמוקה עם Google Pay ו-AP2 |
| גילוי (Discovery) | מבוסס פידים ייעודיים וחימוש ChatGPT | מבוסס GMC וה-Shopping Graph של גוגל |
מה החסרונות של מכירה אג’נטית?
כן כן, יש גם מינוסים. עם ההזדמנות למכור דרך הצ׳אט מגיעה גם האחריות.
ברגע שאתם מאפשרים לסוכן AI לבצע פעולה עסקית אמיתית בשם המשתמש, אתם פותחים שכבת תפעול חדשה לגמרי, עם סיכונים שמחלקות IT ו-CIOs חייבים להכיר מראש.
1. אבטחה
המעבר מחנות סגורה למערכת של Endpoints פתוחים מייצר מרחב תקיפה חדש. נקודות קצה ליצירת Checkout Sessions, חישוב מיסים או בדיקת זמינות הופכות ליעד פוטנציאלי לבוטים זדוניים, ניסיונות DoS או ניסיונות גניבת מידע.
המשמעות היא שחייבים לשים דגש על דברים כמו:
- להטמיע WAF מתקדם.
- לדעת להבחין בין סוכן לגיטימי של Google או OpenAI לבין תנועה חשודה.
- לנטר שימוש חריג ב-Endpoints בזמן אמת.
במיוחד ב-UCP, שבו בקשות מתבצעות בתדירות גבוהה, כל השהייה או תקלה עלולות לגרום לסוכן לנטוש את השרת ולעבור לאלטרנטיבה הבאה.
2. ביצועים
במסחר אג’נטי אין סבלנות. אם השרת שלכם לא מחזיר תשובה בזמן, הסוכן לא ״יחכה״, הוא פשוט ימשיך הלאה.
המערכות חייבות לעמוד בעומסי קצה, במיוחד בשלב חישוב המשלוח, המיסים והזמינות הסופית. זמני תגובה הם כבר לא עניין של UX, אלא של זכייה או הפסד בעסקה.
3. איכות נתונים וסנכרון
אם הסוכן מבטיח ללקוח אספקה תוך יומיים על סמך מידע ישן, וההבטחה לא מתקיימת, הפגיעה במותג קשה ומיידית. לכן נדרשת אופטימיזציה קפדנית לקטלוג:
- GTINs מדויקים
- משקלים וממדים נכונים
- זמני אספקה אמיתיים
- סנכרון מלא בין הפיד, ה-API והמערכות הפנימיות
זכרו שהסוכן משתמש בנתונים האלו כדי לבצע חישובים סופיים בלי מגע יד אדם.
4. אחריות
כאשר סוכן AI מזמין צבע לא נכון, מפרש תיאור בצורה שגויה או בוחר וריאציה לא מתאימה, האחריות כמעט תמיד נשארת אצל הסוחר, כ-Merchant of Record.
חשוב מאד שהמידע יהיה חד משמעי לגבי תיאורים לא עמומים, אפשרויות בחירה מרובות ומינימום פרשנות חופשית לסוכן. עמימות עולה בכסף, בהחזרות וב-Chargebacks (הכחשת עסקה).
לסיכום: מה הצעד הבא שלך כדי למכור מתוך הצ׳אט?
אם הגעתם עד לכאן, אני מניח שהשאלה שאתם שואלים את עצמכם היא לא שאלה של ״אם״, אלא שאלה של ״מתי״.
בלי לחץ, המעבר למכירה מתוך הצ׳אט לא קורה בבת אחת וזה גם לא ״פרויקט AI״ כללי. זה תהליך מדורג, עם החלטות ברורות שצריך לקבל.
הצעד הבא שלכם תלוי בנקודת הפתיחה: אם עדיין לא בדקתם איך המותג שלכם נראה בתוך שיחות AI, זה הזמן להבין האם ואיך אתם מוזכרים, באילו הקשרים, ואיפה אתם נופלים בדרך. בלי השלב הזה, אין טעם לדבר על מכירה מתוך הצ׳אט.
אם אתם כבר מופיעים בשיחות אבל הקנייה נתקעת, כאן בדיוק נכנסים הפרוטוקולים. בדקו האם המידע שלכם נגיש בצורה מובנית, האם קיימת אפשרות ל-Checkout אג’נטי, והאם המערכות שלכם מסוגלות להגיב בזמן אמת לבקשות של סוכן.
אפשר להתחיל מפיילוט קטן, לא צריך להחליף את האתר או לעצור את ה-SEO, אלא לבודד קטגוריה/סט מוצרים/שוק אחד, ולבחון איך נראית מכירה בעולם של Zero click.
בסופו של דבר, השאלה כבר לא תהיה ״איך אני מביא עוד טראפיק לחנות״, אלא ״האם כשסוכן AI מחפש פתרון עבור משתמש, אני בכלל אופציה״ 🙂
עבדכם הנאמן הצטרף בתור מייסד שותף לחברת Chatoptic, תוכנה המאפשרת לכל מותג להבין איך הוא מופיע במודלי AI, אז אם מעניין אתכם לבדוק איך אתם מופיעים מוזמנים לתאם איתנו דמו לא מחייב.