סקילים — חיבור, ידע ומתודולוגיה

עודכן 30.08.2026

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

`myb-p-getting-started`

מאפס עד חיבור מוכח: פתיחת חשבון ← התחברות ראשונה ← חיבור התוסף ← הוכחה ← המשימה הראשונה.

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

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

שתי דרכי החיבור — ומה כל אחת אומרת על הסיכון

	Application Id + API Key	התחברות משתמש (OAuth 2.1)
הלקוח שולח	`X-Parse-Application-Id` + `X-Parse-API-Key`	`Authorization: Bearer <token>`
הזהות בשרת	משתמש‑על בשם `Master`	משתמש ה‑CRM שהתחבר
מודל הרשאות	אין — עוקף כל הרשאת טבלה	התפקיד שלו בתוספת הרשאות ה‑MCP האישיות
זמין ב	כל לקוח	דפדפן בלבד — לקוחות שולחן עבודה/CLI חסומים כרגע
ביטול	`Revoke` לכל מפתח בנפרד	ניקוי הרשאות ה‑MCP של המשתמש

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

הוכחת שלוש הקריאות — לעולם לא לדלג

initialize ורשימת הכלים מצליחות גם בלי אימות, ולכן “השרת ירוק” לא מוכיח דבר. רק קריאת כלי אמיתית מוכיחה.

#	הקריאה	תשובה תקינה	מה זה מוכיח
1	`Usage-Guide`	טקסט ההוראות של השרת	התעבורה עובדת, ומול שרת MyBusiness
2	`Get-Current-User`	המשתמש שהתחבר · או הזהות הסינתטית `username: "Master"` (מצב מפתח; בגרסאות שרת ישנות `Error: User name not found`)	האימות עובד — ובאיזה מצב
3	`Get-Schema` (בלי פרמטרים)	אובייקט שמפתחותיו הם שמות הטבלאות	הגעתם לבסיס נתונים אמיתי

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

הדיווח נראה כך:

מחובר לבסיס הנתונים <שם/סאב‑דומיין> בזהות <משתמש או Master>. יש בו <n> טבלאות, כולל <3–4 שמות מזוהים>. זו המערכת הנכונה?

המשימה הראשונה — טבלת הניתוב

אחרי שהחיבור הוכח, הסקיל אומר מה יש במערכת (ספירת מודולים וטבלאות מ‑Get-Schema/Count-Data) ומציע שלוש נקודות פתיחה, כשכל אחת מועברת לסקיל שאחראי עליה:

המשתמש רוצה…	הסקיל
“האם המערכת יודעת X?” / סקירת דרישות	`myb-p-kb` ← `myb-p-fit-gap`
מודול או ישות חדשה מקצה לקצה	`myb-p-create-entity`
דף כרטיס, רשימה, דשבורד, דוח	סקילי הממשק · דוחות
אוטומציה, התראות, יעדי זמן	סקילי האוטומציה
ייבוא נתונים או טופס באתר	נתונים ואינטגרציות
משתמשים, תפקידים, הרשאות	`myb-p-users-roles-permissions`

ארבעת כללי הברזל

לעולם לא להכניס API Key לקובץ משותף או מנוהל‑גיט — לא ל‑repository, לא ל‑.mcp.json של פרויקט, לא לצ’אט. קונפיגורציית התוסף שומרת אותו בכספת של מערכת ההפעלה; שם מקומו.
לעולם לא לבקש מהמשתמש את סיסמת החשבון שלו. מצב ההתחברות לוקח אותו לדף ההתחברות הרשמי; מצב המפתח לא צריך סיסמה כלל.
חיבור אחד = בסיס נתונים אחד. אין כלי חוצה‑מערכות. עובדים מול כמה מערכות? מחליפים חיבור — ומאמתים עם Get-Current-User + Get-Schema אחרי כל החלפה.
מוכיחים לפני שכותבים. זהות מאושרת של בסיס הנתונים היא הדבר היחיד שעומד בין בקשת הדגמה לבין שינוי במערכת ייצור.

מגבלות ידועות

התחברות משתמש חסומה בלקוחות שולחן עבודה/CLI — ה‑callback המקומי נדחה לפני שהוא מגיע לשרת. עד שזה ייפתח, שם משתמשים במפתח.
הרשאות MCP ניתנות לכל משתמש בנפרד, לא לתפקיד — קליטת עשרה משתמשים = עשר הענקות. בלשונית ארבע תיבות (Read / Create / Update / Edit pages and schema), והן זמינות רק במערכת עם חבילת מנוי — במערכת ללא חבילה הן מנוטרלות.
הסקיל מקים ומוכיח את החיבור; הוא לא מאבחן את ה‑CRM עצמו. שגיאת גישה ברמת טבלה (Permission denied on get) היא שאלת הרשאות.

