BLOG

11 consejos para dar un buen servicio de soporte si desarrollas software

Por [N4] rcueto.velneo el | 6 Comments

La atención al cliente en una empresa de desarrollo de software es una tarea a la que no siempre le damos la importancia que realmente tiene. Podemos tener un producto magnífico pero, si no ofrecemos una buen servicio de atención al cliente, éste llegará a tener una percepción negativa del producto.

Debemos ver el producto y los servicios como dos partes de un todo. El servicio es parte del producto también.

Cuando comencé a escribir este artículo me he puesto a calcular cuánto tiempo llevo en la primera línea de batalla, es decir, en contacto directo con “mis” clientes y veo que acabo de cumplir 23 años de servicio, que se dice pronto.

Digo “mis clientes” porque los siento como parte de mi vida, de hecho, puedo decir con orgullo que a día de hoy sigo dando soporte a clientes que conozco desde hace más de 20 años. Creo que eso quiere decir que en esta empresa algo estamos haciendo bien que nos permite generar relaciones duraderas con nuestros clientes.

Desde mi experiencia en este ámbito me gustaría compartir once consejos que creo que pueden ayudar a dar un buen servicio de soporte de software.

1 Personal profesional y motivado

Obviamente debemos contar con personal debidamente formado, que conozca el producto, pero también debe estar motivado y sentirse acompañado.

Debemos tener en cuenta que el personal de atención al cliente es la cara visible de la empresa para los clientes.

Una persona desmotivada nunca va a dar un buen servicio. Puede cubrir el expediente, sin más, pero se alejará de la excelencia que siempre buscamos en este tipo de servicios.

También debe sentirse apoyado y acompañado por el resto del equipo. No hay nada más desolador que encontrarse bloqueado con un soporte y no tener a nadie a quien pedir ayuda y/o consejo.

Nosotros solemos hacer sesiones de equipo cortas a primera hora de la mañana donde ponemos en común nuestras experiencias, resolvemos dudas, etc.

2 Formación continua

En el mundo de software todo evoluciona a una velocidad tremenda, por lo que tenemos que estar continuamente aprendiendo y ser proactivos en el aprendizaje.

Tras todos estos años trabajando aún siento que me queda mucho por aprender y que sigo tengo margen de mejora en mi trabajo.

3 Elige tu plataforma de soporte

En un departamento de soporte pueden llegar consultas por vías muy diversas: teléfono, email, redes sociales, WhatsApp… Busca una plataforma que te permita centralizarlo todo, hacer un seguimiento de las consultas recibidas y responder de manera eficiente.

No intentes inventar la rueda. No pierdas tiempo programando una plataforma de soporte. Hay en el mercado plataformas muy buenas especializadas en atención al cliente o “help-desk”, como dicen los americanos. Compensa invertir en una plataforma ya focalizada al trabajo que hacemos.

En Velneo caso utilizamos Zendesk, pero hay varias opciones en el mercado, todas muy válidas, ideadas par dar soporte de software, es decir, orientadas a empresas que desarrollan programas.

4 Crea una buena base de conocimiento para tus clientes

Una buena base de conocimiento es una valiosa herramienta de autoservicio para nuestros clientes ya que les permitirá encontrar una respuesta inmediata a determinadas consultas.

En nuestro caso, una consulta que se repite de forma reiterada en soporte ya es candidata a ser incluida en nuestra base de conocimiento.

5 Crea procedimientos internos

Sí, ya sé que redactar procedimientos es muy tedioso y requiere mucho tiempo, pero a la larga va a ser beneficioso para el departamento:

  • Siempre están disponibles para su consulta si tenemos alguna duda.
  • Serán un recurso formativo muy valioso para la formación futuros agentes de soporte.

Recientemente hemos incorporado a Eduardo Chaparro a nuestro equipo y los procedimientos que tenemos han sido de gran ayuda para su formación.

