Soporte al cliente para empresas de software y SaaS

El soporte al cliente para empresas de software es el trabajo de responder las dudas de uso de un producto digital, recibir los errores que encuentran sus clientes y avisarles cuando quedaron corregidos. La tercera parte es la que más se olvida. Quien reportó un bug en marzo y nunca supo que se arregló en abril sigue convencido de que el producto falla.

En una tienda o una clínica, quien atiende puede resolver casi todo lo que entra. En una empresa de software, una parte de los tickets la cierra alguien que programa, y el soporte se juega en ese traspaso: con qué datos llega el error a desarrollo, quién decide qué se arregla primero y cómo vuelve la respuesta al cliente que esperaba.

Melonhelp nació dentro de una empresa de software. Empezó como una integración de Slack a la medida de Rocketbot, la plataforma latinoamericana de RPA, y Rocketbot sigue dando soporte a sus propios clientes por Slack sobre Melonhelp. Si tus clientes escriben por correo y no por Slack, cambia el canal y el proceso se mantiene.

Siete tipos de pedido y quién cierra cada uno

Los mensajes que recibe una empresa de software caen en una de estas filas. Cada una tiene otro responsable y exige otros datos, y separarlas desde que entran ahorra idas y vueltas:

En Melonhelp, cada fila puede ser una categoría con sus palabras en la descripción (“factura, cobro, tarjeta” para facturación; “api, token, webhook” para integraciones). Con la clasificación automática encendida, el ticket entra ya clasificado por coincidencia de palabras, sin IA y sin costo extra, y en los reportes del mes ves cuánto del volumen fueron dudas que una guía habría evitado y cuánto fueron errores. Para ordenar la cola dentro de cada tipo, los criterios están en cómo priorizar tickets de soporte.

El calendario de un software: versiones, incidentes y cierres de mes

El volumen de soporte de un producto digital sube con el calendario del propio producto y de sus clientes:

• La mañana después de cada versión. Lo que se desplegó a las 18:00 se reporta a las 9:00. Desplegar un viernes en la tarde traslada ese pico al lunes, cuando el equipo recién llega y los reportes del fin de semana ya están esperando.
• Un incidente. Si algo se cae, entran decenas de mensajes iguales en pocos minutos, por todos los canales a la vez.
• El primer mes de cada cliente nuevo. La implementación concentra las dudas de uso. Si cierras varias cuentas grandes el mismo mes, ese mes las dudas se suman.
• Los primeros días del mes, si tu producto toca facturación, sueldos o contabilidad. El cliente necesita cerrar el mes y cualquier falla choca con un plazo tributario o de pago de remuneraciones que no depende de ti.
• Enero y febrero en el Cono Sur. Buena parte del equipo en Chile, Argentina o Uruguay toma sus vacaciones de verano mientras los clientes de México o Colombia trabajan como cualquier otro mes.

Entre septiembre y abril, Chile continental usa el horario de verano (UTC-3) y Ciudad de México está en UTC-6 todo el año, porque México dejó el horario de verano en 2022. Un equipo en Santiago que atiende hasta las 18:00 deja a sus clientes mexicanos sin respuesta desde las 15:00 de allá. Si tus SLA se miden en horas hábiles, decide de quién son esas horas y escríbelo en el contrato.

Para el incidente, Melonhelp tiene el Aviso general, en Comunicaciones, Respuestas automáticas. Lo activas con un texto como “Detectamos una falla en la exportación desde las 9:00 y ya estamos trabajando; te avisamos por este mismo medio cuando quede resuelta”, y el aviso sale una sola vez en cada ticket, por el mismo canal por el que llegó el reclamo. Con el aviso encendido, la IA no contesta. En Slack hay un matiz: el aviso solo contesta los mensajes que ya son tickets. Para llegar a todos tus canales de clientes, usa Comunicaciones, que publica un mensaje en cada canal de un grupo. El resto del proceso, desde el diagnóstico hasta el cierre, está en gestión de incidencias en una empresa.

Slack para las cuentas grandes, correo para el resto