`myb-p-kb`

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

myb-p-kb/references/
├── 00-overview/             סקירת מוצר · ארכיטקטורה · מילון מונחים · סביבות וגישה
├── 10-modules/              CRM Core · MyBooks · MyCampaigns · MyChat · MyCollege · TimeSheet · MyInbox
├── 20-data-model/           סקירה · טבלאות ליבה · טבלאות מודולים · טבלאות מערכת ולוגים · טיפוסים ומוסכמות
├── 30-customization/        דפים · טבלאות תצוגה · דשבורדים ודוחות · טריגרים · חוקי טופס ·
│                            הרשאות · מינוח · מסמכים · דפוסי שדות · Blueprints · פורטלים
├── 40-integrations-api/     Parse REST · קטלוג כלי MCP · getlead/web2table · פונקציות ענן ·
│                            ערוצי הודעות · קבצים ואחסון
├── 50-ui-walkthrough/       סיור בממשק הריצה ובממשק הבנייה — עם צילומי מסך
├── 60-implementation-methodology/  מחזור יישום · אפיון · fit-gap · אפיון טכני · תוכנית · אומדנים
├── 80-capability-matrix/    מטריצת יכולות + מגבלות ידועות
└── 90-appendices/           קטלוג מדריכי התמיכה · שאלות נפוצות

כל קובץ נפתח בשורת Purpose ומסתיים ב‑Limitations & gotchas.

חמשת כללי השימוש — והם מחייבים

מערכת חיה גוברת על מסמכים. לפני שמבטיחים התנהגות על מערכת ספציפית — מאמתים בקריאות MCP לקריאה בלבד (Get-Schema, Get-Triggers, Get-Site-Pages). סכימות מתפצלות בין לקוחות.
כל דבר שמסומן ⚠️ UNVERIFIED חייב אימות לפני שמסתמכים עליו או מבטיחים אותו.
תשובות יכולת משתמשות בסולם: Native / Config / Custom-JS / Custom-Server / External / Gap.
טענות שמצטטות מספרי קריאות שירות או “ב‑QA” — פגות תוקף. מאמתים מחדש בזמן השימוש.
אם התיעוד שגוי — אומרים את זה במפורש בתשובה ומסמנים למתחזקים. לא עוקפים בשקט.

למה סוכן מותקן עונה תשובות מוצר מדויקות יותר

זו לא שאלה של “יותר מידע”. זו שאלה של מאיפה מגיעה התשובה.

סוכן בלי התוסף עונה על “האם MyBusiness יודע לעשות X?” מהאינטואיציה שלו על מערכות CRM בכלל. הוא ייתן תשובה שנשמעת סבירה, ולפעמים היא תהיה נכונה. הבעיה היא שאין דרך לדעת מתי.

סוכן עם myb-p-kb עובד אחרת:

הוא ניגש למטריצת היכולות, שהיא מגובת‑ראיות — כל שורה מצביעה למנגנון ספציפי.
הוא חייב לבדוק את 02-known-limitations.md לפני שהוא אומר “כן”. זה כלל מנוסח, לא המלצה.
אם השורה חסרה במטריצה, יש לו סדר חיפוש מוגדר: Blueprints של פתרונות ← מסמך התחום ← אימות חי בסביבת ניסיון.
הוא מסווג לסולם, כלומר התשובה כוללת גם מי משלם על זה: Native הוא בחינם, Custom-Server הוא כרטיס פיתוח.
ולכל טענה יש מקור: שורה במטריצה, blueprint, או אימות חי שהוא הרגע ביצע.

ההבדל בפועל הוא בין “כן, אפשר לבנות SLA” לבין “כן — אבל טבלאות ה‑SLASettings הן מעטפת קונפיגורציה בלבד, אין מנוע ריצה שכותב את SLADeadline, ולכן זה Config שדורש שלושה טריגרים שנבנים בפרויקט. חישוב ימי עסקים אמיתי מעלה את זה ל‑Custom-Server.”

התשובה השנייה היא זו שאפשר לתמחר.

`myb-p-fit-gap`

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

השיטה: סולם היכולות + עקרון fit-to-standard first — adopt > adapt > build — עם הכרעות מנוסחות לפערים, ו‑workbook עקיב שמסמך האפיון הטכני צורך.