6 Crea niveles de escalado de soportes

Hay soportes que los técnicos podemos resolver sobre la marcha, otros no, pues requieren de la realización de pruebas y otros requieren de la intervención del Equipo de Desarrollo. Es recomendable, por tanto, definir los distintos niveles que vayamos a tener de soporte e informar sobre nuestros niveles de escalado y avisarles cuando un soporte sea escalado a un nivel superior.

En nuestro caso tenemos tres niveles:

  • 1er nivel: soporte normal.
  • 2º nivel: soporte que requiere de la realización de pruebas.
  • 3er nivel: soporte que ha pasado al Equipo de Desarrollo para su análisis.

7 Condiciones del servicio

Es bueno que los clientes conozcan las condiciones de nuestro servicio para así evitar posibles malentendidos durante el ejercicio del mismo.

En nuestro caso, están publicadas en nuestro centro de soporte.

8 Las formas

Debemos ser empáticos, ponernos en la piel del cliente cuando acude a nosotros en busca de ayuda.

Somos humanos y cometemos errores. Si cometemos un error no intentemos echar balones fuera ni justificarnos. Es mejor reconocer abiertamente nuestro error y pedir disculpas.

Si vas a enviar una respuesta por escrito, léela de nuevo antes de enviarla. Cambiarás algo seguro, y si vuelves a hacer una nueva revisión, seguro que también…

9 Solicitar valoración

Nada mejor que un cliente valore nuestro servicio. Lo ideal es que no solamente lo valore, sino que nos de su “feedback” para que nosotros podamos analizarlo y obtener un aprendizaje de ello y, por tanto, sacar de ahí una posible área de mejora.

10 Contacto con el equipo de desarrollo

Al comienzo de este artículo decía que el producto y el servicio eran uno. En el caso del software, el equipo de desarrollo debe tener contacto directo con el equipo de soporte. Es fundamental para lograr un buen producto/servicio

11 No superar las expectativas

Y como último consejo uno que seguramente os extrañará leer a muchos de vosotros. Y no lo digo yo, es algo que está estudiado y demostrado: superar las expectativas del cliente no va a hacer que éste valore mejor nuestro servicio. Sorprendente, ¿verdad?

Si un cliente te pide una manta dale la manta. Que se la des dando un triple salto mortal desde el mostrador a ti te va a suponer un desgaste y un esfuerzo extra que realmente no va a aportar nada a tu cliente.

Artículos relacionados: Tu plataforma de desarrollo de software de gestión empresarial en Colombia para 2019 y más allá, Guía para elegir una plataforma de desarrollo con éxito

Velneo es el entorno ágil para el desarrollo
de aplicaciones empresariales

DESCARGAR VELNEO