Muchos clientes empresa de un software B2B trabajan en Slack y prefieren un canal compartido con su proveedor antes que un formulario. Ese canal de Slack Connect tiene una condición: según la guía de Slack Connect, cada organización del canal tiene que estar en un plan pagado de Slack. Con cuentas grandes eso ya está resuelto. Con cien clientes chicos, no, y para ellos el correo o WhatsApp funcionan mejor.

En Melonhelp, un mensaje del canal se vuelve ticket cuando alguien lo marca: mencionando a @Melonhelp, reaccionando con 🎟️ o 🎫, con el atajo Crear ticket o con /autoticket. Lo que tu equipo responde desde el ticket aparece en el hilo de Slack, y lo que el cliente contesta en el hilo se suma al ticket. En la configuración de Slack dentro de Melonhelp, los canales compartidos aparecen marcados y puedes agruparlos (por ejemplo, “Clientes”) para mandarles un mismo mensaje desde Comunicaciones. Melonhelp no copia los archivos adjuntos: se quedan en Slack.

Cómo ordenar un canal por cliente, qué plan pide Slack a cada lado y cómo medir por cuenta está en soporte a clientes por Slack Connect, y la historia de Rocketbot, en Rocketbot y Melonhelp.

Lo que cruza de soporte a desarrollo, y lo que vuelve

En el traspaso entre soporte y desarrollo los casos se pierden con facilidad. Un bug que llega a desarrollo como “a un cliente no le funciona exportar” vuelve con otra pregunta; uno que llega con versión, pasos y hora se puede reproducir esa misma mañana. Estas reglas sostienen el traspaso en un equipo chico:

• Soporte reproduce antes de escalar. Si no puede, pide al cliente lo que falta antes de mover el ticket.
• Un error entra a desarrollo una vez, aunque lo reporten diez clientes. Cada cliente conserva su ticket, porque son conversaciones distintas, y todos apuntan al mismo caso.
• El ticket que espera a desarrollo pasa a un estado propio, como “Esperando desarrollo”, para que nadie lo lea como abandonado. En Melonhelp los estados se personalizan por espacio de trabajo.
• El orden lo ponen los usuarios afectados y lo que pagan las cuentas que lo piden. El cliente que más insiste no define la prioridad.
• Una persona de desarrollo hace guardia de soporte por semana, en rotación. Como Melonhelp cobra por volumen de tickets y no por agente, sumarla a Tickets no agrega un asiento.

Un límite de hoy: Melonhelp Tickets no crea un issue de GitHub ni de Jira desde un ticket. La integración con GitHub está en el roadmap, y mientras tanto el enlace al issue va en una nota interna del ticket. Si tu equipo técnico quiere automatizarlo, los webhooks de Tickets avisan cuando un ticket se crea, se asigna, se cierra, se reabre o recibe un comentario. Si tu proceso depende de enlazar cada solicitud con un issue de Jira desde el primer día, Jira Service Management ya trae ese enlace entre solicitudes e issues; la comparación está en Melonhelp vs Jira Service Management.

Errores que llegan solos al equipo de producto

Muchos errores nunca llegan a soporte: el cliente se frustra, recarga la página y sigue. Para esos casos está Melonhelp Feedback, un producto aparte de Tickets. Su SDK se instala con una línea en tu app y hace tres cosas: pone un botón para enviar ideas y errores con captura de pantalla, captura los errores no controlados (en silencio o preguntándole al usuario si quiere reportarlo) y los agrupa, con la página, la versión, los pasos previos y cuántos usuarios los sufrieron. Antes de guardarlos borra correos, tokens, contraseñas y números con forma de tarjeta. Si un error vuelve después de resolverlo, se reabre como regresión.

Los pedidos de funciones van a un portal con votos y roadmap. Si tu app identifica a cada usuario con un token firmado, puedes enviar su plan y su MRR, y ordenar los pedidos por los ingresos de quienes los piden. Cuando un cliente pide algo por un ticket, soporte lo registra en la Bandeja de Feedback, con el botón Nueva y el correo del cliente, que queda como autor. El aviso por correo le llega si esa dirección ya está verificada en tu portal, por ejemplo porque tu app lo identifica.

