ארבעה מסלולים, דירוגים 0 עד 3, ומנעול אחד במסך אחד.
התמיכה נמכרת כארבע רשומות PLAN_OBJ בתוך config.json שנושאות category "support" ו-rank 0 עד 3: Starter ב-0, Developer ב-1, Business ב-2 ו-Enterprise ב-3. אלה רשומות נפרדות משבע רשומות המנוי, וכל הארבע נושאות price_id של Stripe, כולל שלב Starter החינמי, ולכן התמיכה מופיעה כשורת חיוב נפרדת משלה במינוי המאוחד היחיד, לצד המנוי ו-ai_workspace. מה שהשלבים משנים בקוד הרץ קטן בהרבה ממה שהטבלה מרמזת. בדיוק רשומה אחת מתוך 1010 הרשומות ב-cpi_methods נושאת min_support_plan: submit_support_ticket, שממפה את ticket ל-starter, את chat ל-business ואת call ל-enterprise. זה כל הסולם מבחינת הפלטפורמה. שער המסלול בצד השרת, isValidPlan בקובץ cpi/http_module/index.mjs, קורא רק את cpi_methods[method].min_plan ומשווה אותו מול account.membership_plan; הוא לעולם אינו קורא את min_support_plan ולעולם אינו קורא את support_plan. האכיפה היא אפוא מנעול בצד הלקוח: לוח הבקרה משווה שני דירוגים ב-PLAN_OBJ שטוח ומאפיר Button. העמוד הזה קורא את ארבע הרשומות מול הקוד שבאמת צורך אותן, עוקב אחרי פנייה אחת שנשלחה עד המקומות שאליהם היא מגיעה, ומסתיים ברשימה פשוטה של מה שהסולם מפורסם כעושה ומה שאינו עושה.
הסולם כפי שהוא כתוב, שדה אחר שדה.
כל תא כאן הוא הערך המילולי שברשומת PLAN_OBJ, לא סיכום שלו. שני דברים כדאי לקרוא לרוחב ולא לאורך. שורת price_note מפרסמת תוספת באחוזים בכל שלושת השלבים בתשלום, ואף קובץ ב-cpi, ב-dashboard, ב-shared או ב-website-nuxt אינו קורא את price_note: שום דבר אינו מחשב אחוז ושום דבר אינו גובה אותו. ושורת Support Agents נושאת מחרוזת זהה ב-Developer וב-Business, מילה במילה, כך שאמצע הסולם מתאר את אותו צוות עצמו פעמיים בפער מחיר של פי חמישה עשר. Monitoring הוא המחרוזת המילולית "N/A" בשלושה שלבים; רק ב-Enterprise יש טקסט של ממש.
Starter | Developer | Business | Enterprise | |
|---|---|---|---|---|
| מחיר לחודש | 0 $ | 100 $ | 1,500 $ | 4,500 $ |
| price_note (לא נקרא בשום מקום) | none | 100 $/mo + 2% of monthly Xuda usage | 1,500 $/mo + 5% of monthly Xuda usage | 4,500 $/mo + 7% of monthly Xuda usage |
| Response Time, הנתון הראשון | <72 hr | <4 hr | <2 hr | <30 min |
| מערכת ייצור מושבתת | not stated | <1 hr | <30 min | <10 min |
| מחרוזת Support Channels / מערך channels | Email / ticket | Email / ticket | Email, Chat / ticket, chat | Email, Chat, Call / ticket, chat, call |
| Support Agents | Customer service team offering broad-based assistance. | Highly skilled technical staff, proficient in all products. | Highly skilled technical staff, proficient in all products. The identical string to Developer. | Dedicated technical team, experts in all products. |
| Monitoring | N/A | N/A | N/A | Incident Detection and Response: round the clock proactive surveillance and incident handling for chosen projects. |
| rank | 0 | 1 | 2 | 3 |
נתיבי נושא ברמה השלישית, ואף אחד מהם אינו נשמר כמסמך
רשומות ב-cpi_methods שנושאות min_support_plan
כל הטווח של יעד התגובה הראשונה בארבעת השלבים
מזהה חשבון ב-support_team_account_ids, שמקבל התראה על כל פנייה של הפלטפורמה
מתודה אחת, שלושה ערוצים, ורק שניים מהם מתעדים משהו.
submit_support_ticket היא המתודה היחידה שסולם התמיכה חוסם. היא דוחה כל communication_type שאינו call, ticket או chat עם קוד -1, ואז מאצילה ל-ticket_submit, שאחראית על השיוך לדייר, על הנושאים, על הפעולות, על ה-SLA ועל ההתראות. שלושת הענפים כאן הם מה שכל ערוץ באמת מגיע אליו. שניים מהם יוצרים מסמך פנייה במוקד של הפלטפורמה. האמצעי, זה ש-Business קונה, אינו קורא למתודה הזאת בכלל.
ארבע רשומות, הצהרה אחת, ושרשרת שנגמרת בדפדפן.
התמיכה היא סולם עצמאי ב-PLAN_OBJ, לא שדה על המנוי. ארבע רשומות נושאות category "support" ו-rank 0 עד 3: Starter 0, Developer 1, Business 2, Enterprise 3, בנפרד משבע רשומות המנוי (free, pro, team, agency ו-enterprise_t1, t2 ו-t3). מה ששלב משנה צר יותר ממה שהטבלה מרמזת, והנקודות כאן אומרות עד כמה: מתודה אחת מתוך 1010 מצהירה על רצפת תמיכה, וההשוואה שאוכפת אותה רצה בדפדפן, על Button.
- הסולם מתומחר ב-0, 100, 1500 ו-4500 לחודש, וכל ארבעת השלבים נושאים price_id של Stripe, כולל שלב Starter החינמי. לכן התמיכה מופיעה כשורת חיוב נפרדת משלה במינוי המאוחד היחיד, לצד המנוי ו-ai_workspace.
- הרצפה מוצהרת פעם אחת. בדיוק רשומה אחת מתוך 1010 הרשומות ב-cpi_methods נושאת min_support_plan: submit_support_ticket, שממפה את ticket ל-starter, את chat ל-business ואת call ל-enterprise, ב-clearance user וב-private true. שום דבר אחר אינו נושא רצפת תמיכה, ולכן קריאת פניות, מענה עליהן, פתיחה מחדש, צירוף קבצים וסגירה יושבים מחוץ לסולם.
- מה שמשתנה בפועל הוא שלוש מחרוזות. features["Response Time"] מכיל "<72 hr", אחר כך "<4 hr, Production system down: <1 hr", אחר כך "<2 hr, Production system down: <30 min", ואחר כך "<30 min, Production system down: <10 min". Support Channels מכיל Email, Email, "Email, Chat", "Email, Chat, Call". Monitoring הוא המחרוזת המילולית "N/A" בשלושה שלבים, ורק ב-Enterprise יש טקסט של ממש, שמתאר זיהוי אירועים ותגובה להם.
- שני שדות ברשומות האלה הם קישוט. כל שלב נושא מערך channels (ticket, אחר כך ticket ו-chat, אחר כך ticket, chat ו-call) שאף קובץ ב-cpi, ב-dashboard, ב-shared או ב-website-nuxt אינו קורא: מפת הערוצים החיה יושבת ב-cpi_methods במקום. השלבים בתשלום נושאים price_note שמפרסם "$100/mo + 2% of monthly Xuda usage", 5% ב-Business ו-7% ב-Enterprise, ו-grep על כל המאגר מחזיר את config ותו לא. שום דבר אינו מחשב אחוז ואינו גובה אותו.
- config.json מצהיר עליוmin_support_plan על submit_support_ticket, הרשומה היחידה מתוך 1010 שיש לה אחד
- get_metrics מפרסם אותוapp_module מעתיק את הרצפה ללקוח לצד min_plan, גם עבור מתודות private שהתיאור והשדות שלהן מוסתרים
- ה-Button משווה דירוגיםisFeatureUnlocked קורא את USER_DATA.support_plan, isValidPlan משווה rank ב-PLAN_OBJ השטוח, ו-Chat או Call מוצגים עם מנעול
- הקפיצה לשרת שאינה קיימתisValidPlan ב-http_module קורא רק את min_plan מול membership_plan, ו-ticket_module אינו קורא את support_plan בכלל
איך באמת נראית פנייה שנשלחה.
מסמך אחד נוחת ב-xuda_tickets על כל שליחה. שלושה שדות שווים קריאה מדוקדקת. first_response_due_ts הוא מועד היעד היחיד שהפלטפורמה קובעת, והוא נקבע רק לפניות של הפלטפורמה, כי למוקד של לקוח אין מסלול תמיכה לקרוא ממנו. resolve_due_ts יושב באותו בלוק ושום דבר לעולם אינו כותב אותו. ושני השדות שהיו מזיזים פנייה מעצמה, action_id ו-assignee, שניהם null ברגע שהיא נוצרת.
שלושה דברים קורים עם הלחיצה על Submit.
submit_support_ticket היא עטיפה דקה. היא דוחה כל communication_type שאינו call, ticket או chat עם קוד -1, מקפלת את הבחירה ברמה השלישית לתוך גוף הפנייה, ומעבירה הכל ל-ticket_submit, שאחראית על השיוך לדייר, על הנושאים, על הפעולות, על ה-SLA ועל ההתראות. מה שבא כאן הוא הפונקציה הזאת, לפי הסדר.
- 01
המוקד, איש הקשר והמספר
שבעה מתוך עשרת מקורות הפנייה המוצהרים הם מקורות של הפלטפורמה, ומקור של הפלטפורמה תמיד מפנה את הדייר ל-support_team_account_ids[0] בלי קשר לערך שהקורא שולח, ולכן לקוח אינו יכול להגיש למוקד של Xuda תחת הדייר שלו עצמו, וגם לא להפך. הפונה מותאם לאיש קשר תחת פרופיל הדייר הזה, והאסמכתה נטבעת ממסמך מונה נפרד לכל דייר: XD-000001 במוקד של הפלטפורמה, TK במוקד של לקוח.
- 02
המסמך וה-interaction הראשון
הפנייה נכתבת ל-xuda_tickets, ואז השליחה עצמה נרשמת כ-interaction מספר אחת, direction in, from requester, visibility public, והיא נושאת את הטקסט ואת כל הצרופות. הנושא מותאם לפי id או לפי שם מול מסמכי ticket_topic שנזרעו, ונושא לא מוכר אינו נדחה: הפנייה נוחתת ללא מיון במקום ללכת לאיבוד.
- 03
שתי התראות, ואפס שיוך
הפונה מקבל את ticket_opened_customer, שמציג את היעד כ-Math.round(response_ms / 3600000) שעות, ולכן פנייה של Enterprise עם יעד של 30 דקות מקבלת אישור עם המחרוזת "1 hours". אחר כך יוצאת הודעת ticket_opened_agent אחת לכל uid ב-support_team_account_ids, והמערך הזה מחזיק בדיוק מזהה אחד, זהה ל-auto_reply_account_id. שום דבר אחר אינו נורה: assignee נשאר null, ומעבר הפעולות מדולג כי אין action_id להפעיל.
עשרה נושאים, 146 תת-נושאים, ו-414 מחרוזות שלעולם אינן נשמרות.
config.support מחזיק בדיוק שלושה מפתחות: auto_reply_account_id, support_team_account_ids ו-ticket_topics. השלישי עמוק שלוש רמות, ורק שתיים מהרמות האלה הופכות למסמכים: _tk_seed_platform_topics כותב מסמך ticket_topic אחד לכל נושא עם תת-הנושאים משובצים בתוכו, והרמה השלישית נשארת במקומה. עשרת הנושאים מקובצים כאן לפי מה שהם עוסקים בו, עם מה שכל אחד תורם ולאן בחירה נוחתת בפנייה הגמורה.
תשעה דברים שסולם התמיכה אינו עושה, כולל זה שהוא נמכר עליו.
- אין לו שום אכיפה בצד השרת בשום מקום. שער המסלול הוא isValidPlan בקובץ cpi/http_module/index.mjs בשורות 542 עד 547, שנקרא בשורה 868, והוא קורא בדיוק שדה אחד, cpi_methods[method].min_plan, ומשווה אותו מול account.membership_plan. הוא לעולם אינו קורא את min_support_plan ולעולם אינו קורא את support_plan, ו-ticket_module לעולם אינו קורא מסלול תמיכה לצורך הרשאה. נעילת הערוץ היא מנעול מצויר על Button, ומאחוריו אין דבר.
- הוא חוסם מתודה אחת מתוך 1010. submit_support_ticket היא הרשומה היחידה ב-cpi_methods שנושאת min_support_plan. קריאת הפניות שלך, מענה על אחת מהן, פתיחה מחדש, צירוף קובץ, סגירה: אף אחת מהן אינה נושאת רצפת תמיכה. הסולם מחליט איזה משלושה כפתורים אינו מואפר במסך אחד, ושם הוא נעצר.
- ל-min_support_plan יש שני קוראים בכל המאגר, ואף אחד מהם אינו בדיקה. app_module מפרסם אותו ללקוח בתוך get_metrics, ו-SupportForm.vue מעביר אותו ל-prop של Button. שום דבר ב-ticket_module אינו מתייעץ בו, ולכן חשבון Starter ששולח communication_type "call" מתקבל: המתודה דוחה רק ערך שאינו call, ticket או chat, עם קוד -1, ואז מאצילה הלאה.
- PLAN_OBJ נושא גם מערך channels בכל רשומת תמיכה, ticket, אחר כך ticket ו-chat, אחר כך ticket ו-chat ו-call. אף קובץ ב-cpi, ב-dashboard, ב-shared או ב-website-nuxt אינו קורא את PLAN_OBJ.channels. מפת הערוצים החיה יושבת ב-cpi_methods במקום, וזה המקום היחיד שבו השניים יכולים לסתור זה את זה בלי ששום דבר ישים לב.
- "Limited selection" ו-"Open selection" מתארים הגבלת נושאים שאינה קיימת. שניהם מחרוזות תצוגה ב-PLAN_OBJ features.support, וההופעות היחידות שלהם מחוץ ל-config.json הן טבלת התמחור הציבורית ושני composables של explore. SupportForm.vue מרנדר כל מפתח של _CONF.support_ticket_topics בלי שום סינון לפי מסלול, ולכן כל 10 הנושאים וכל 146 תת-הנושאים מופיעים באופן זהה ב-free וב-enterprise_t3.
- chat, הדבר ש-Business קונה, יוצא מהפלטפורמה. הפאנל שחסום ברמת Business הוא iframe קשיח של tawk.to בלי כפתור שליחה, ולכן submitRequest לעולם אינו רץ עבורו. לשיחת chat לא נוצרים מסמך פנייה, ticket_no, interaction, תמליל ב-Tickets או SLA. משלושת הערוצים, רק ticket ו-call כותבים משהו.
- ניתוב הנושאים אינו מנתב. _tk_seed_platform_topics כותב את כל 10 נושאי הפלטפורמה ואת תת-הנושאים המשובצים בהם עם action_id: null, ואז _tk_resolve_action_id מחזיר null כשאף אחת מהרמות אינה נושאת אחד, assignee הוא null ברגע היצירה, שום דבר אינו משייך אוטומטית, וכל פנייה של הפלטפורמה מתריעה לאותו מזהה חשבון יחיד. רק שתיים משלוש רמות הנושא הופכות אי פעם למסמכים: 414 המחרוזות ברמה השלישית לעולם אינן נשמרות, וזו שנבחרה נוספת לגוף הפנייה כשורה שאומרת "Detail: <value>".
- ה-SLA הוא מספר אחד, והוא הרך מבין השניים. _tk_response_ms לוקח את המספר והיחידה הראשונים מתוך מחרוזת Response Time, ולכן החצי שעוסק בהשבתת ייצור בכל שלב בתשלום לעולם אינו מפוענח לכדי מועד יעד. היעד שנשמר הוא זמן שחלף בפועל, כולל סופי שבוע, ומייל האישור מדפיס Math.round(response_ms / 3600000) שעות, וכך Enterprise, שהיעד שלו הוא 30 דקות, מקבל אישור עם המחרוזת "1 hours". ו-sla.breached נקבע רק על ידי ticket_auto_close_sweep, שהשאילתה שלו מחזירה פניות שלא הייתה בהן פעילות יותר מ-24 שעות, ולכן יעד של 30 דקות, שעתיים או 4 שעות לעולם אינו יכול להיות מסומן בתוך החלון של עצמו. הסגירה האוטומטית עצמה נשלחת כבויה כברירת מחדל.
- בשוליים: את price_note שמפרסם "$100/mo + 2% of monthly Xuda usage", 5 אחוזים ב-Business ו-7 אחוזים ב-Enterprise, לא קורא אף קובץ ב-cpi, ב-dashboard, ב-shared או ב-website-nuxt, ושום דבר אינו מחשב אחוז ואינו גובה אותו. לתמיכה אין member_price_id, ולכן הנחת המנויים של 10 אחוזים אינה מגיעה אליה. אף עמוד ציבורי אינו מוכר את הסולם. ופאנל המאמרים הפופולריים שולח שאילתה על סוג מסמך ששום דבר במאגר הזה אינו כותב.
השאלות שעמוד תמיכה בדרך כלל משמיט
שש תשובות שנקראו מתוך config.json, http_module, app_module ו-ticket_module, ולא מכרטיס המסלול.
הסיור המודרך, וכלל אחד לצפייה בו.
היכן שההקלטה והעמוד הזה חלוקים על מספר, על ערוץ או על זמן תגובה, העמוד הוא זה שנבנה מהמקור. כל נתון כאן נקרא באוגוסט 2026 מתוך העותק של config.json במאגר ומתוך cpi/http_module, cpi/app_module ו-cpi/ticket_module, ולא הועתק מניסוח קודם. הכלל הזה חשוב כאן יותר מאשר בעמוד על מסך, כי רוב מה שהעמוד הזה מדווח הוא היעדר: שער מסלול שלעולם אינו נבדק בשרת, פאנל צ'אט שאינו כותב מסמך, נושאים שנזרעו וה-action_id שלהם null, ודגל חריגה שאינו יכול להידלק בתוך החלון של עצמו. הקלטה אינה יכולה להראות היעדר. היא כן יכולה להראות את המסך שבו המנעול מצויר, שהוא החלק בסולם שכן עובד.
פתיחת פנייה אחת, ואז קריאת הרשומה שהיא כתבה.
היציאה הראשונה היא מסך התמיכה בלוח הבקרה. בחירת נושא, תת-נושא והפירוט ברמה השלישית, מילוי הטופס ושליחה. זה כותב מסמך פנייה עם אסמכתה שמתחילה ב-XD, יעד תגובה ראשונה אם השלב נושא כזה, אישור קבלה אליך והודעה אחת לחשבון המוקד היחיד, ופרט לטופס ה-call זה המסלול היחיד באותו מסך שכותב משהו בכלל. אחר כך קריאת השורה שהוא יוצר ב-Tickets: האסמכתה, היעד, וה-assignee שהוא null. כל מה שכתוב כאן ניתן לבדיקה שם בערך בדקה. היציאה השנייה היא מסך המסלולים, שבו התמיכה נקנית כקטגוריה משלה לצד המנוי ו-AI Workspace ונוחתת כשורה שלישית במינוי מאוחד אחד. כדאי להגיע לשם בידיעה מה ארבעת השלבים משנים: מחרוזת תגובה שהופכת למועד יעד אחד בזמן שחלף, רשימת ערוצים שמציירת או מסירה מנעול בלוח הבקרה, ושום דבר בשרת. טבלת התמחור הציבורית נושאת שורת Support level אחת ואינה מוכרת את הסולם בכלל.