Quatre paliers, des rangs de 0 à 3, et un seul verrou sur un seul écran.
Le support est vendu sous forme de quatre enregistrements PLAN_OBJ dans config.json, portant la catégorie "support" et un rang de 0 à 3 : Starter au rang 0, Developer au rang 1, Business au rang 2, Enterprise au rang 3. Ce sont des enregistrements distincts des sept enregistrements d'abonnement, et les quatre portent un price_id Stripe, y compris le palier Starter gratuit, ce qui explique pourquoi le support apparaît comme une ligne à part sur l'abonnement unique consolidé, aux côtés de l'abonnement et de ai_workspace. Ce que les paliers changent dans le code en production est bien plus restreint que ce que le tableau laisse penser. Une seule des 1010 entrées de cpi_methods porte un min_support_plan : submit_support_ticket, qui associe ticket à starter, chat à business et call à enterprise. C'est là toute l'échelle, du point de vue de la plateforme. La barrière côté serveur, isValidPlan dans cpi/http_module/index.mjs, ne lit que cpi_methods[method].min_plan et le compare à account.membership_plan ; elle ne lit jamais min_support_plan ni support_plan. L'application de la règle est donc un verrou côté client : le dashboard compare deux rangs dans un PLAN_OBJ plat et grise un Button. Cette page confronte les quatre enregistrements au code qui les consomme réellement, suit un ticket soumis jusqu'aux endroits où il atterrit, et se termine par une liste simple de ce que l'échelle prétend faire et de ce qu'elle ne fait pas.
L'échelle telle qu'elle est écrite, champ par champ.
Chaque cellule ci-dessous est la valeur littérale de l'enregistrement PLAN_OBJ, pas un résumé. Deux éléments méritent d'être lus en ligne plutôt qu'en colonne. La ligne price_note annonce une surtaxe en pourcentage sur les trois paliers payants, et aucun fichier dans cpi, dashboard, shared ou website-nuxt ne lit price_note : rien ne calcule un pourcentage, rien n'en facture un. Et la ligne Support Agents porte la chaîne identique, mot pour mot, sur Developer et sur Business, alors que l'écart de prix entre les deux est de quinze fois. Monitoring est la chaîne littérale "N/A" sur trois paliers ; seul Enterprise porte du texte.
Starter | Developer | Business | Enterprise | |
|---|---|---|---|---|
| Prix par mois | 0 $US | 100 $US | 1 500 $US | 4 500 $US |
| price_note (lu par rien) | none | 100 $US/mo + 2% of monthly Xuda usage | 1 500 $US/mo + 5% of monthly Xuda usage | 4 500 $US/mo + 7% of monthly Xuda usage |
| Response Time, premier chiffre | <72 hr | <4 hr | <2 hr | <30 min |
| Système de production en panne | not stated | <1 hr | <30 min | <10 min |
| Chaîne Support Channels / tableau 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 |
Chemins de sujets de troisième niveau, aucun stocké comme document
Entrées de cpi_methods portant un min_support_plan
Écart complet de la cible de première réponse sur les quatre paliers
Identifiant de compte dans support_team_account_ids, notifié pour chaque ticket plateforme
Une méthode, trois canaux, et seulement deux qui écrivent quelque chose.
submit_support_ticket est la seule méthode que l'échelle de support conditionne. Elle refuse tout communication_type en dehors de call, ticket et chat avec le code -1, puis délègue à ticket_submit, qui gère la tenancy, les sujets, les actions, le SLA et les notifications. Les trois branches ci-dessous montrent où chaque canal aboutit réellement. Deux d'entre elles créent un document de ticket sur le bureau de la plateforme. La branche du milieu, celle que Business achète, n'appelle jamais cette méthode.
Quatre enregistrements, une déclaration, et une chaîne qui s'arrête au navigateur.
Le support est sa propre échelle dans PLAN_OBJ, pas un champ de votre abonnement. Quatre enregistrements portent la catégorie "support" et un rang de 0 à 3 : Starter 0, Developer 1, Business 2, Enterprise 3, distincts des sept enregistrements d'abonnement (free, pro, team, agency et enterprise_t1, t2 et t3). Ce qu'un palier change est plus restreint que ce que le tableau suggère, et les points ci-dessous précisent à quel point : une méthode sur 1010 déclare un seuil de support, et la comparaison qui l'applique s'exécute dans le navigateur, sur un Button.
- L'échelle est tarifée à 0, 100, 1500 et 4500 par mois, et les quatre paliers portent un price_id Stripe, y compris le palier Starter gratuit. C'est pourquoi le support apparaît comme sa propre ligne sur l'abonnement unique consolidé, aux côtés de l'abonnement et de ai_workspace.
- Le seuil est déclaré une seule fois. Une seule des 1010 entrées de cpi_methods porte min_support_plan : submit_support_ticket, associant ticket à starter, chat à business et call à enterprise, avec clearance user et private true. Rien d'autre ne porte de seuil de support, donc lire les tickets, répondre, rouvrir, joindre des fichiers et clore se situent en dehors de l'échelle.
- Ce qui change visiblement, ce sont trois chaînes. features["Response Time"] indique "<72 h", puis "<4 h, Système de production en panne : <1 h", puis "<2 h, Système de production en panne : <30 min", puis "<30 min, Système de production en panne : <10 min". Support Channels indique Email, Email, "Email, Chat", "Email, Chat, Call". Monitoring est la chaîne littérale "N/A" sur trois paliers, et seul Enterprise porte du texte, décrivant la détection et la réponse aux incidents.
- Deux champs de ces enregistrements ne sont que décoratifs. Chaque palier porte un tableau channels (ticket, puis ticket et chat, puis ticket, chat et call) qu'aucun fichier dans cpi, dashboard, shared ou website-nuxt ne lit : la carte des canaux réellement active vit dans cpi_methods. Les paliers payants portent un price_note annonçant "100 $/mois + 2 % de l'usage Xuda mensuel", 5 % sur Business et 7 % sur Enterprise, et une recherche dans tout le dépôt ne renvoie que config et rien d'autre. Rien ne calcule ni ne facture un pourcentage.
- config.json le déclaremin_support_plan sur submit_support_ticket, la seule entrée sur 1010 qui en possède un
- get_metrics le publieapp_module copie le seuil vers le client à côté de min_plan, même pour les méthodes privées dont la description et les champs sont retenus
- Le Button compare les rangsisFeatureUnlocked lit USER_DATA.support_plan, isValidPlan compare le rang dans le PLAN_OBJ plat, et Chat ou Call s'affiche avec un cadenas
- Le passage serveur qui n'existe pashttp_module isValidPlan ne lit que min_plan face à membership_plan, et ticket_module ne lit jamais support_plan
À quoi ressemble réellement un ticket soumis.
Un document atterrit dans xuda_tickets par soumission. Trois champs méritent une lecture attentive. first_response_due_ts est le seul délai que la plateforme fixe, et il n'est fixé que pour les tickets plateforme, puisqu'un bureau client n'a pas de plan de support à lire. resolve_due_ts se trouve dans le même bloc et rien ne l'écrit jamais. Et les deux champs qui feraient avancer un ticket de lui-même, action_id et assignee, valent tous deux null dès la création.
Trois choses se produisent quand vous appuyez sur Submit.
submit_support_ticket est un mince enrobage. Elle refuse tout communication_type en dehors de call, ticket et chat avec le code -1, replie le choix tertiaire dans le corps, et confie le tout à ticket_submit, qui gère la tenancy, les sujets, les actions, le SLA et les notifications. Voici cette fonction, dans l'ordre.
- 01
Le bureau, le contact et le numéro
Sept des dix sources de ticket déclarées sont des sources plateforme, et une source plateforme résout toujours le tenant vers support_team_account_ids[0], quoi que l'appelant transmette, donc un client ne peut pas déposer sur le bureau Xuda sous son propre tenant, ni l'inverse. Le demandeur est rapproché d'un contact sous ce profil de tenant, et une référence est générée à partir d'un document compteur par tenant : XD-000001 sur le bureau plateforme, TK sur un bureau client.
- 02
Le document et la première interaction
Le ticket est écrit dans xuda_tickets, puis la soumission elle-même est journalisée comme interaction un, direction in, from requester, visibility public, portant votre texte et toute pièce jointe. Le sujet est rapproché par id ou par nom des documents ticket_topic préchargés, et un sujet inconnu n'est pas rejeté : le ticket atterrit sans tri plutôt que d'être perdu.
- 03
Deux notifications, et aucune assignation
Le demandeur reçoit ticket_opened_customer, qui affiche la cible sous forme Math.round(response_ms / 3600000) heures, si bien qu'un ticket Enterprise avec une cible de 30 minutes est accusé réception avec la chaîne "1 hours". Puis un avis ticket_opened_agent part par uid dans support_team_account_ids, et ce tableau contient exactement un identifiant, identique à auto_reply_account_id. Rien d'autre ne se déclenche : assignee reste null, et le passage des actions est sauté faute d'action_id à déclencher.
Dix sujets, 146 sous-sujets, et 414 chaînes jamais stockées.
config.support ne contient que trois clés : auto_reply_account_id, support_team_account_ids et ticket_topics. La troisième est profonde de trois niveaux, et seuls deux de ces niveaux deviennent des documents : _tk_seed_platform_topics écrit un document ticket_topic par sujet, avec les sous-sujets intégrés, et le troisième niveau reste où il était. Les dix sujets sont regroupés ci-dessous par thème, avec ce que chacun apporte et où un choix atterrit sur le ticket terminé.
Neuf choses que l'échelle de support ne fait pas, y compris celle sur laquelle elle est vendue.
- Il n'existe aucune application côté serveur, nulle part. La barrière de plan est isValidPlan dans cpi/http_module/index.mjs, lignes 542 à 547, appelée à la ligne 868, et elle ne lit qu'un seul champ, cpi_methods[method].min_plan, comparé à account.membership_plan. Elle ne lit jamais min_support_plan ni support_plan, et ticket_module ne lit jamais un plan de support pour l'autorisation. Le verrou de canal est un cadenas dessiné sur un Button, et il n'y a rien derrière.
- Elle conditionne une méthode sur 1010. submit_support_ticket est la seule entrée de cpi_methods à porter min_support_plan. Lire vos tickets, répondre à l'un d'eux, le rouvrir, joindre un fichier, le clore : aucun de ces gestes ne porte de seuil de support. L'échelle décide lequel des trois boutons n'est pas grisé sur un écran, et s'arrête là.
- min_support_plan a deux lecteurs dans tout le dépôt, et aucun n'est un contrôle. app_module le publie vers le client dans get_metrics, et SupportForm.vue le transmet à une prop de Button. Rien dans ticket_module ne le consulte, donc un compte Starter qui poste communication_type "call" est accepté : la méthode ne refuse qu'une valeur en dehors de call, ticket et chat, avec le code -1, puis délègue.
- PLAN_OBJ porte aussi un tableau channels sur chaque enregistrement de support : ticket, puis ticket et chat, puis ticket, chat et call. Aucun fichier dans cpi, dashboard, shared ou website-nuxt ne lit PLAN_OBJ.channels. La carte des canaux réellement active vit dans cpi_methods, seul endroit où les deux pourraient diverger sans que personne ne s'en aperçoive.
- "Sélection limitée" et "Sélection ouverte" décrivent une restriction de sujets qui n'existe pas. Les deux sont des chaînes d'affichage dans PLAN_OBJ features.support, et leurs seules occurrences en dehors de config.json sont le tableau public des tarifs et deux composables explore. SupportForm.vue affiche chaque clé de _CONF.support_ticket_topics sans aucun filtre de plan, donc les 10 sujets et les 146 sous-sujets apparaissent à l'identique sur un compte gratuit comme sur enterprise_t3.
- Le Chat, ce que Business achète, quitte la plateforme. Le panneau conditionné à Business est un iframe tawk.to codé en dur, sans bouton de soumission, donc submitRequest ne s'exécute jamais pour lui. Aucun document de ticket, aucun ticket_no, aucune interaction, aucune transcription dans Tickets et aucun SLA n'est créé pour une conversation de chat. Des trois canaux, seuls ticket et call écrivent quelque chose.
- L'acheminement des sujets n'achemine rien. _tk_seed_platform_topics écrit les 10 sujets plateforme et leurs sous-sujets intégrés avec action_id: null, _tk_resolve_action_id renvoie alors null quand aucun des deux niveaux n'en porte un, assignee vaut null à la création, rien n'assigne automatiquement, et chaque ticket plateforme notifie le même identifiant de compte unique. Seuls deux des trois niveaux de sujet deviennent jamais des documents : les 414 chaînes de troisième niveau ne sont jamais stockées, et celle choisie est ajoutée au corps sous forme d'une ligne "Detail: <value>".
- Le SLA se résume à un seul chiffre, et c'est le plus indulgent des deux. _tk_response_ms prend le premier nombre et unité de la chaîne Response Time, donc la moitié "système en panne" de chaque palier payant n'est jamais analysée en délai. La cible stockée est un temps écoulé brut, week-ends compris, et l'e-mail d'accusé de réception affiche Math.round(response_ms / 3600000) heures, ce qui explique comment Enterprise, dont la cible est 30 minutes, se voit accusé réception avec la chaîne "1 hours". Et sla.breached n'est positionné que par ticket_auto_close_sweep, dont la requête renvoie les tickets inactifs depuis plus de 24 heures, donc une cible de 30 minutes, 2 heures ou 4 heures ne peut jamais être signalée dans sa propre fenêtre. La fermeture automatique elle-même est désactivée par défaut.
- En marge : le price_note annonçant "100 $/mois + 2 % de l'usage Xuda mensuel", 5 pour cent sur Business et 7 pour cent sur Enterprise, n'est lu par aucun fichier dans cpi, dashboard, shared ou website-nuxt, et rien ne calcule ni ne facture de pourcentage. Le support ne porte aucun member_price_id, donc la remise membre de 10 pour cent ne l'atteint pas. Aucune page publique ne vend l'échelle. Et le panneau des articles populaires interroge un type de document qu'aucun fichier de ce dépôt n'écrit.
Les questions qu'une page de support laisse habituellement de côté
Six réponses lues dans config.json, http_module, app_module et ticket_module, plutôt que sur la fiche tarifaire.
La démonstration, et une règle pour la regarder.
Là où l'enregistrement vidéo et cette page divergent sur un chiffre, un canal ou un temps de réponse, c'est la page qui fait foi, car elle est construite à partir du code source. Chaque chiffre ci-dessus a été lu en août 2026 dans la copie du dépôt de config.json et dans cpi/http_module, cpi/app_module et cpi/ticket_module, sans être repris d'une formulation antérieure. Cette règle compte davantage ici que sur une page consacrée à un écran, car l'essentiel de ce que rapporte cette page est une absence : une barrière de plan jamais évaluée côté serveur, un panneau de chat qui n'écrit aucun document, des sujets préchargés dont l'action_id est null, un indicateur de non-respect qui ne peut jamais se déclencher dans sa propre fenêtre. Un enregistrement vidéo ne peut pas montrer une absence. Il peut montrer l'écran où le cadenas est dessiné, ce qui est la partie de l'échelle qui fonctionne réellement.
Ouvrez un ticket, puis lisez l'enregistrement qu'il a écrit.
La première issue est l'écran de support du dashboard. Choisissez un sujet, un sous-sujet et le détail de troisième niveau, remplissez le formulaire et soumettez. Cela écrit un document de ticket avec une référence commençant par XD, une cible de première réponse si votre palier en porte une, un accusé de réception pour vous et un avis pour l'unique compte du bureau, et hormis le formulaire d'appel, c'est le seul chemin de cet écran qui écrit quoi que ce soit. Lisez la ligne qu'il crée dans Tickets : la référence, la cible, l'assignee null. Tout ce qui précède se vérifie là en environ une minute. La seconde issue est l'écran des plans, où le support s'achète comme sa propre catégorie, aux côtés de l'abonnement et d'AI Workspace, et atterrit comme une troisième ligne sur un abonnement unique consolidé. Rendez-vous-y en sachant ce que les quatre paliers changent : une chaîne de réponse qui devient une seule échéance en temps écoulé, une liste de canaux qui dessine ou retire un cadenas dans le dashboard, et rien côté serveur. Le tableau public des tarifs porte une seule ligne de niveau Support et ne vend l'échelle en rien.