# Qué revisar en el soporte de una plataforma IoT antes de firmar > El soporte es lo que de verdad compras una vez que los dispositivos están en campo. Cómo probar quién responde, los niveles de severidad, la ayuda con la decodificación, la documentación y el soporte al revendedor durante la prueba. ![Qué revisar en el soporte de una plataforma IoT antes de firmar](https://tago.io/og/es/blog/iot-platform-support-before-you-sign.png) Casi todas las evaluaciones de plataforma siguen el mismo patrón. Una hoja de cálculo con una fila por función, una fila por límite, una fila para el precio y, cerca del final, una fila llamada "soporte" con valores como "email" o "24/7" copiados de la tabla de planes. Las funciones y el precio merecen esa atención; la [guía del comprador](https://tago.io/blog/iot-platform-buyers-guide) las cubre bien. El soporte se queda con una sola fila porque nadie sabe cómo evaluarlo desde fuera y, durante la prueba, todavía no se ha roto nada. Después los dispositivos salen a campo. Ocho meses más tarde, una actualización de firmware del gateway cambia el formato de un payload y 300 sensores empiezan a escribir basura a las 2 de la mañana de un sábado. En ese momento la lista de funciones no importa. Lo que estás comprando es quién responde, con qué rapidez y si esa persona entiende la capa de dispositivo o solo la plataforma. El soporte que recibes en esa hora quedó decidido por cosas que la página de precios nunca te mostró: quién atiende la cola, qué significa "respuesta" en cada nivel de severidad y si puedes resolverlo por tu cuenta cuando no hay nadie despierto. Este post trata de averiguar esas cosas durante la prueba, mientras todavía te queda tiempo y puedes elegir. ![El soporte que ves frente al soporte que recibes: frases de la tabla de planes como soporte por email, 24/7, tiempo de respuesta de 4 horas, soporte de plataforma, documentación y programa de partners, cada una asociada a la pregunta que decide el resultado a las 2 de la mañana, desde quién lee el ticket hasta si puedes escalar los problemas de tus clientes](https://tago.io/images/blog/iot-platform-support-before-you-sign/support-you-see-vs-support-you-get.svg) ## Quién responde y qué sabe El "soporte 24/7" describe un horario, no una capacidad. La pregunta que importa es qué sabe la persona que lee tu ticket. Hay una distancia enorme entre un primer nivel que clasifica tickets y pide capturas de pantalla, y un ingeniero que ha construido sobre la plataforma y puede leer tu código de Payload Parser. La prueba: durante la evaluación, abre un ticket real con un problema técnico real. Una pregunta de decodificación funciona bien. Envía un payload en crudo, tu código del parser y la salida incorrecta. Después observa. Una primera respuesta que pregunta qué navegador usas dice una cosa. Una primera respuesta que detecta el error en el desplazamiento de bytes dice otra. Mide el tiempo hasta la primera respuesta y el tiempo hasta una respuesta útil; son números distintos, y con el segundo es con el que vas a convivir. Pregunta sin rodeos si el soporte lo atienden los ingenieros del propio proveedor o un nivel tercerizado, y si quienes responden pueden llegar a quienes escriben la plataforma. Quieres un sí a lo segundo, aunque la respuesta a lo primero sea mixta. ## Compromisos de respuesta por severidad, por escrito La mayoría de las tablas de planes indican un único tiempo de respuesta, o ninguno. Los incidentes no son todos del mismo tamaño. Un widget de dashboard que se muestra mal no es lo mismo que la ingesta de datos caída para todos los dispositivos en la sede de un cliente, y un modelo de soporte que los trata igual promete demasiado en lo pequeño o se queda corto en lo grande. Lo que quieres es una escala de severidad: la definición de cada nivel, el compromiso de respuesta de cada uno, el horario en que aplica y el canal que usas. Pide por escrito la ruta de escalamiento: quién entra cuando el primer nivel se atasca y cómo lo activas tú. Un proveedor que no puede describir su escalamiento no lo tiene; tiene una cola. No aceptes un "normalmente respondemos en menos de una hora". Normalmente no es un compromiso, y el incidente que te cuesta un cliente es, por definición, inusual. ## Ayuda con la plataforma frente a ayuda con el dispositivo Aquí es donde el soporte IoT decepciona casi siempre. El proveedor de la plataforma da soporte a la plataforma. Tu problema vive en el dispositivo: un uplink LoRaWAN en un puerto inesperado, un mapa de registros Modbus desplazado en uno, un decodificador que funcionaba con el firmware 2.1 y se rompe con el 2.3. Los proveedores trazan la línea del soporte en el límite de la API, y todo lo que queda debajo pasa a ser "problema del fabricante de tu dispositivo". Averigua dónde está la línea antes de necesitarla. En TagoIO, la capa de dispositivo es parte del producto: los [Connectors y Networks](https://docs.tago.io/docs/tagoio/devices/payload-parser/connector/connector-overview) decodifican payloads de modelos de sensores publicados, y el [Payload Parser](https://docs.tago.io/docs/tagoio/devices/payload-parser/parser-vs-analysis-comparison) es el sitio previsto para arreglar la decodificación, así que una pregunta sobre el decodificador queda dentro del alcance y no fuera. Sea cual sea la plataforma que evalúes, haz la pregunta directa: "Si mi parser produce valores incorrectos, ¿van a revisar el parser?" ## ¿Puedes resolverlo por tu cuenta a medianoche? Los tickets de soporte son el camino lento. El camino rápido es la documentación (TagoIO publica la suya en docs.tago.io), y su calidad decide cuántos tickets vas a necesitar de entrada. Durante la prueba, sáltate la guía de inicio. Lee la documentación de tu caso de uso exacto: el tipo de Action que piensas usar, el disparador de Analysis que necesitas, la forma de la política de Access Management para tus clientes. Si los docs responden la pregunta que de verdad tienes, con un ejemplo que funciona, la mayoría de las noches no vas a abrir tickets. Más verificaciones de autoservicio: - Una página de estado pública con historial. Un punto verde no alcanza; quieres el registro de los incidentes pasados, cómo se comunicaron y cuánto duraron. TagoIO publica la suya en status.tago.io. - Una comunidad donde otros integradores responden. La de TagoIO está en community.tago.io. Lee las preguntas sin responder con la misma atención que las respondidas; la proporción te dice qué tan viva está. ## Qué pasa cuando revendes Si eres un integrador de sistemas y pones a tus propios clientes en un portal de TagoRUN, la pregunta del soporte se duplica. Tus clientes te llaman a ti, no a la plataforma. Eres la primera línea, lo hayas planeado o no, y el proveedor de la plataforma es tu segunda línea. Eso cambia lo que necesitas de ellos. Pregunta: ¿puedo abrir un ticket por el problema de un cliente y que lo traten como mío? ¿Los Profiles que administro para clientes tienen el mismo nivel de soporte que los míos? Cuando le prometo a mi cliente un tiempo de respuesta, ¿qué tiempo de respuesta me dan ustedes para respaldarlo? La diferencia entre esos dos números es tu riesgo, y no se cierra con buena voluntad. El artículo sobre [qué incluir en un SLA de reventa](https://tago.io/blog/sla-reselling-iot-platform) explica cómo estructurar la promesa; aquí el punto es conseguir el número de arriba antes de escribir el de abajo. ## Confirma qué incluye de verdad tu plan Los niveles de soporte suelen seguir a los niveles de plan, y tu evaluación se ejecuta en el nivel que el proveedor eligió para las pruebas. Antes de firmar, nombra el plan que vas a comprar de verdad y pregunta, por escrito, qué soporte trae: canales, horarios, compromisos por severidad y si el escalamiento existe en ese nivel o solo más arriba. En el caso de TagoIO, los términos vigentes están en la [página de precios](https://tago.io/pricing) y en la [documentación de planes de cuenta](https://docs.tago.io/docs/tagoio/my-account/billing/account-plans); lee la versión publicada el día que firmas, no el resumen de una llamada de ventas. ## El plan de pruebas de la evaluación Haz esto durante la evaluación, no después: - Abre un ticket real con un problema real del payload parser. Registra el tiempo hasta la primera respuesta y el tiempo hasta una respuesta útil. - Lee la documentación de tu caso de uso exacto, no el tutorial. Anota lo que falta. - Lee el historial de la página de estado del último año. - Busca en la comunidad tu modelo de dispositivo y las funciones de las que vas a depender. - Pide por escrito las definiciones de severidad y la ruta de escalamiento. - Pregunta qué incluye el plan que vas a comprar y si el nivel de la prueba era el mismo. - Si revendes, pregunta cómo se manejan los tickets por problemas de tus clientes y qué tiempo de respuesta puedes trasladar. Dos días de este trabajo dicen más sobre los próximos tres años que cualquier comparación de funciones. La plataforma que gana en la hoja de cálculo y pierde el ticket de las 2 de la mañana es la cara, diga lo que diga la fila del precio. ## Recursos - [Guía de compra de plataformas IoT: 10 preguntas que hacer antes de decidir](https://tago.io/blog/iot-platform-buyers-guide) - [Qué incluir en un SLA al revender una plataforma IoT](https://tago.io/blog/sla-reselling-iot-platform) - [Precios de TagoIO](https://tago.io/pricing) [llms.txt](https://tago.io/llms.txt)