Las empresas tecnológicas (y no tan tecnológicas) han despreciado e infravalorado el soporte técnico durante los últimos 20 años. Alguien en algún momento dijo “eso no escala” y es muy caro a medida que los usuarios crecen. Como si todas las empresas hiciesen el famoso hockey stick o tuviesen millones de clientes.
En parte es verdad, pero no toda la verdad. La parte que no se cuenta es que dar un soporte de alta calidad es también difícil, así que aunque creas que no lo haces porque es caro, en realidad no solo es un tema de pasta. Tener a gente con una calidad técnica alta, que sepa navegar varias capas de tecnología y personas para solucionar algo, que tenga criterio para tomar decisiones sin avisar a un supervisor, no es sencillo.
Es complicado formar a alguien para estar a un nivel técnico alto. Más difícil es formarlos para que sean amables, empáticos y resolutivos. Pero lo realmente jodido es encontrar gente a la que realmente le preocupe lo que le pasa al cliente. Alguien que le importe, que no abandone cuando ve a un cliente en la estacada y que ponga buena cara después de dos años viendo problemas todos los días.
Soporte técnico no es “preguntas-fáciles-de-resolver as a service” o alguien respondiéndote emails con frases sacadas de una plantilla para dar la sensación de que se está haciendo algo con la esperanza que dejes de protestar.
Es preguntar las preguntas adecuadas, es informar al cliente de lo que pasa, es pelear para solucionar un problema, o por lo menos dar una respuesta satisfactoria. Es perseguir durante meses un problema, es buscar una vía para bordear lo que está bloqueando en vez de un “sorry, unfortunately”. Es instalar ese software que no instalarías en tu vida solo para ver lo que tu cliente ve. El soporte técnico no es esperar, es preguntar antes de que pase. Es monitorizar y avisar.
Mucha gente no se da cuenta que tener un soporte técnico de calidad es el mejor camino para no tener churn, la mejor forma de que tu cliente use el producto más, la mejor forma de que tu producto escuche a los clientes (y no clientes), de que esa persona junior se convierta en la persona que mejor entiende el producto. El soporte técnico tiene efecto compuesto.
En Tinybird lidero el equipo de “data engineering”, no es un equipo de trabajo con datos hacia dentro, es hacia fuera, ayudamos a los clientes a resolver problemas con datos. Somos actualmente 11 personas (un 15% de la empresa) y hacemos tareas pre y post venta. Ayudamos con desde cosas sencillas a cosas que requieren meses de investigación. Los casos de uso en los que trabajamos son complejos y difíciles, muchos de nuestros clientes podrían haber estado meses para resolver esos problemas. Y no hablo de clientes que no sepan qué es trabajar con datos precisamente.
No me arrepiento ni un segundo de haber invertido horas y horas en tener un equipo que sepa de trabajar con datos en tiempo real, que sepa sacarle jugo a cada ciclo de CPU y que tenga en la cabeza lo que tiene que preguntar después de escuchar al cliente 20 segundos. Es cierto que luego ellos han puesto la parte más importante, la parte humana, la de que te importe el prójimo.
Tinybird es un producto para desarrolladores y la parte técnica es muy importante en el soporte de calidad, de hecho para mi es un equipo más de desarrollo dentro de la empresa. Se ve que de casta le viene al galgo o que realmente no sé hacer otra cosa, pero el hecho de tener un equipo cohesionado, muy técnico y que cubra bien todos los espectros necesarios no se diferencia en prácticamente nada a un equipo de producto.
Pon un buen equipo a hablar con tus clientes y pon a todo tu equipo a hablar con tus clientes. Da igual por qué parte empieces, es un ciclo virtuoso.
(Por cierto, buscamos gente para el equipo de data engineering )
Después de años desarrollando, ahora me dedico al Global Customer Center. Me toca hacer un poco de todo, también desarrollo, y aunque reconozco que echo de menos desarrollar más, y que a veces el trato con cliente es difícil, también lo es la satisfacción. Lo más importante, es que el equipo este unido, se ayuden, y que tengan acceso y herramientas adecuadas. Para mi poder leer el código es fundamental. Y he de decir, que la peor parte es la de la gran responsabilidad que supone, como bien has explicado, ya que es un peso enorme, y por eso, sentir el respaldo y apoyo del equipo y la organización es fundamental. También participamos en despliegue de proyectos, cuando no hay carga en casos elevada, lo que nos ayuda a mantenernos al día, y en contacto con los diferentes proyectos y clientes. Por último, estoy muy de acuerdo, en que es un perfil exigente, si se quiere hacer bien, no se trata de respuestas programadas, y por eso, hay casos que se resuelven en horas ,y otros, en meses o años.
Antes, yo tenía un dominio total del producto, y ahora es complicado por la amplitud (es otro diferente, muy legacy, y a la vez moderno), y ahí, una buena base de conocimiento es fundamental. Por un lado la documentación oficial, pero una buena wiki para el GCC, y un QA, son para mi, imprescindibles.
Ahora mismo, incluso me ha surgido una oportunidad para desarrollo en un nuevo producto (internamente), y me está costando siquiera considerarlo, porque el equipo GCC y de Proyectos, es extremadamente acogedor, y eso, no tiene precio. Y sobretodo, que está lleno de retos, aunque no siempre son de programación, me estoy curtiendo con los coredump, algo que no había podido hacer muy a menudo, y que para mí, es un área muy interesante.
Perdón por el speech, empecé bien, pero mi mente en árbol me ha arrastrado. Algo que me resulta muy, muy útil en el momento de resolver casos y relacionar todas las partes que intervienen en un problema.... Gracias por leerme