6 Responses to "11 consejos para dar un buen servicio de soporte si desarrollas software"
  1. [N4] SyP dice:

    Buen artículo. Se lo ha leido el personal de soporte de Velneo?

  2. Muchas gracias por tu comentario. Como bien digo en el artículo no somos perfectos pero intentamos mejorar cada día.

    Le damos muchísima importancia a la puntuación que los clientes hacen de cada soporte y les llamamos cuando vemos una puntuación mala para aclarar lo sucedido. Nos encantaría comentar contigo por teléfono cualquier incidencia o aspecto de mejora.

    Un saludo del equipo de soporte.

  3. [N4] conexta2 dice:

    Buenos días y buen artículo!
    Este articulo da para mucho mas, y a veces lo importante es centrar el tiro.
    Habéis pensado alguna vez, que si dedicarais a documentar un poco mejor, por ejemplo, vERP, lo ahorraríais en horas de soporte-
    Cuando decidimos enviar un ticket de soporte, no es por gusto, es porque no encontramos otra solución.
    Si vERP tuviera un buen documento de análisis, ahorraria muchos soportes.
    Ese ahorro en tickets de soporte, os permitiría dedicar mas tiempo a los tickets realmente importantes, que requieren de pruebas y comunicación con desarrollo.
    Así que es la pescadilla que se muerde la cola. Si queréis mejorar el soporte, no debéis mejorar la formación de los agentes de soporte, debéis mejorar la formación de los clientes para que no os hagan perder el tiempo con las chorradas que se envían a soporte. Si evitáis ese 80% de soportes intrascendentes, podréis dedicar más tiempo al 20% de tickets verdaderamente importantes.
    Ejemplo, que en vERP se incluya un campo, una tabla, una funcionalidad… para realizar cualquier tarea, no sirve de nada, si no nos explicáis para que sirve ese campo y por que se ha decidido hacer de esa forma y no de otra. Porque normalmente decimos que eso esta mal echo, cuando deberíamos decir que creemos que esta mal echo porque realmente no sabemos como se debe usar. Y si entendemos el porque de esa decisión, igual nuestra opinión sería muy diferente.

    saludos
    Jose

  4. Buenos días, Conexta2.

    Estoy de acuerdo con lo que comentas. Somos conscientes de que mejorando vuestro conocimiento os ayudamos y eso redunda en un beneficio para todos.

    Precisamente estamos con un proyecto interno que tiene ese objetivo de mejora para que programar con vERP sea para vosotros más fácil a partir del conocimiento de su código..

    Aprovecho para preguntar si conocéis estos recursos que están disponibles:

    Lista de reproducción del canal de youtube de Velneo sobre Velneo vERP.
    https://www.youtube.com/watch?v=j4y1GZGSUPI&list=PL-bVpgNOlmiq_tdc-svJdubtCirDXrOOg&index=5&t=0s

    Novedad de Velneo 26 sobre la documentación en vídeo para usuario final de Velneo vERP, para facilitar el conocimiento de las funcionalidades.
    https://velneo.es/novedad-velneo-26-nuevo-sistema-de-ayuda-de-verp-en-video/

    Guía de estilo de programación Velneo con la que está desarrollada Velneo vERP. Se entregó en un curso de actualización.
    https://disfrutaprogramando.com/wp-content/uploads/2019/11/Gui%CC%81a-de-estilo-de-programacio%CC%81n-Velneo.pdf

    Reitero que estamos trabajando para mejorar la formación de vERP para desarrolladores de Velneo. Y esperamos tener novedades interesantes en el primer semestre de 2020.

    Un cordial saludo.
    Jesús Arboleya

  5. Hola a todos.

    José, a mi me pasa a veces como a ti y, como bien dices Jesús, luego descubro que una cuestión que me vuelve loco está perfectamente documentada.

    Un ejemplo:
    En vERP, menú Configuración, Grupos de usuarios, no consigo entender si la pestaña Opciones de menú me permite asignar facilmente las opciones a las que podrá acceder o no un usuario de ese grupo. La primera vez marque los que no quería asginar a ese grupo y descubrí que los borra para todos. La duda que tengo, ¿me simplifica la asignación o su funcionamiento es el mismo que Configuración, Menús dinámicos?

    Saludos y, por favor, no lo toméis como una critica. Solo es una aportación, a mi me pasa lo mismo con los usuarios del software que desarrollamos.

    Luismi.

  6. Hola, Luismi:

    Antes de nada, quiero agradecer tu respuesta. Como bien ha respondido Jesús a José, estamos con un proyecto interno que tiene ese objetivo de mejora para que programar con vERP sea para vosotros más fácil a partir del conocimiento de su código.

    De hecho, en estos días habrás recibido un correo con un cuestionario para que nos des tu feedback sobre vERP, ya que es muy valioso para nosotros.

    Muchas gracias por tu interés y por tu colaboración.

Deja un comentario

Esta web utiliza cookies. Si continúa navegando acepta dichas cookies y nuestra política de cookies. Gracias. ACEPTAR

Aviso de cookies