סדר החיפוש — מחייב

לעולם לא מסווגים מהזיכרון. הסדר:

מטריצת היכולות ← ואז תמיד מגבלות ידועות, לפני כל “כן”. שורה חסרה? ← Blueprints של פתרונות ← מסמך התחום ← אימות חי בסביבת ניסיון.
עוגני אומדן ממדריך ההערכות.
מסמך השיטה + ה‑playbook של הסיווג בסקיל.

הסולם

המחלקה	המשמעות	הבעלים
Native	עובד מהקופסה, או הגדרה	—
Config	ללא קוד: שדות, דפים, תצוגות, דשבורדים, דוחות, טריגרים, חוקי טופס, תפקידים, מינוח, תבניות	מיישם / AI
Custom-JS	JS/CSS ברמת הדף	מיישם + סקירת מפתח
Custom-Server	פונקציית שרת (כרטיס פיתוח)	מפתח
External	Make/Zapier/שירות חיצוני מחזיק את זה	מפתח/מיישם + השירות
Gap	לא פתיר באופן מקובל היום	—

ולצדן שתי הכרעות שיכולות לפתור שורה במקום מחלקה:

Process-change — השינוי בתהליך, לא במערכת. הלקוח מתאים את עצמו לזרימה הסטנדרטית. דורש הסכמה מתועדת של הלקוח.
Defer — חדר המתנה, עם תאריך חזרה.

כל צעד למטה בסולם דורש שורת נימוק כתובה.

מה חייב להופיע בכל שורה

הפריט	מה זה
סקיצת פתרון	המנגנון בשמו: “טריגר מתוזמן על `Cases.NextStepDate` +6 שעות ← מייל ל‑`OwnerId`”. אם אי אפשר לכתוב את השורה הזו — לא סיווגתם.
בדיקת מגבלה	מול המגבלות הידועות: שרשרות טריגרים ≤3, כותבים שדורסים, קיבוץ מצטבר על String, אין דה‑דופליקציה ילידית
מאמץ	S/M/L/XL לפי העוגנים
בעלים	מי מבצע
דגל ייעוץ מפתח	לכל שורת `Custom-Server` / `External` — ייעוץ של חמש דקות מונע שבוע שנמכר בטעות

החלטת ההיקף

עדיפות × מאמץ	ברירת המחדל
חובה + S/M	בהיקף
חובה + L/XL	לאתגר את הדרישה קודם — האם blueprint או וריאנט רזה עונים על הצורך?
רצוי/אפשרי + L/XL	שלב 2, עם תאריך חזרה

לכל Gap אחת משלוש הכרעות כתובות: עוקף (כולל עלות החיכוך שלו) / דחייה / הסרה מההיקף (עם יידוע הלקוח). מהשורות נגזרת רמת המורכבות (Low/Medium/High/Enterprise = השלב העמוק ביותר שנעשה בו שימוש) — והיא מכתיבה את שאר ההתקשרות.

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

התוצר

דוח HTML ממותג בעברית + fit-gap.csv — ההעברה המכונתית לסקיל האפיון הטכני.

חמשת כללי הברזל

מחפשים, לא מנחשים. כל סיווג מצטט שורת מטריצה, blueprint, או אימות חי. תשובה “מהניסיון” היא באג.
טענות שמצטטות כרטיסים פתוחים או “ב‑QA” פגות — לאמת מחדש.
גיליתם יכולת או מגבלה שהמטריצה לא מכירה — לציין בדוח וגם לסמן למתחזקים.
“Config בתיאוריה, Custom בפועל”: 14 טריגרים שלובים גרועים מפונקציית שרת אחת. שופטים לפי תחזוקתיות, לא לפי יוקרת המחלקה.
הדוח בעברית; סקיצות הפתרון יכולות לשאת שמות מנגנון באנגלית.

`myb-p-csat-survey`

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

עובד על כל אובייקט עסקי עם אירוע סגירה ואיש קשר נגיש — Cases הוא הנפוץ, אבל Sales, Tasks או ישות מותאמת עובדים זהה.

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

למה הארכיטקטורה נראית כך

המשיב הוא אנונימי, ואנונימי לא יכול לכתוב לפנייה. שלוש עובדות פלטפורמה מדודות כופות את הצורה:

