Castro Podcasts: por qué salió mal el intento de construir relaciones mediante soporte al cliente

• Tras adquirir Castro, intentaron diferenciarse con soporte centrado en personas, usando el producto todos los días y respondiendo todos los correos, pero eso no se tradujo en la lealtad ni la simpatía de los clientes que esperaban
• La satisfacción era alta cuando podían dar una solución inmediata y precisa, pero la mayoría de las respuestas cuidadosas no coincidían con las expectativas de los usuarios e incluso aumentaban la frustración
• Consultas como el precio de la suscripción, bugs difíciles de reproducir o pedidos de funciones podían servir como señales para mejorar el producto, pero era difícil que una respuesta por sí sola fuera una solución suficiente para el cliente
• Los problemas complejos en los que una persona podía intervenir, como cuentas y suscripciones de App Store, tenían buena recepción, pero estos casos representaban menos del 1% de todos los correos de soporte
• Para el equipo de Castro funcionaba mejor leer los correos y enfocarse en mejorar el producto, en lugar de dar explicaciones largas; las experiencias positivas se generaban más por mejoras reales del producto que por conversaciones de soporte

---

El tipo de soporte que Castro esperaba ofrecer

• Al adquirir Castro, consideraron que el soporte centrado en personas, basado en la experiencia real de uso, podía ser una forma sencilla de diferenciarse
• Como casi nunca recibían respuestas útiles del soporte de los servicios que usaban normalmente, esperaban que los clientes valoraran que ellos usaran el producto todos los días, leyeran todos los correos y respondieran con dedicación
• Cuando el volumen de correos se volvió difícil de manejar, pagaron a un usuario que conocía bien el producto y solía enviar correos con frecuencia para que se encargara de responder el soporte
  • Este usuario obtuvo buenos resultados, especialmente en resolver directamente los problemas de los usuarios
• El resultado fue distinto de lo esperado
  • Cuando podían responder de inmediato y dar una solución exacta, lograban sorprender a los clientes
  • Pero la mayoría de las respuestas diligentes no generaban una satisfacción profunda en los clientes y, a veces, los irritaban más

Consultas sobre suscripciones y precios

• Los correos sobre suscripciones y precios casi no ayudaban a construir una relación
• Castro ya había pensado mucho sobre los precios y el modelo de suscripción, y no iba a cambiar su política por un solo correo
• Podían explicar por qué valía la pena pagar por una app esencial o por qué el software encajaba bien con un modelo de suscripción, pero los usuarios por lo general no quedaban satisfechos con esa respuesta
• En dos años, solo hubo aproximadamente un cliente que recibió con sorpresa positiva la idea de que una suscripción tenía sentido porque el software cuesta dinero y se trabaja en él todos los días
• En el 99% de los casos, por más cuidadosa y amable que fuera la explicación, la respuesta volvía con un tono más negativo que el correo inicial
• También probaron ofrecer 30 días adicionales de prueba a quienes lo pedían, pero eso no cambiaba el tono del correo, y la tasa de conversión de esa prueba era bastante menor que la de la prueba gratuita normal

Las señales y límites de las consultas sobre bugs

• Los correos sobre bugs sí son útiles para quien los recibe
  • Permiten identificar problemas que los usuarios sufren a diario
  • Si el bug ya era conocido y estaba en proceso de corrección, o ya se había corregido, podían dar una respuesta satisfactoria al cliente
  • Por la forma de distribución de App Store, era común que un bug ya estuviera corregido pero todavía no distribuido
• El problema es que muchos bugs no entran en ese caso ideal
  • Hay bugs de los que ya se había oído hablar, pero que no se pueden confirmar ni reproducir directamente
    • El usuario tiene que hacer trabajo adicional o no obtiene una solución, lo que se convierte en una mala experiencia para ambas partes
    • Muy de vez en cuando llega un reporte detallado con pasos de reproducción o condiciones significativas
  • También hay bugs de los que se escucha por primera vez
    • El usuario puede aportar detalles, pero si no les aparecen a otros usuarios, es probable que queden con baja prioridad
  • También hay correos en los que todo el contenido es “no funciona”
    • Si el usuario no aporta más información, casi no hay nada que se pueda hacer
  • También hay problemas ya conocidos, pero cuya corrección requiere mucho trabajo, tienen poco impacto o afectan a pocos usuarios, por lo que quedan con baja prioridad
• Las respuestas a estas categorías no generaban una cercanía significativa
• Dar una respuesta honesta que se acerca a “hoy no podemos resolver este problema y tampoco vamos a intentarlo” puede ser una experiencia muy mala para el usuario
• Los correos de soporte son útiles como señales de problemas, pero Castro solía obtener mejores datos de la telemetría y los logs de crashes