La otra mitad es para quien programa. Feedback tiene un servidor MCP remoto con OAuth: pegas su URL en Claude Code, Codex, Cursor u otro cliente compatible, autorizas con tu cuenta de Melonhelp y el agente puede leer los errores ordenados por usuarios afectados. Si tu rol es de owner o administrador, también puede tomarlos, enlazar el arreglo y marcarlos resueltos. No puede borrar nada ni ver secretos, sus respuestas públicas esperan la aprobación de una persona, y lo que escribieron tus usuarios le llega marcado como contenido no confiable, para que lo lea como datos y no como órdenes.

Tickets tiene su propio conector MCP, de solo lectura: lista tickets, abre uno y lee su hilo (cómo conectarlo). Con los dos conectados, el agente que arregla un error puede leer también lo que el cliente le contó a soporte. En los planes pagados, Feedback se conecta con GitHub y el pull request que cierra una publicación la avanza sola; Slack y Linear todavía no están disponibles. La lista completa de herramientas está en la documentación del MCP de Feedback, y cómo se compara Feedback con otras opciones, en herramientas de feedback de usuarios.

La versión 4.12, del primer reporte al aviso

Un ejemplo con una empresa inventada: un software de inventario para distribuidoras, con 70 empresas clientes en Chile, Perú y México. Las cuentas grandes escriben por Slack Connect y el resto, a soporte@. Usa Melonhelp Tickets y Feedback. Así se ve un bug de punta a punta con lo que hoy permiten los dos productos:

Dos pasos siguen siendo manuales: enlazar los tickets con el caso de Feedback y responderles a los clientes que escribieron por Slack o por correo. Feedback les escribe a quienes reportaron desde la app; quien solo habló con soporte se entera por su ticket. El cierre por versión desplegada depende del plan de Feedback. Si tu plan no lo incluye, el aviso sale en el momento en que marcas el caso como resuelto, así que márcalo con el arreglo ya en producción.

Qué contesta un agente de IA con tu documentación

MIA es un agente de Melonhelp Agents que responde dentro de Tickets, en el mismo hilo de Slack o en el mismo correo, con lo que le cargaste en Agents: tu centro de ayuda, la referencia de la API, páginas web, PDFs y preguntas frecuentes. En el soporte de un software, eso alcanza para una franja clara:

• Cómo se usa una función, con el enlace a la guía.
• Qué significa un mensaje de error que está documentado y qué hacer con él.
• Cómo autenticarse en la API, qué límites tiene y qué devuelve un endpoint.
• Pedir la versión, el navegador y los pasos antes de pasar un posible bug a una persona, si se lo indicas en sus instrucciones.
• Responder a las 23:00 lo que mañana a las 9:00 sería la misma respuesta.

Y hay otra franja que siempre toma una persona:

• Confirmar si algo es un bug y cuándo se arregla. El agente responde con lo que le cargaste, no con tu código ni con tu tablero de trabajo.
• Prometer fechas o funciones del roadmap.
• Excepciones de cobro, devoluciones, descuentos y bajas de cuentas que pagan.
• Cuestionarios de seguridad, acuerdos de tratamiento de datos y cualquier pregunta que compromete a la empresa por contrato.
• Un incidente en curso. Con el Aviso general activo, la IA no responde.

El traspaso es automático. Si la respuesta no está en su conocimiento, MIA deja de contestar en ese ticket, se lo pasa a quien corresponde según tus reglas de asignación y el equipo recibe el aviso con la conversación completa. Cuando alguien del equipo responde, MIA se calla en ese ticket, y puedes volver a encenderla ahí si quieres. Las preguntas que no supo contestar quedan en Knowledge gaps, dentro de Agents, con un contador, y responderlas ahí las suma a su conocimiento. Los criterios para decidir qué escala están en cuándo un agente de IA debe escalar a un humano.

MIA cuesta US$79 al mes fijo en cualquier plan de Tickets y no cobra por resolución. Para usarla necesitas un plan de Melonhelp Agents con un agente publicado; las conversaciones que responde se descuentan de ese plan.

Datos de tus clientes dentro de un ticket: Chile y México