כתיבות Parse REST אנונימיות חסומות ב‑CAPTCHA (קוד 119, This action is not allowed without a valid CAPTCHA) — גם עם create: {"*": true}. הרחבת CLP לא פותחת דף ציבורי; היא רק מרחיבה חשיפה. אם תפסתם את עצמכם פותחים CLP כדי שדף ציבורי יעבוד — עצרו.
web2table ו‑getlead הם מסלולי הכתיבה האנונימיים המאושרים — נתקלתם בשם web2lead? הוא אינו רשום בשרת, והפונקציה הרשומה היא getlead. הם עוקפים CLP (ולכן טבלת הקליטה נשארת סגורה), ו‑web2table דורש phone באופן קשיח (400 missing "phone").
web2table יוצר, לעולם לא מעדכן. שום דבר אנונימי לא מעדכן שורה קיימת.

מכאן ארבע השכבות:

מייל · קישור לכל דירוג   →  ?c={{{objectId}}}&p={{{PhoneNumber}}}&r=1|2|3
דף ציבורי                →  web2table  →  שורה בטבלת הקליטה
טריגר היטל               →  מעתיק דירוג / הערה / תאריך אל הפנייה
טריגר תגובה              →  דירוג שלילי  →  משימה או התראה לאחראי

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

ההחלטות שסוגרים לפני שבונים

ההחלטה	למה זה משנה
אילו סטטוסי סגירה מצדיקים סקר?	המלכודת. “נסגר — אין מענה” (מעולם לא הגענו ללקוח) ו“הועבר למחלקה אחרת” (הצוות הזה לא פתר כלום) הם סטטוסי סגירה שאסור שישלחו. בקשו את הרשימה; אל תניחו “כל הסגורים”
כמה רמות?	3 (טוב/סביר/רע) נותן התפלגות שימושית; 2 חד יותר להחלטה. יותר משאלה אחת מוריד את שיעור המענה — אמרו את זה בקול
הניסוח המדויק	עברית מול לקוח. מהבעלים של התהליך, בכתב. לטקסט זמני יש נטייה לעלות לאוויר
תזמון	מיד בסגירה (ברירת מחדל) או בהשהיה דרך טריגר מתוזמן
תקרה ללקוח?	בלי תקרה, לקוח כבד נסקר על כל פנייה
מה קורה בדירוג שלילי	משימה נכנסת לתור עבודה; התראה לא. בוחרים במכוון
הטלפון ב‑URL	החלטת פרטיות ששייכת ללקוח, לא לכם

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

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

Get-Schema(<הטבלה העסקית>)        ← Pointer לאיש הקשר, שדה האחראי, שדה הסטטוס
Get-Data(<טבלת הסטטוסים>)         ← סטטוסי הסגירה וה-objectIds, לשאול בשמות אמיתיים
Get-Schema("SatisfactionSurveys") ← ייתכן שכבר קיימת במערכת ותיקה (במערכת חדשה אינה קיימת)
Get-Triggers(<הטבלה העסקית>)      ← לרוב כבר יש טריגר מייל סגירה: כבוי, או על הסטטוסים הלא נכונים
Get-Site-Pages                     ← דף ציבורי קיים מוכיח שהמסלול עובד כאן — וזה הדבר הכי טוב לשכפל

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

טבלת הקליטה

משתמשים ב‑SatisfactionSurveys אם קיימת. אחרת — בונים במינימום שנדרש:

השדה	הטיפוס	למה
`CaseId`	Pointer ← הטבלה העסקית	הרשומה המדורגת; גם מפתח הדה‑דופליקציה
`AccountId`	Pointer ← `Accounts`	פילוח לפי לקוח
`OverallRating`	Number	לא String — אי אפשר לחשב ממוצע של טקסט
`AdditionalComments`	String	המילה החופשית, כשנכתבת
`OwnerId`	Pointer ← `_User`	מועתק מהרשומה — זה מה שמאפשר CSAT לכל נציג
`RespondedAt`	Date	חשבון שיעור המענה

משאירים את ה‑CLP סגור. טבלה שנוצרת ב‑Create-Table נולדת עם find/get ל‑requiresAuthentication ו‑create/update/delete ל‑role:Admin בלבד — אין בה שום פתח אנונימי, וכך היא צריכה להישאר; web2table כותב בכל מקרה, גם לטבלה סגורה. מוודאים ב‑Get-Table-Permissions שלא פתחתם אותה בטעות בזמן דיבוג.

ארבעת השדות על האובייקט העסקי

CsatRating (Number) · CsatComment (String) · CsatAt (Date) — ואלה מה שטריגר ההיטל כותב וכל דוח קורא. בנוסף, סקשן לקריאה בלבד על הכרטיס, כדי שאדם יראה את התשובה במקום שבו הוא עובד.