Los casos raros en los que la intervención humana realmente ayuda

• A veces llegan preguntas complejas sobre procesos de App Store, problemas de la tienda, regiones específicas o problemas muy concretos de podcasts
• Un usuario tenía suscripciones de Castro en dos cuentas distintas en momentos diferentes, y quería dejar vencer una de ellas sin perder el período por el que ya había pagado
• Castro resolvió ese problema rápidamente, y los usuarios realmente agradecen ese tipo de capacidad de respuesta
• Sin embargo, estas consultas representaban menos del 1% de todos los correos de soporte, por lo que tenían poco peso para convertir el soporte en una estrategia de diferenciación

Clientes confundidos y una carga recurrente

• A veces los clientes enviaban correos confundidos sobre cómo funcionan los podcasts, cómo funciona App Store, cómo usar la Mac u otros problemas periféricos
• Este tipo de caso era lo más cercano a la relación con clientes que esperaban construir, pero produjo los peores resultados
• El mismo usuario tendía a consultar repetidamente y, cuando descubría que Castro respondía, sus pedidos se volvían más frecuentes y demandantes
• A diferencia del objetivo de construir relación y lealtad, en la práctica terminaban dedicando mucho tiempo a las personas que más exigían
  • Su suscripción no era más cara
  • Rara vez quedaban satisfechas
  • Como resultado, quedaba la sensación de estar siendo aprovechados

Pedidos de funciones y dirección del producto

• Los pedidos de funciones y comentarios generales son buenos en teoría y a veces útiles, pero muchas veces llegan de forma repetida desde un grupo pequeño y poco representativo de usuarios con opiniones fuertes
• Si se implementan sugerencias recibidas por correo, es probable que pronto se reciba toda una hoja de ruta de producto
• Castro es una app con una dirección clara, y ya se había pensado mucho qué construir y qué hacer después
• Era poco probable que un pedido de función se implementara realmente
• Si se ajusta más el producto a usuarios avanzados exigentes, existe el riesgo de alejar a usuarios nuevos que no entienden bien cómo funciona
  • Los usuarios avanzados son un segmento al que le resulta relativamente más difícil irse
  • Alejar a usuarios nuevos es fatal para el producto
• Desde la perspectiva del usuario, una respuesta que no sea “lo vamos a construir ahora mismo” suele recibirse como tibia o negativa
• Las respuestas honestas de que algo ya se había considerado o intentado en el pasado, pero no había funcionado bien, tampoco ayudaban mucho a construir lealtad o cercanía

El modelo de operación de soporte que eligió Castro

• Para Castro, dedicar demasiado tiempo al soporte no era un factor de diferenciación y a menudo producía el efecto contrario
• Los clientes que pagan la suscripción pero no piden cosas gratis por correo también merecen recibir una app tan buena como quienes mandan correos todas las semanas
• Cuando hay una solución clara o una corrección para un problema concreto, conviene resolverlo activamente
• En caso contrario, daba mejores resultados responder brevemente que agradecían el correo, que lo estaban leyendo y que seguían trabajando en el producto para mejorar el problema
• Al evitar explicaciones y detalles, por lo general obtenían una reacción neutral, y nadie quedaba atrapado en una conversación larga ni gastaba demasiado tiempo
• Para Castro, lo que hacen la mayoría de las empresas era lo que mejor funcionaba
• En el momento en que un usuario está frustrado y algo no funciona, es difícil construir lealtad o cercanía; la experiencia positiva real ocurre cuando el producto mejora

[GN⁺]

Opiniones de Hacker News

• Rara vez recibí una respuesta útil del soporte al cliente de los servicios que uso. Por eso pensé que, si usaba mi propio producto todos los días, leía todos los correos y respondía con dedicación, la gente lo agradecería y se generaría cierto grado de lealtad y buena voluntad.
  Opero una app con 16,000 usuarios, recibo entre 2 y 5 tickets de soporte por semana y los leo todos.
  Alrededor del 20% de la app se hizo a partir de sugerencias de usuarios, y la gente en general es amable y promociona la app gratis en varias plataformas. No hay presupuesto de marketing.
  Los usuarios no siempre expresan su agradecimiento con palabras, pero ayudan activamente a resolver problemas enviando pasos claros para reproducir bugs, capturas de pantalla o videos, y respondiendo rápido a las preguntas de seguimiento. A veces me sorprende ver gente recomendando mi app en Reddit o en comentarios de YouTube.
  Si estás dando buen soporte a tus usuarios, es muy probable que ellos ya te estén retribuyendo a su manera.

  • Esto puede variar muchísimo según el tipo de app y cuál sea su base de usuarios.
  • Leer 5 tickets por semana no parece ser un gran motivo de orgullo. Aunque si hubieras respondido todos los tickets con cartas por correo postal, eso sí habría sido impresionante.