Una empresa de software que guarda datos de los clientes de sus clientes trata esos datos por cuenta de otro, y para la ley suele ser un encargado del tratamiento. En soporte esos datos aparecen todo el tiempo: la captura de pantalla con la lista de pacientes de una clínica, la planilla de clientes que adjuntan para reproducir una importación fallida, el acceso a una cuenta para revisar un reporte. Esto es una guía de operación, no asesoría legal.

En Chile, la Ley 21.719 entra en vigencia el 1 de diciembre de 2026. Su artículo 15 bis obliga al encargado a tratar los datos conforme al encargo y a las instrucciones del responsable, sin usarlos para otros fines ni cederlos sin autorización. El artículo 14 sexies obliga al responsable (tu cliente) a reportar a la nueva Agencia de Protección de Datos Personales las vulneraciones de seguridad que pongan en riesgo a los titulares, por los medios más expeditos y sin dilaciones indebidas. Si la filtración ocurre en tu sistema, tu cliente solo puede reportarla a tiempo si tú le avisas primero.

En México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares de 2025 define a la persona encargada en su artículo 2 (fracción XII). El artículo 19 obliga al responsable a informar de forma inmediata a los titulares las vulneraciones que afecten sus derechos de forma significativa, y el artículo 20 pide controles para que todas las personas que intervienen en el tratamiento guarden confidencialidad, incluso después de terminada su relación.

Llevado a la bandeja de soporte:

• Pide capturas con los datos personales tapados y, si necesitas un archivo, que traiga solo las filas que fallan.
• Nunca pidas una contraseña por ticket. Si alguien de soporte entra a la cuenta del cliente, que el permiso quede escrito en el mismo ticket.
• En Melonhelp, los adjuntos de Slack se quedan en Slack y no se copian al ticket. Los errores que captura Feedback llegan con correos, tokens y números de tarjeta ya borrados.
• Un ticket que revela una posible filtración deja de ser un ticket de soporte. Pasa al proceso de incidentes, con alguien que pueda decidir si hay que reportar.

Argentina, Brasil y el resto de la región, junto con lo que cambia al usar IA, están en agentes de IA y protección de datos en LatAm.

Cómo se entera cada cliente del arreglo

Un arreglo que nadie anuncia no le cambia la opinión a quien sufrió el error. Cada grupo de clientes se entera por un lugar distinto: quien escribió a soporte, por la respuesta en su ticket; quien reportó o votó en Feedback, por el correo que sale al resolver; el resto, por la entrada del changelog, la pestaña Novedades del botón dentro de tu app y, si atiendes por Slack, un mensaje desde Comunicaciones a tus canales de clientes. Cómo escribir esas entradas para que alguien las lea está en changelog: qué es y cómo avisar a tus usuarios, y cómo decidir qué entra al roadmap con los votos en la mano, en roadmap público con votación.

Lo que paga un equipo de software, y cuándo elegir otra herramienta

Un ejemplo, con los precios vigentes en octubre de 2026: dos personas en soporte, seis desarrolladores que rotan la guardia y unos 600 tickets al mes. En Melonhelp eso cabe en Equipo, que cuesta US$70 al mes y llega a 1.000 tickets, con SLA en horario hábil, reportes y las ocho personas incluidas. El plan Esencial, de US$29 hasta 250 tickets, trae Slack, correo y WhatsApp, pero no SLA. MIA agrega US$79 al mes fijos, más el plan de Agents que elijas. Para Tickets no existe plan gratis; la prueba, de 14 días, se activa sin tarjeta. Feedback y Agents, en cambio, se pueden usar gratis. El detalle está en precios.

Melonhelp no es la mejor opción si:

• Tu ingeniería vive en Jira y necesitas que cada solicitud quede enlazada a su issue desde hoy. Jira Service Management ofrece ese enlace con Jira.
• Tu soporte es sobre todo chat dentro de la app, con mensajes de bienvenida y recorridos guiados. Esa es la especialidad de herramientas como Intercom.
• Tus contratos fijan un SLA distinto por cliente. En Melonhelp los SLA se definen por prioridad, no por cuenta.
• Tus incidentes generan cientos de tickets duplicados que quieres fusionar. La fusión de tickets todavía está en el roadmap.

Si estás eligiendo entre varias apps que atienden por Slack, la comparación con precios por agente está en apps de tickets para Slack comparadas.

Preguntas frecuentes