טריגר השליחה — הצעד שנוגע בעולם החיצון

Set-Trigger על הטבלה העסקית: events: ["update"], onSetFields: ["<שדה הסטטוס>"], קריטריונים רק לסטטוסים שסוכמו, oneachupdate: false, ופעולת email שמפנה לתבנית.

בונים אותו active: false. מפעילים רק לחלון מבוקר, מול רשומות בדיקה שכתובת איש הקשר שלהן פנימית.
מסיטים כל פעולת מייל, לא רק אחת. טריגר יכול לשאת כמה פעולות מייל; אדם אמיתי כבר קיבל מייל בדיקה כי אחת משתיים נשארה מכוונת לייצור.
מכבים ב‑finally, ומאמתים את הכיבוי ב‑Get-Triggers — לא סומכים על תשובת ההצלחה.
משאירים כבוי עד שהבעלים של התהליך אישר את הניסוח.
לפני הפעלה אמיתית — בודקים בטבלת אנשי הקשר כתובות דמה. שורות מילוי עם …@gmail.com הן תיבות דואר חיות בעולם.

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

טריגר ההיטל

על טבלת הקליטה, events: ["create"], פעולת update-object:

{ "targetClass": "Cases",
  "connection": "source.CaseId",
  "fieldsValue": [
    { "field": "CsatRating",  "type": "dynamic", "value": "OverallRating" },
    { "field": "CsatComment", "type": "dynamic", "value": "AdditionalComments" },
    { "field": "CsatAt",      "type": "dynamic", "value": "updatedAt" }
  ]}

source.<Pointer> = “הרשומה שהשורה הזו מצביעה אליה”. הדקדוק המלא: אוטומציה.

טריגר התגובה — ומלכודת הסדר

על טבלת הקליטה, קריטריון OverallRating <= <סף שלילי> ← create-object (משימה לבעלים של התהליך, מקושרת לפנייה וללקוח) או notification.

הדוחות

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

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

קבלה — והשליליים הם העיקר

11 בדיקות, ארבע מהן שליליות. השליליות הן שמפרידות בין “בניתי” לבין “עובד”:

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

מדווחים את הספירה בכנות (n/11), כולל אילו בדיקות לא הצלחתם להריץ.

מלכודות שעולות שעה כל אחת

שתי שורות לכל מענה זה נכון, לא באג — האובייקט העסקי מחזיק את התשובה, טבלת הקליטה היא היומן. כתבו את זה, אחרת מישהו “יתקן”.
אי אפשר לשנות סוג של פעולה במקום. Set-Trigger-Action מדווח הצלחה ומשאיר את הישנה; deleteAction אינו אמין דרך הפרוקסי. להחלפת משימה בהתראה: בונים טריגר חדש נקי ומכבים את הישן.
דירוג שנשמר כ‑String הורג את חישוב הממוצע, ואף אחד לא מבחין עד שהדוח נדרש.
קריטריון Number בטריגר צריך T: "Number" — ערך כמחרוזת פשוט לעולם לא יתאים.
שמירת ה‑JS של הדף מחזירה 403? ה‑WAF של הפלטפורמה דחה את התוכן, לא את הקוד שלכם — חלק מדפוסי ה‑URL וה‑regex ב‑JS של דף חסומים, והכללים משתנים עם הזמן (חסימת גופי ה‑data‑URI הוסרה מנקודת ה‑MCP בגרסאות שרת עדכניות אך נשארה ב‑REST). מעלים את הסקריפט ב‑Upload-Public-File וטוענים אותו מ‑loader בן שתי שורות. אל תנסו לנצח את המסנן בשכתוב הקוד.

מגבלות ידועות

שאלה אחת בלבד. יותר שאלות נכנסות לטבלת הקליטה אבל דורשות טופס אמיתי — וזה מוותר על כלל הלחיצה האחת.
שיעור מענה הוא opt-in ולא ניתן להשלמה לאחור.
אין דה‑דופליקציה של דירוגים. נמען שלוחץ פעמיים יוצר שתי שורות, וההיטל המאוחר מנצח. מקובל ל‑CSAT; לא מקובל אם לציון יש השלכה מסחרית.
מייל בלבד. אותו קישור עובד בהודעת סגירה ב‑WhatsApp ובדרך כלל עונים לו הרבה יותר — אבל המתכון הזה לא בונה את הרגל הזו.

המשך

התקנה בכל סוכן — הצד המעשי של myb-p-getting-started
עבודה בטוחה עם סוכן על מערכת חיה
אינדקס 22 הסקילים