• No es un comentario especialmente interesante, pero como parece haber muchas reacciones negativas, quiero aportar algo de equilibrio.
  Me parece interesante que haya hecho el experimento, y agradezco que haya compartido los resultados. Aunque es un poco deprimente, en general se ve razonable.

  • Mucha gente interpreta que el autor quería recibir “likes”, pero creo que están leyendo el texto con demasiada dureza.
    Dar soporte a clientes empresariales que gastan hasta millones de dólares al año y dar soporte a usuarios finales que cuentan cada centavo que gastan son juegos completamente distintos en expectativas, capacidad técnica, profesionalismo, etc.
    Creo que el artículo resume bien el hecho de que no siempre se puede ayudar a todos los usuarios. Es una lección difícil de aprender en soporte técnico, y todos quieren ser el héroe brillante que resuelve los problemas del cliente, pero no es común tener la capacidad de decir “no” de la manera correcta.
    A quienes atacan al autor: incluso si les pagas a las personas para que usen software, igual habrá muchísimas que se quejen y te insulten. Coordinar los intereses del cliente, la presión de tiempo, la salud mental de cada persona, etc., es prácticamente tal cual el trabajo de soporte técnico.
  • Yo pensé lo mismo. Al autor original le van a llover críticas por este texto, pero es un artículo realmente excelente que encaja muy bien con la experiencia de haber manejado productos de mercado masivo.
    Es un registro que vale la pena revisar, así que se lo envié de inmediato a algunos fundadores en etapa temprana que están quemando una cantidad sorprendente de tiempo con clientes poco deseables.
  • Parece que todos en HN saben manejar su negocio mejor que el autor original, y que pueden satisfacer al 100% de los clientes o clientes potenciales el 100% del tiempo.
    El idealismo no dura mucho cuando choca con la realidad.
  • Yo también lo veo así. Se siente como algo que todos los dueños de software piensan por dentro, pero que nadie quiere admitir por la reacción en contra.

• El punto central del artículo es este: “En otras palabras, el mejor enfoque para nosotros es el que usan la mayoría de las empresas”.
  Todo fundador sin experiencia empieza prometiendo que no dará un soporte pésimo como el de grandes empresas tipo Google o Comcast, y cree que eso será un camino al éxito.
  Pero al final aprende que tiene que ofrecer el mismo nivel de soporte que ofrecen las otras empresas de su mercado. Aunque el soporte sea realmente mejor, nadie lo nota como corresponde y no importa mucho.
  Los fundadores sin experiencia son tercos, y eso también es una virtud. Por eso, por lo general solo aprenden esta lección después de vivirla en carne propia.

  • Creo que eso aplica exactamente a un negocio que lanza un reproductor de podcasts.
    Pero el soporte al estilo gran empresa solo es inevitable cuando la empresa necesariamente tiene que escalar. En muchos mercados se puede sobrevivir perfectamente con mayores márgenes y un producto y soporte premium.

