Cuatro niveles, rangos de 0 a 3, y un candado en una sola pantalla.
El soporte se vende como cuatro registros PLAN_OBJ en config.json con la categoría "support" y rank de 0 a 3: Starter en 0, Developer en 1, Business en 2, Enterprise en 3. Son registros distintos de los siete registros de membresía, y los cuatro llevan un price_id de Stripe, incluido el nivel gratuito Starter, y por eso el soporte aparece como su propia línea en la única suscripción consolidada, junto a membership y ai_workspace. Lo que los niveles cambian en el código en ejecución es mucho menos de lo que sugiere la tabla. Exactamente una de las 1010 entradas de cpi_methods lleva un min_support_plan: submit_support_ticket, que asigna ticket a starter, chat a business y call a enterprise. Esa es toda la escala en lo que respecta a la plataforma. El control de plan del lado del servidor, isValidPlan en cpi/http_module/index.mjs, lee únicamente cpi_methods[method].min_plan y lo compara con account.membership_plan; nunca lee min_support_plan ni support_plan. La aplicación es, por tanto, un candado del lado del cliente: el panel compara dos rangos en un PLAN_OBJ plano y desactiva un Button. Esta página contrasta los cuatro registros con el código que realmente los consume, sigue un ticket enviado hasta los lugares donde acaba, y termina con una lista clara de lo que se anuncia que hace la escala y lo que no hace.
La escala tal como está escrita, campo por campo.
Cada celda de abajo es el valor literal del registro PLAN_OBJ, no un resumen. Hay dos cosas que conviene leer en horizontal en lugar de en vertical. La fila price_note anuncia un recargo porcentual en los tres niveles de pago, y ningún archivo de cpi, dashboard, shared o website-nuxt lee price_note: nada calcula un porcentaje y nada lo cobra. Y la fila Support Agents lleva exactamente la misma cadena en Developer y en Business, palabra por palabra, así que la mitad de la escala describe al mismo personal dos veces con una diferencia de precio de quince veces. Monitoring es la cadena literal "N/A" en tres niveles; solo Enterprise lleva un texto descriptivo.
Starter | Developer | Business | Enterprise | |
|---|---|---|---|---|
| Precio por mes | 0 US$ | 100 US$ | 1500 US$ | 4500 US$ |
| price_note (no lo lee nada) | none | 100 US$/mo + 2% of monthly Xuda usage | 1500 US$/mo + 5% of monthly Xuda usage | 4500 US$/mo + 7% of monthly Xuda usage |
| Response Time, primera cifra | <72 hr | <4 hr | <2 hr | <30 min |
| Sistema de producción caído | not stated | <1 hr | <30 min | <10 min |
| Cadena Support Channels / array 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 |
Rutas de tema de tercer nivel, ninguna almacenada como documento
Entradas de cpi_methods que llevan un min_support_plan
Rango completo del objetivo de primera respuesta en los cuatro niveles
Id de cuenta en support_team_account_ids, notificada en cada ticket de plataforma
Un método, tres canales, y solo dos de ellos anotan algo.
submit_support_ticket es el único método que la escala de soporte restringe. Rechaza cualquier communication_type distinto de call, ticket y chat con el código -1, y luego delega en ticket_submit, que se encarga de la titularidad, los temas, las acciones, el SLA y las notificaciones. Las tres ramas de abajo son lo que alcanza realmente cada canal. Dos de ellas crean un documento de ticket en la mesa de la plataforma. La del medio, lo que compra Business, nunca llama a este método.
Cuatro registros, una declaración y una cadena que termina en el navegador.
El soporte es su propia escala en PLAN_OBJ, no un campo de su membresía. Cuatro registros llevan la categoría "support" y rank de 0 a 3: Starter 0, Developer 1, Business 2, Enterprise 3, separados de los siete registros de membresía (free, pro, team, agency y enterprise_t1, t2 y t3). Lo que cambia un nivel es más estrecho de lo que sugiere la tabla, y los puntos de abajo dicen cuánto: un método de 1010 declara un mínimo de soporte, y la comparación que lo aplica se ejecuta en el navegador, sobre un Button.
- La escala tiene precios de 0, 100, 1500 y 4500 al mes, y los cuatro niveles llevan un price_id de Stripe, incluido el nivel gratuito Starter. Por eso el soporte aparece como su propia línea en la única suscripción consolidada, junto a membership y ai_workspace.
- El mínimo se declara una sola vez. Exactamente una de las 1010 entradas de cpi_methods lleva min_support_plan: submit_support_ticket, que asigna ticket a starter, chat a business y call a enterprise, con clearance user y private true. Nada más lleva un mínimo de soporte, así que leer tickets, responder, reabrir, adjuntar archivos y cerrar quedan fuera de la escala.
- Lo que cambia de forma visible son tres cadenas. features["Response Time"] dice "<72 hr", luego "<4 hr, Production system down: <1 hr", luego "<2 hr, Production system down: <30 min", y luego "<30 min, Production system down: <10 min". Support Channels dice Email, Email, "Email, Chat", "Email, Chat, Call". Monitoring es la cadena literal "N/A" en tres niveles, y solo Enterprise lleva un texto descriptivo sobre detección y respuesta ante incidentes.
- Dos campos de esos registros son decorativos. Cada nivel lleva un array channels (ticket, luego ticket y chat, luego ticket, chat y call) que ningún archivo de cpi, dashboard, shared o website-nuxt lee: el mapa de canales real vive en cpi_methods. Los niveles de pago llevan un price_note que anuncia "$100/mo + 2% of monthly Xuda usage", 5% en Business y 7% en Enterprise, y un grep en todo el repositorio devuelve la configuración y nada más. Nada calcula ni cobra un porcentaje.
- config.json lo declaramin_support_plan en submit_support_ticket, la única entrada de 1010 que lo tiene
- get_metrics lo publicaapp_module copia el mínimo al cliente junto a min_plan, incluso para métodos privados cuya descripción y campos se ocultan
- El Button compara rangosisFeatureUnlocked lee USER_DATA.support_plan, isValidPlan compara el rank en el PLAN_OBJ plano, y Chat o Call se renderizan con un candado
- El salto en el servidor que no existeisValidPlan de http_module solo lee min_plan frente a membership_plan, y ticket_module nunca lee support_plan
Qué aspecto tiene realmente un ticket enviado.
Por cada envío llega un documento a xuda_tickets. Vale la pena leer con atención tres campos. first_response_due_ts es el único plazo que fija la plataforma, y se fija solo para los tickets de plataforma, ya que una mesa de cliente no tiene un plan de soporte que leer. resolve_due_ts está en el mismo bloque y nada lo escribe nunca. Y los dos campos que harían que un ticket avanzara por sí solo, action_id y assignee, son ambos null en el momento en que se crea.
Ocurren tres cosas cuando pulsa Enviar.
submit_support_ticket es una capa fina. Rechaza cualquier communication_type distinto de call, ticket y chat con el código -1, incorpora la elección terciaria al cuerpo y entrega todo a ticket_submit, que se encarga de la titularidad, los temas, las acciones, el SLA y las notificaciones. Lo que sigue es esa función, en orden.
- 01
La mesa, el contacto y el número
Siete de las diez fuentes de ticket declaradas son fuentes de plataforma, y una fuente de plataforma siempre resuelve el tenant a support_team_account_ids[0] sea cual sea lo que pase quien llama, así que un cliente no puede registrar en la mesa de Xuda bajo su propio tenant ni al revés. A quien solicita se le asocia con un contacto bajo ese perfil de tenant, y se genera una referencia desde un documento contador por tenant: XD-000001 en la mesa de la plataforma, TK en una mesa de cliente.
- 02
El documento y la primera interacción
El ticket se escribe en xuda_tickets, y después el propio envío se registra como la interacción uno, con dirección entrante, desde quien solicita, visibilidad pública, y llevando su texto y los archivos adjuntos. El tema se busca por id o por nombre entre los documentos ticket_topic creados en la siembra, y un tema desconocido no se rechaza: el ticket llega sin clasificar en lugar de perderse.
- 03
Dos notificaciones y ninguna asignación
Quien solicita recibe ticket_opened_customer, que muestra el objetivo como Math.round(response_ms / 3600000) horas, así que un ticket de Enterprise con un objetivo de 30 minutos se confirma con la cadena "1 hours". Después sale un aviso ticket_opened_agent por cada uid en support_team_account_ids, y ese array contiene exactamente un id, idéntico a auto_reply_account_id. No se dispara nada más: assignee sigue siendo null, y la fase de acciones se omite porque no hay ningún action_id que disparar.
Diez temas, 146 subtemas y 414 cadenas que nunca se guardan.
config.support tiene exactamente tres claves: auto_reply_account_id, support_team_account_ids y ticket_topics. La tercera tiene tres niveles de profundidad, y solo dos de esos niveles se convierten en documentos: _tk_seed_platform_topics escribe un documento ticket_topic por tema con los subtemas incrustados en él, y el tercer nivel se queda donde estaba. Los diez temas se agrupan abajo según de qué tratan, con lo que aporta cada uno y dónde acaba una elección en el ticket terminado.
Nueve cosas que la escala de soporte no hace, incluida aquella con la que se vende.
- No se aplica en el servidor en ninguna parte. El control de plan es isValidPlan en cpi/http_module/index.mjs, líneas 542 a 547, llamado en la línea 868, y lee exactamente un campo, cpi_methods[method].min_plan, comparado con account.membership_plan. Nunca lee min_support_plan ni support_plan, y ticket_module nunca lee un plan de soporte para autorizar. El bloqueo de canal es un candado dibujado sobre un Button, y detrás no hay nada.
- Restringe un método de 1010. submit_support_ticket es la única entrada de cpi_methods que lleva min_support_plan. Leer sus tickets, responder a uno, reabrirlo, adjuntar un archivo, cerrarlo: ninguno lleva un mínimo de soporte. La escala decide cuál de tres botones no está desactivado en una pantalla, y ahí se acaba.
- min_support_plan tiene dos lectores en todo el repositorio, y ninguno es una comprobación. app_module lo publica al cliente dentro de get_metrics, y SupportForm.vue lo pasa a una prop de Button. Nada en ticket_module lo consulta, así que una cuenta Starter que envía communication_type "call" es aceptada: el método solo rechaza un valor fuera de call, ticket y chat, con el código -1, y después delega.
- PLAN_OBJ lleva además un array channels en cada registro de soporte: ticket, luego ticket y chat, luego ticket, chat y call. Ningún archivo de cpi, dashboard, shared o website-nuxt lee PLAN_OBJ.channels. El mapa de canales real vive en cpi_methods, que es el único punto donde ambos podrían discrepar sin que nada lo notara.
- "Limited selection" y "Open selection" describen una restricción de temas que no existe. Ambas son cadenas de visualización en PLAN_OBJ features.support, y sus únicas apariciones fuera de config.json son la tabla de precios pública y dos composables de explore. SupportForm.vue renderiza todas las claves de _CONF.support_ticket_topics sin ningún filtro por plan, así que los 10 temas y los 146 subtemas aparecen igual en free y en enterprise_t3.
- El chat, lo que compra Business, sale de la plataforma. El panel restringido a Business es un iframe de tawk.to fijo en el código y sin botón de envío, así que submitRequest nunca se ejecuta para él. No se crea ningún documento de ticket, ningún ticket_no, ninguna interacción, ninguna transcripción en Tickets ni ningún SLA para una conversación de chat. De los tres canales, solo ticket y call escriben algo.
- El enrutamiento por tema no enruta. _tk_seed_platform_topics escribe los 10 temas de plataforma y sus subtemas incrustados con action_id: null, _tk_resolve_action_id devuelve entonces null cuando ninguno de los dos niveles lleva uno, assignee es null al crearse, nada asigna automáticamente y cada ticket de plataforma notifica al mismo y único id de cuenta. Solo dos de los tres niveles de tema llegan a ser documentos: las 414 cadenas de tercer nivel nunca se guardan, y la elegida se añade al cuerpo como una línea que dice "Detail: <value>".
- El SLA es un solo número, y es el más laxo. _tk_response_ms toma el primer número y unidad de la cadena Response Time, así que la mitad relativa a producción caída de cada nivel de pago nunca se convierte en un plazo. El objetivo almacenado es tiempo transcurrido sin más, fines de semana incluidos, y el correo de acuse imprime Math.round(response_ms / 3600000) horas, que es como Enterprise, cuyo objetivo son 30 minutos, acaba confirmado con la cadena "1 hours". Y sla.breached solo lo fija ticket_auto_close_sweep, cuya consulta devuelve tickets inactivos durante más de 24 horas, así que un objetivo de 30 minutos, 2 horas o 4 horas nunca puede marcarse dentro de su propia ventana. El cierre automático se entrega desactivado por defecto.
- En los márgenes: el price_note que anuncia "$100/mo + 2% of monthly Xuda usage", 5 por ciento en Business y 7 por ciento en Enterprise, no lo lee ningún archivo de cpi, dashboard, shared o website-nuxt, y nada calcula ni cobra un porcentaje. El soporte no lleva member_price_id, así que el descuento del 10 por ciento para miembros no le alcanza. Ninguna página pública vende esta escala. Y el panel de Artículos populares consulta un tipo de documento que nada en este repositorio escribe.
Las preguntas que una página de soporte suele omitir
Seis respuestas leídas en config.json, http_module, app_module y ticket_module en lugar de en la ficha del plan.
El recorrido guiado, y una regla para verlo.
Cuando la grabación y esta página discrepen sobre una cifra, un canal o un tiempo de respuesta, la página es la que está construida a partir del código fuente. Cada cifra de arriba se leyó en agosto de 2026 en la copia del repositorio de config.json y en cpi/http_module, cpi/app_module y cpi/ticket_module, no se arrastró de una redacción anterior. Esa regla importa aquí más que en una página sobre una pantalla, porque casi todo lo que informa esta página es una ausencia: un control de plan que nunca se evalúa en el servidor, un panel de chat que no escribe ningún documento, temas sembrados cuyo action_id es null, una marca de incumplimiento que no puede dispararse dentro de su propia ventana. Una grabación no puede mostrar una ausencia. Sí puede mostrar la pantalla donde se dibuja el candado, que es la parte de la escala que sí funciona.
Registre un ticket y después lea lo que quedó anotado.
La primera salida es la pantalla de soporte del panel. Elija un tema, un subtema y el detalle de tercer nivel, complete el formulario y envíelo. Eso escribe un documento de ticket con una referencia que empieza por XD, un objetivo de primera respuesta si su nivel lo incluye, un acuse para usted y un aviso a la única cuenta de la mesa, y aparte del formulario de llamada es la única ruta de esa pantalla que escribe algo. Lea la fila que crea en Tickets: la referencia, el objetivo, el assignee nulo. Todo lo anterior se puede comprobar ahí en cosa de un minuto. La segunda salida es la pantalla de planes, donde el soporte se compra como su propia categoría junto a la membresía y AI Workspace, y aparece como una tercera línea en una única suscripción consolidada. Vaya allí sabiendo qué cambian los cuatro niveles: una cadena de respuesta que se convierte en un plazo de tiempo transcurrido, una lista de canales que dibuja o quita un candado en el panel, y nada en el servidor. La tabla de precios pública lleva una sola fila de nivel de soporte y no vende la escala en absoluto.