• Es deprimente ver el soporte al cliente como un “diferenciador” o una forma de generar ingresos. Simplemente habría que intentar hacer lo mejor para el cliente.
  El feedback que está recibiendo ahora es oro, y si se maneja bien, se puede aprovechar en lugar de ignorarlo. También dice mucho asumir que quienes se oponen al modelo de precios son personas que no entienden de negocios.
  Hay que reconocer que su modelo de precios no es bueno para algunas personas, en especial para quienes sufren fatiga de suscripciones, y decidir si está bien perder su dinero o no recibirlo desde el principio.
  A la estrategia de soporte le falta un canal para que los usuarios con muchas preguntas puedan hacerlas, y en la práctica termina culpando a los clientes por fallas de su propia estructura. Sería fácil crear al menos un foro donde los usuarios avanzados se ayuden entre sí y donde el desarrollador entre de vez en cuando para ayudar o registrar problemas.
  Además, claramente deberían revisar los procesos de desarrollo y QA. Si los reportes de bugs se sienten como “una pérdida de tiempo para todos”, probablemente sea porque la app no tiene registro de errores ni telemetría adecuados. Tener que esperar reportes manuales de bugs por parte de los usuarios ya es, en sí mismo, un fracaso.
  Está perfectamente bien definir el producto como uno quiera y rechazar solicitudes de funciones, pero decir que uno, sentado solo en una silla, pensó todos los problemas en comparación con el pensamiento distribuido de los demás, es bastante arrogante.

  • En algunas situaciones de suscripción, también se puede ofrecer un precio que funcione para ambas partes.
    Una app llamada PhotoSync ofrece opciones premium a 1 dólar al mes o 24 dólares de por vida. Probablemente porque vieron que la duración promedio de una suscripción rondaba los 2 años. Dejando aparte el valor temporal del dinero y los costos de procesamiento por transacción.
    Personalmente, aunque no tenía claro si seguiría usando esa app después de 24 meses, preferí muchísimo más una compra única. Encaja mejor con mi forma algo caótica de administrar el dinero.
  • La parte de “decir que uno, sentado solo en una silla, pensó todos los problemas es bastante arrogante” resulta curiosamente irónica si se aplica a este mismo comentario.
  • Sí y no.
    Cuando despliegas una actualización al 2% de los usuarios, necesitas suficiente registro y telemetría para saber si algo salió muy mal antes de lanzarla al 98% restante.
    Por otro lado, probablemente no quieras telemetría al punto de detectar que el cliente Jim Smith tiene un problema con WebRTC cuando se une a una llamada sin micrófono mientras tiene activado el túnel dividido de Firefox y Cloudflare Warp.
  • Por eso la postura antitelemetría de HN es difícil de justificar.
  • No sé cómo leíste el post del blog, pero esa interpretación no parece precisamente benévola.
    El autor escribió que ya tienen telemetría suficientemente buena, y que en muchos casos no hay mucho que puedan decirle al cliente por correo más allá de una respuesta genérica como “sabemos del problema y agradecemos el reporte”, así que no resulta útil ni para el cliente ni para ellos.

• En la universidad trabajé en una panadería, y conversando con los clientes que venían al local terminé haciendo varios amigos que duraron de verdad.
  Más tarde, con esa experiencia conseguí un trabajo de soporte por email, respondiendo preguntas de usuarios sobre un plugin de software. Aunque un cliente mandara un email una vez al mes, ahí nunca hice amistades duraderas.
  La diferencia está en que en el soporte por email u online no existen esos tiempos muertos humanos. En la panadería, mientras se calentaba o se horneaba lo que habían pedido, uno esperaba y la conversación surgía naturalmente. Al menos era así hace 10 años, cuando los celulares no estaban tan omnipresentes como ahora.
  Me pregunto si, en el contexto del software, algo como unas “horas de oficina abiertas” mensuales por Zoom podría recrear un poco esa sensación. Probablemente no, pero quizá sea mejor que responder emails.

  • También está el hecho de que el soporte por email u online deja registro. No quiero dejar un registro escrito preguntándole a alguien sobre su vida. Si después llega una auditoría, podría ser un problema.

• Me identifico con la parte de “por más cuidadosa y amablemente que lo expliques, en el 99% de los casos la respuesta es más negativa que el primer email”.
  Cuando trabajaba como líder de producto, me gustaba hacer personalmente parte del trabajo de soporte, y es una experiencia común. El cliente que escribe un email enojado no está interesado en tus razones. Quiere algo: una tarifa más barata, una función específica, un descuento, un beneficio gratis; lo demás no le importa.
  Es la versión digital del cliente tipo “quiero hablar con el gerente”, que cree que, si insistir de forma grosera le da aunque sea un 10% de probabilidad de conseguir lo que quiere, vale la pena presionar hasta el final.
  A veces obtenía una pequeña satisfacción cuando alguien se daba cuenta de que del otro lado de la dirección de email había una persona que se preocupaba, y en esos casos se sentía valioso.
  Pero la mayoría de las veces se parecía más a un juego transaccional, donde creen que si se quejan lo suficientemente fuerte pueden ejercer algún poder sobre la empresa.
  Aquí también hay grandes diferencias culturales. Los contactos de clientes de un país donde ofrecíamos el servicio eran tan hostiles que se salían de control. A veces había incluso amenazas leves de violencia, y el 90% venía de un solo país; no voy a decir cuál, pero lo agregué mentalmente a mi lista de “lugares que no visitaré”. Era tan consistente que resultaba extraño.

  • A ese tipo de personas hay que sacarlas de inmediato. No solo son malos clientes en sí mismos, sino que además hacen que se vayan los buenos clientes.
  • En casi 20 años trabajando entre producto y soporte técnico, también vi patrones interesantes en las interacciones de soporte con clientes de ciertos países.
    No todos eran negativos; simplemente eran diferentes. En algunos países primero elogian extensamente y luego piden un descuento de manera indirecta. En otros, contactan por un problema o bug legítimo y, una vez resuelto, esperan una compensación por la molestia. Incluso cuando ellos mismos causaron el problema.
    En otros lugares, aunque la conversación ya pudiera terminar, reabrían el ticket cada vez para agradecer de forma larguísima y expresar gratitud.
    Eso me hizo replantearme mi propia actitud cuando interactúo como cliente o cliente corporativo, y también cómo personas de otros países verán al mío.

• Las historias de fracaso son muy valiosas, y creo que más útiles que los relatos de éxito. Las historias de éxito muchas veces son racionalizaciones a posteriori.
  Es una pena que los genios de sillón de este hilo actúen como si fueran mucho más inteligentes y nunca fueran a fracasar, o al menos como si nunca fueran a admitirlo.

• El texto tiene muchas observaciones valiosas, pero creo que el encuadre está un poco desviado. Suena transaccional y centrado en los números.
  Es bastante sabido que los usuarios más ruidosos no necesariamente son representativos. La mayoría de los usuarios satisfechos no contacta a soporte, pero también son los usuarios más importantes con los que hay que hablar para mejorar el producto.
  Para interpretar las solicitudes de los usuarios, hay que construir un modelo propio de quiénes son tus usuarios. Eso significa decidir si esta solicitud es señal o ruido.
  Si la solicitud viene de alguien que pertenece a tu mercado objetivo y expresa un punto de dolor, puede ser una señal importante. Una solicitud para cobrar solo el 20% del precio actual solo es útil si estás listo para considerar reorganizar tu estructura de oferta. Si recibes muchos emails así, quizá sea una oportunidad para un producto más barato con solo ciertas funciones. Si no, basta con responder “gracias por tu email; actualmente no tenemos planes de cambiar el precio” y seguir adelante.
  Dicho eso, es impresionante que un desarrollador que vende a través de la App Store pueda tener este tipo de conversaciones. Siempre sentí que Apple, al ponerse en medio, mató la capacidad de mantener una relación con los clientes. Nunca he publicado directamente en la Mac App Store.

  • Al final, si es algo que tú y tus empleados hacen para ganarse la vida, y no una actividad benéfica que hacen por diversión en su tiempo libre, es realmente difícil evitar un marco transaccional y centrado en los números.
    Hablar con usuarios satisfechos para mejorar el producto está bien, pero eso no se llama soporte al cliente; se llama investigación de mercado.

• El autor contrató a alguien con conocimientos técnicos, pero eso por sí solo no alcanza.
  El conocimiento técnico y las habilidades interpersonales son cosas distintas.
  Si alguien se tomó la molestia de contactarte, es muy probable que su primera impresión de ti ya sea mala. Si la respuesta se enfoca en “educar al cliente” o se preocupa demasiado por la justicia del negocio en sí, es difícil causar una buena impresión.
  Un gran soporte al cliente debería ser del tipo que hace que el cliente quiera compartir esa interacción con amigos o en redes sociales. El soporte descrito en este texto no parece tener muchas posibilidades de lograr eso.

  • Por dar un ejemplo de cómo ir un paso más allá en este negocio: Uncommon Apps debería crear y mantener un documento PDF con información justa y útil sobre apps de podcasts competidoras que no usen un modelo de negocio por suscripción.
    Cuando alguien se queje con Uncommon Apps sobre el modelo de suscripción, si no pueden hacerle cambiar de opinión —que normalmente será el caso—, podrían enviarle una lista de alternativas.
    Así, el ticket de soporte de Castro podría terminar siendo útil. Uncommon Apps perdería esa venta de todos modos, pero al menos obtendría un beneficio reputacional.
  • Es exactamente lo contrario. Si la primera impresión es mala, no me molesto en contactar a la empresa: busco alternativas.

• Que el CEO o fundador se encargue del soporte de primer nivel quizá no sea tan presumible como parece.
  Desde el punto de vista del usuario, si el CEO o fundador responde mi pregunta, sinceramente me haría sospechar que se trata de una operación temporal de una sola persona que desaparecerá la próxima semana.
  Además, una experiencia de soporte satisfactoria no necesariamente es la más rápida. Si pido algo y soporte de primer nivel dice “no”, lo escala al equipo de ventas, ventas también dice “no” y luego lo escala al fundador, y el fundador dice “sí”, el usuario puede sentirse más “escuchado” y con una mayor sensación de logro.
  El resultado es el mismo, pero en un caso se siente como algo que consiguió por su cuenta.