Mis errores como emprendedor líder en tagUin


En noviembre de 2009 dejé Toprural para liderar un nuevo proyecto que había concebido algunos meses antes. Me fui de Toprural movido por el gusanillo emprendedor y por el deseo de liderar mi propio proyecto. Si no hubiera sido por eso, voluntariamente me hubiera quedado mucho más tiempo ya que sentía que aportaba cosas a la vez que aprendía otras muchas.
En aquel momento las redes sociales verticales estaban en pleno auge y yo venía de participar en dos proyectos muy exitosos, pensaba que mi momento había llegado. Como ya conté en un post anterior, tanto François Derbaix como José Luis Vallejo me apoyaron desde el principio, me ayudaron con el plan de negocio y me enseñaron cómo encontrar financiación. En paralelo, Javier Fernández y Alberto Rodríguez completaban el equipo emprendedor y trabajaban en ls primera beta del proyecto, que vio la luz en junio de 2009 en forma privada para algunos beta testers. Mi rol no era tan técnico como en anteriores proyectos, para eso estaba Javier. En este caso tenía que liderar el proyecto en todos sus aspectos.
Conseguimos 160.000€ de capital semilla aportado por amigos, familiares y algunos business angels lo que suponía un inmejorable punto de partida. No obstante cometí muchos errores que han hecho que hoy tagUin esté en una vía muerta. Entre tantos errores he destacado tres que creo que son los más significativos, aunque si preguntáis a mis socios, seguramente identifiquen otros muchos:

  • No crear un equipo más heterogéneo. Es uno de los errores de libro pero yo lo cometí. Los fundadores teníamos un perfil demasiado parecido y dejamos cojas áreas clave en una startup. Hacer un buen equipo es muy difícil y además uno de los factores de éxito más importante. Como fundador líder debería haber buscado un equipo más complementario.
  • Invertir demasiado pronto en marketing. En una startup que arranca con poco capital, invertir correctamente cada euro es otro de los factores de éxito y yo no lo hice bien. En mi deseo de crecer rápidamente y alcanzar unos objetivos de negocio razonables que nos permitieran cerrar con garantías la siguiente ronda de financiación, invertimos en marketing cuando nuestro producto no estaba suficientemente maduro y eso suponía que cada usuario que captábamos, no lo rentabilizábamos correctamente. Además, el capital inicial que teníamos no nos permitía hacer demasiados experimentos por lo que teníamos una bala y teníamos que acertar en la diana a la primera. Lo he comentado alguna vez a quien me pregunta sobre el tema: es mejor apuntalar y mejorar el producto antes de invertir en marketing. Si no te puede pasar como a nosotros.
  • Arrancar sin capital suficiente como para demostrar a los inversores que el proyecto tiene “tracción”. Este es quizá el punto más controvertido, sobre todo entre los más firmes defensores del emprendimiento low-cost pero me voy a explicar. Cuando un proyecto va orientado al gran público y además necesita de un volumen importante para que el modelo de negocio tenga sentido, hay que tener claro que la inversión necesaria es muy grande. Los inversores que invierten después de la ronda semilla esperan ver que el proyecto ha despejado algunas de las incógnitas del business plan y además ha encontrado un camino hacia el éxito. Mi error fue arrancar tagUin sin capital suficiente como para llegar con garantías a ese punto, sin gasolina para llegar al punto que los inversores esperan de un proyecto invertible en búsqueda de su segunda ronda de inversión. Sin esa gasolina, nos quedamos a mitad de camino, en la vía muerta en la que estamos ahora. Fueron mis ganas de emprender y mi falta de experiencia en el arranque de proyectos lo que me llevó a pensar que con 160.000€ en un proyecto como tagUin se puede llegar a ese punto, pero no creo que sea así.

Estos errores fueron, bajo mi punto de vista, los más importantes, aunque hubo otros. En diciembre de 2010 y de la mano de José Luis Vallejo a través de su empresa Medianet, Javier y yo pasamos a formar parte del equipo técnico que desarrolló un core de ecommerce para Prisa Digital en paralelo a Planeo, el site de ofertas de ocio del Grupo Prisa. Esto suponía aparcar definitivamente tagUin, dejándolo en modo supervivencia. En este momento tagUin tiene unos 40.000 usuarios registrados, aunque muy poco tráfico. De hecho estamos buscando la mejor manera de liquidar el proyecto, vendiéndolo, traspasándolo o cerrándolo.
Mi rol en Prisa fue la de responsable técnico de Planeo y product-proyect manager de ecommerce en Prisa Digital. Esta nueva fase tampoco estuvo exenta de errores. Pero eso lo contaré otro día.

Mis errores como CTO en Toprural


Tal y como hice en el post anterior donde repasé mis errores como CTO en BuyVIP, voy a repasar mis errores como CTO en Toprural, como parte de la serie de posts auto críticos que inicié con este post.

Me incorporé a Toprural en junio de 2008 después de dejar voluntariamente BuyVIP. Me encontré con un equipo técnico ya montado de 10 personas de los que 8 se dedicaban a desarrollo y que estaban repartidos en dos equipos: los que estaban desarrollando desde cero un nuevo Toprural en nueva tecnología y los que estaban manteniendo el antiguo Toprural. El foco era cumplir el plan de migración al nuevo Toprural (15 meses que terminaron siendo 18) junto con la implantación de un ERP (finalmente fue Microsoft Dynamics NAV) y el reciclaje del equipo encargado del mantenimiento del antiguo Toprural. No fue un aterrizaje fácil ya que una parte grande del equipo técnico no entendía la necesidad de un CTO, pensaban que no necesitaban jefe y lo peor, pensaban que la empresa dependía de ellos, lo que generaba un ambiente de ellos contra el mundo. Afortunadamente con el tiempo fueron entendiendo mejor la situación y se terminaron destapando las manzanas podridas del equipo. Allí me encontré a gente muy brillante técnicamente y alguno evolucionó de manera impresionante, siendo mi sustituto como CTO tras mi salida. A Paco le deseo lo mejor en su nueva etapa fuera de Toprural y espero que algún día podamos volver a trabajar juntos.
En esta nueva etapa me sentía muy a gusto y con la confianza de la dirección. Tanto François como Rafa creían en mi y en mi criterio y yo pude aprender mucho de ellos. Sin duda fueron buenos tiempos. Los principales errores que destaco de aquella época son:

  • No traerme a todo mi equipo de confianza. Creo que es esencial tener confianza ciega en las personas más importantes de tu equipo. En esta nueva aventura me acompañaron, algunos meses más tarde, dos de las personas de mi equipo de BuyVIP aunque una de ellas se volvió bastante pronto a BV tras no gustarle lo que allí encontró (incluso creo que yo mismo fui una de las cosas que no le gustó, aunque ya me conocía). Me costó demasiado tiempo sentirme alineado con mi equipo y eso nos impidió ir más rápido y mejor. Finalmente lo conseguí parcialmente al poder confiar plenamente en el trabajo que hacía el que fue mi sustituto.
  • No tener buen ojo con los fichajes. No todos los fichajes fueron malos ni mucho menos. Algunos fueron realmente buenos, pero unos cuantos fueron un error completo y lo peor fue que conseguí el efecto contrario al buscado: En lugar de alinearse conmigo, se alinearon con las manzanas podridas.
  • No despedir a quien debía cuando debía. Este punto suena muy duro y habrá gente que piense que soy un insensible o cosas similares pero nada más lejos de la realidad. El despido es un drama para todas las partes. Para la empresa porque tiene que prescindir de un profesional al que una vez quiso en el barco y que tiene que suplir con otra persona, con el trastorno que eso supone. Para el trabajador… Un palo muy duro. Aunque muchas veces es la mejor solución para todas las partes implicadas. El tema del despido requeriría un post aparte que escribiré cuando acabe esta serie. El caso es que debía haber limpiado la casa de manzanas podridas y haber dejado a los realmente buenos e implicados, fichando y renovando al equipo, aunque a corto plazo supusiera un retraso en loa planes. En estos casos te terminas dando cuenta que todo el tiempo que retrasas esta decisión es tiempo perdido.

Me marché de Toprural a finales de 2009 para montar tagUin. Después de pasar por dos empresas exitosas de Internet, no pude contener más el gusanillo emprendedor y decidí dar el salto, dejar un buen trabajo para montar un proyecto propio. Tuve la suerte de que muchos amigos e inversores apostaron por mi y por el proyecto, pero no estuvo exento de errores, aunque esta vez no fueron tanto técnicos o de gestión de equipos… pero eso lo cuento en el siguiente post.

Mis errores como CTO en BuyVIP


Me incorporé a BuyVIP en febrero de 2007. Primero como empleado de Medianet, empresa socia fundadora de BuyVIP, siendo CTO part-time compartiendo tareas con otros proyecto de dicha empresa. Pero rápidamente las necesidades de la empresa requerían una dedicación a tiempo completo y pasé a la plantilla de BuyVIP. En aquel momento toda la tecnología estaba externalizada en Medianet y hacía falta que BV tomara dicho control por lo que mi primera preocupación fue crear equipo propio. Para ello conté con varias personas que conocía de etapas anteriores y en las que confiaba. Era la primera vez que era CTO y de ahí vinieron muchos de mis errores. Los que más destaco son:

  • Falta de seniority. No es tanto un error mío sino una característica inherente a mi situación en aquel momento. Era la primera vez que era CTO y además no había tenido ningún espejo en el que mirarme. Por suerte, este tipo de “errores” se corrigen con el tiempo y con ejercicios de autocrítica como esta serie de posts. Ya lo he comentado en algún post anterior, un CTO no es un programador venido a más o como en mi caso en aquel momento, un jefe de proyecto venido a más.
  • No pensar a lo grande. En un proyecto como BuyVIP en el que todo va muy rápido y el crecimiento es enorme hace falta pensar a lo grande y concebir la estrategia técnica de la misma manera. Siempre intenté dar los pasos adecuados cimentados en base sólida pero en algunos momentos en BuyVIP ese no era el mejor camino.
  • No imponer más mi criterio. Derivado del primer error comentado y en un entorno donde el CEO de la empresa tiene un carácter y un empuje muy importantes y que intenta imponer su criterio en todos los órdenes de la empresa, me dejé influir en muchos aspectos en contra de mi criterio y creo que de esa influencia vinieron las peores decisiones o acciones tomadas en el departamento técnico. Debería haber sabido demostrar que mi criterio era el correcto y no dejarme influenciar. Este punto fue la principal razón de mi salida voluntaria de BV en junio de 2008.
  • No pedir ayuda. Hay veces que hay que reconocer que te hace falta ayuda. Yo quería hacerlo lo mejor posible y quería hacerlo demostrando que podía hacerlo con mi equipo pero en aquella situación lo mejor hubiera sido reconocer que hacía falta un CTO con más experiencia y ponerme a rebufo suyo para ganar experiencia y conocimientos.

De todo se aprende. Muchas veces repaso situaciones de aquella época y pienso cómo las hubiera afrontado ahora. Las cosas hubieran sido diferentes aunque a toro pasado todo se ve de otra manera.

Tal y como he dicho antes, me fui voluntariamente de BV en junio de 2008. Tomé la decisión de marcharme un par de mese antes y así lo comuniqué. El nivel de estrés que tenía junto con mi falta de feeling con la dirección de la empresa me hicieron tomar esta decisión. El siguiente paso fue incorporarme a Toprural como CTO. Pero eso lo cuento en el siguiente post…

Mis defectos y virtudes


Voy a empezar a escribir una serie de posts bastante reflexivos, con una dosis fuerte de autocrítica y auto análisis que espero que sirvan a alguien para no cometer los mismos errores y de paso os animen a hacer el mismo ejercicio. Creo que es importante conocer nuestras fortalezas y debilidades para intentar corregir las segundas e impulsar las primeras. Como le decía a un gran amigo hace ya algunos años en tono jocoso: “lo primero es reconocer que eres un atraso de persona. A partir de ahí todo es construir”.

Los posts que quiero escribir en esta serie son:

No van a ser posts demasiado largos ya que no tengo demasiado tiempo. Mi hijo ha cumplido un año hace pocos días y le dedico el poco tiempo libre que tengo. Por eso voy a escribir en ratos cortos e intentaré que los posts sean muy concentrados.
Me pongo a ello…

Lo que quieres no siempre es lo que necesitas


Hace unos días ponía en twitter que una cosa es lo que quieres y otra bien distinta lo que necesitas. Esto es aplicable en todas las áreas pero hoy quiero desarrollar un poco mejor este concepto en el ámbito del desarrollo de software.

El negocio suele saber lo que quiere
Es habitual que el equipo de negocio sepa más o menos lo que quiere. El problema es que la mayoría de las veces nos transmiten al equipo técnico directamente cómo implementar la solución en lugar de la necesidad de negocio. Esto provoca que si en el equipo técnico no hay un perfil con la experiencia y conocimiento suficiente, se suele implementar directamente lo que propone el negocio. Bajo mi punto de vista es un error ya que, saben lo que quieren pero no lo que necesitan. O dicho de otra manera, saben cuál es la necesidad del negocio pero no la mejor y más eficiente manera de cubrirla.

Rascando y profundizando
Si los técnicos queremos hacer bien nuestro trabajo debemos evitar quedarnos en la info que nos transmite el equipo de negocio y rascar hasta encontrar y entender la necesidad que quiere cubrir el negocio. A partir de ahí debemos concebir la mejor solución y explicarsela al negocio, “pariendo” conjuntamente el camino a seguir. Para ello hace falta tener en el equipo técnico perfiles que sepan de negocio, que entiendan lo que hace falta y que tengan la experiencia suficiente para saber el camino a seguir. Este tema es especialmente crítico en una startup donde el time to market y el presupuesto son muy ajustados, donde no hay tiempo ni dinero para hacer pruebas. Esta experiencia y conocimiento debe venir del CTO. Por eso creo que el CTO de un startup no debe ser un programador con ganas de emprender si no un profesional con largo recorrido técnico y experiencia en el mismo sector de actividad.

No siempre es tan fácil
Pero no siempre es fácil trabajar de esa manera. Para que eso sea posible es imprescindible que desde negocio se confíe en el equipo técnico, que estén dispuestos a aceptar que los técnicos podemos aportar soluciones al negocio y que nuestra experiencia es tan válida como la suya aunque con diferente punto de vista. ¿ Creéis que esto es posible? Difícil, pero posible. Por experiencia puedo decir que muy pocas veces he podido trabajar así pero que cuando lo he hecho los resultados han sido buenos y rápidos o lo que es lo mismo, bueno y barato. Y también por experiencia puedo decir que es más fácil trabajar así en una empresa pequeña o una startup que en una gran empresa donde el trabajo de los técnicos está muy distante del negocio y el negocio no quiere escuchar al equipo técnico. Por eso prefiero las startups!!!

Sueldo de los fundadores. Mi opinión


Estos días ha habido un buen debate en twitter y otros medios, iniciado por François Derbaix, sobre el sueldo de los fundadores en una startup. Básicamente, François dice que el sueldo de los fundadores es inversamente proporcional a las probabilidades de éxito de una startup y aporta ejemplos claros.
He tenido la suerte de tener a François como jefe primero y después como socio e inversor y éste ha sido un tema que hemos tratado varias veces. En este caso no coincido con él y quiero compartir con todos vosotros mi opinión.

Arrancar una empresa es una tarea que requiere que los fundadores estén involucrados al 200%, con la mente ocupada en la empresa 7×24. Por tanto hay que intentar que en su entorno haya el mínimo de distracciones que hagan que su mente se disperse. Es importante que su entorno familiar y personal le den todo su apoyo, que entiendan por lo que está pasando y que le eviten a toda costa quebraderos de cabeza. Uno de los mayores quebraderos de cabeza que tenemos casi todos es el tema económico cuando no está suficientemente cubierto. Pensar en cómo llegar a final de mes cuando se nos ha roto el coche o cuando hemos tenido que llevar a los niños al dentista, no debería ser algo que preocupara a un fundador, que debe estar centrado en sacar adelante la empresa. Por ello yo creo que un fundador debe tener un sueldo suficiente como para cubrir, sin lujos, pero razonablemente bien los gastos a los que se enfrenta en su vida familiar y personal y así evitarle una distracción importante. Además debe tener un porcentaje suficiente de la empresa como para luchar por ello a muerte y no conformarse con cubrir gastos.

Por tanto, en mi opinión, un sueldo alto no debe influir significativamente en la posibilidades de éxito si el plan de negocio se ha hecho correctamente y se ha contemplado adecuadamente. Es más, creo que el paquete retributivo, que incluya sueldo más participaciones, de un fundador debe estar por encima del precio de mercado y que sea el propio fundador el que decida, en función de sus necesidades, cómo repartirlo. De esa manera garantizamos que el tema económico no le llevará a decisiones prematuras y poco válidas para el negocio a medio plazo motivadas por motivaciones económicas a corto plazo.

Por supuesto el debate está abierto y me gustaría conocer vuestra opinión.

Robo de información a BuyVIP


Escribí este post hace algunos días y lo dejé en borradores. Mejor publicarlo tarde que nunca.

Las noticias en Internet vuelan y lo que es actualidad un lunes, ya no lo es un jueves. Por eso este post puede parecer un poco obsoleto, ya que hace días que BuyVIP mandó un email a todos sus usuarios activos indicando que habían sido víctimas de un robo en el que les habían sustraído la información de sus usuarios. Fui CTO de BuyVIP durante un año y medio y por tanto soy especialmente sensible a estas cosas y en base a ello me gustaría compartir con vosotros mi opinión.

Información sustraída
Tal y como indica la propia BuyVIP en su comunicado, les han robado nombre, dirección de email, dirección de envío, fecha de nacimiento, teléfono y contraseña. Es decir, les han robado aquella información que tenían en la base de datos. Ellos mismos dicen que los datos de pago no se han visto afectados, pero creo que está mal expresado. No se han visto afectados porque BuyVIP no almacena esa información y por tanto al no tenerla no se la pueden robar. Yo hubiera remarcado este hecho, ya que creo que transmite más confianza al usuario.

Otro punto que merece la pena comentar es el de la contraseña. BuyVIP no almacena la contraseña en claro, si no encriptada con MD5 usando una semilla, dando por tanto un código alfanumérico de 40 caracteres. Un MD5 no se puede desencriptar y para saber si la password es válida lo que se hace es encriptar la recibida y comparar con la almacenada. Por tanto si alguien quisiera obtener la password debería hacer un proceso de prueba y error encriptando todas las combinaciones de letras y números (si no recuerdo mal hasta 100 caracteres) y compararlo  con lo almacenado. Eso suponiendo que tenga la semilla, ya que si no la tiene ni aún así se obtendría la password. En resumen, han robado la encriptación de la password, pero no la password real. Personalmente estoy tranquilo porque tengo claro que nadie va a obtener mi password en base a lo robado de BuyVIP.

Comunicación a los usuarios
Todo el mundo intuía que pasaba algo ya que tiraron voluntariamente la tienda un miércoles (hablo de memoria) y no volvió a estar operativa hasta el sábado, pero la gente pensaba que estaría relacionado con la apertura de la tienda de Amazon en España. El mismo sábado avisó a sus usuarios activos en los términos comentados, pero hasta varios días después no avisaron a los usuarios dados de baja. Ya comenté en twitter que pensaba que era un error ya que, si bien un usuario dado de baja ha decidido no recibir más notificaciones, estamos ante un hecho extraordinario y al fin y al cabo también han robado la información de los usuarios dados de baja. Pero lo más crítico de este hecho es que indirectamente BuyVIP ha reconocido que guarda toda la información del usuario a pesar de haber sido dado de baja. Me gustaría conocer la opinión de un abogado al respecto ya que esa información debería haber sido borrada con la baja y podría haberse hecho perfectamente ya que no debería afectar en ningún caso a la información financiera relacionada. Algún abogado en la sala que nos de su opinión?

Qué pueden hacer con la información robada
Si el autor del robo lo ha hecho con el fin de obtener datos de pago, la jugada le ha salido mal, pero si simplemente quería obtener una bbdd grande, cualificada y bastante completa de usuarios y compradores de toda Europa, le ha tocado el gordo, ya que BuyVIP tiene varios millones de usuarios en su base de datos. Esa información la puede vender a empresas de email marketing no muy legales para enviar publicidad. La pueden vender incluso a empresas de publicidad física que te envían cartas a tu buzón. Se pueden hacer muchas cosas y no me extrañaría que en los próximos días o semanas recibiéramos más spam del habitual.
Otra alternativa es usar esa información para obtener todavía más info por physing, mucho cuidado con las próximas notificaciones que recibáis en el email pidiendo confirmar datos.

Espero que dentro de unos meses todo quede en una anécdota y los problemas no vayan a más para BuyVIP.

Breve análisis sobre SugarCRM


En las últimas semanas y gracias a un proyecto de ecommerce que estoy haciendo para un importante cliente, he tenido la oportunidad de entrar en las tripas de SugarCRM para ver sus cualidades en cuanto a modificación de la funcionalidad existente y extensión con nueva funcionalidad. La verdad es que me ha sorprendido y quería compartir con todos algunas de las conclusiones que he sacado.

Antecedentes
Ya había visto SugarCRM con anterioridad. En concreto fue durante mi etapa como CTO en BuyVIP cuando pusimos este software como herramienta principal para el equipo de atención al cliente. Era la versión 4 y la modificamos y extendimos para integrarla con la tienda de BuyVIP. En aquel momento la experiencia no fue demasiado buena, pero todo cambia…

Situación actual
Cuando arrancamos el proyecto en el que estoy involucrado, hicimos un breve análisis de alternativas de software CRM para atención al cliente y decidimos usar SugarCRM en su última versión (6.1). Pensamos que si ya lo habíamos extendido y adaptado con anterioridad, seguro que podíamos hacer lo que queríamos y que muy raro sería que el software no hubiera evolucionado a mejor con el paso de las versiones. Por ello nos descargamos la versión community y nos pusimos manos a la obra.

Extensiones y modificaciones que no afectan a actualizaciones
Una de las cosas que me ha sorprendido positivamente ha sido la arquitectura de la aplicación que permite separar la funcionalidad base de las extensiones y modificaciones de manera de un cambio de versión no supone perder tus cambios ni tenerlas que rehacer. Parece que poco a poco todos los fabricantes de software (Prestashop ya incorpora esta arquitectura en la versión 1.4) van entendiendo que es necesario adaptar y extender sus productos sin perder la capacidad de instalar nuevas versiones.

Nueva funcionalidad con module builder
Si queremos incorporar nueva funcionalidad como por ejemplo contratos (no se si lo tiene pero es por poner un ejemplo), de una manera muy fácil desde el module builder podemos hacer un nuevo módulo, definir sus campos, relacionarlo con los módulos existentes, definir los formularios de búsqueda etc… y todo ello sin tirar ni una sola línea de código. Es fácil, rápido y no hace falta conocimiento técnicos por lo que acerca mucho más a usuarios avanzados la posibilidad de extender el producto.

Modificación de modulos ya existentes
Bien a través del module builder que ya hemos comentado o a través del studio (otra herramienta de desarrollo) podemos fácilmente hacer pequeñas modificaciones en módulos ya existentes, como añadir campos, cambiar los campos de los diferentes formularios, cambiar las búsquedas etc… De nuevo las modificaciones están al alcance de usuarios avanzados sin necesidad de tener conocimientos técnicos.

Integración a través de SOAP o Rest
SugarCRM incorpora una capa de integración a través de soap o rest que permite acceder a las funciones básicas de lectura y escritura de casi todas las entidades desde sistemas externos. Esto permite, por ejemplo, permitir que una aplicación de ecommerce guarde en el CRM información básica del contacto o leer en tiempo real si el cliente tiene incidencias abiertas. Las posibilidades son enormes y sin duda abre muchas alternativas especialmente si usamos SugarCRM como aplicación base de atención al cliente.
Algo más complicado es hacer el proceso contrario. Es decir, que SugarCRM se integre con otras aplicaciones consumiendo sus servicios web o API. Ya incluye un cliente SOAP, pero este tema requiere picar código y entrar a saco en las tripas de SugarCRM.

También tiene cosas malas
Hasta ahora parece que la gente de Sugar me ha pagado por hacer el artículo, pero esta vez no ha habido suerte, a ver si para la próxima… Y como no todo podía ser perfecto, hay una serie de cosas que no me ha gustado especialmente. Algunas de ellas son:

  • complejidad de programación de las vistas. Cuando simplemente quieres usar vistas estándar de visualización o edición de datos de una tabla, todo va sobre ruedas. Pero si queremos programar una vista algo distinta, tenemos que entrar a las tripas y nos encontramos con que la funcionalidad está muy disgregada entre diferentes archivos de configuración, vistas y controllers, un poco caos hasta que tienes muy claro cómo funciona Sugar.
  • la aplicación no brilla por su rendimiento. Hasta ahora he hecho pruebas con pocos registros y no es demasiado rápida, pero tengo serias dudas de su rendimiento con más de un millón de clientes y decenas de millones de emails, llamadas, etc…

En general es un buen producto y me parece bastante recomendable como punto de partida para gestionar la relación con clientes y proveedores. Espero que este primer análisis sea útil.

Atención al cliente proactiva


Este año los Reyes Magos han traído regalos tecnológicos en casa. Bueno, como casi todos los años. En este caso nos han “sorprendido” con un Samsung Galaxy Tab para mi mujer y un iPad 3G para mi (desde el que estoy escribiendo). Como tenía la intuición de lo que nos iban a traer, el día 5 de enero me acerqué a una tienda Movistar para pedir dos multisim y así poder compartir la conexión de datos con los móviles que ya tenemos. Total, todo listo para poder disfrutar de los regalos desde primera hora del día.

Llegó el día de reyes y rápidamente nos pusimos mano a mano con nuestros “juguetes” nuevos, pero nos llevamos una gran desilusión al no poder usarlos al 100% por diferentes motivos. El Galaxy Tab comprado libre en FNAC estaba bloqueado para su uso con algún operador y no funcionaba con Movistar y la multisim tipo microsim para el iPad no estaba activa. Como siempre en estos casos, cogí el móvil y puse sendos tweets de queja con los hashtags correspondientes. La respuesta que obtuve fue completamente diferente y quiero compartir con vosotros mi conclusión.

FNAC se puso en contacto conmigo de manera proactiva a través de su cuenta de atención al cliente de twitter para darme una solución. Además se volvieron a poner de nuevo en contacto conmigo pasados unos días para saber si el problema se había solucionado. Es decir, usaron los nuevos canales de relación con el cliente para ser proactivos y dar una solución a un problema. Quedé muy satisfecho y sin duda han conseguido fidelizar a un cliente. Muy bien!

Movistar no hizo caso de mis quejas por twitter. Es más, la atención al cliente proporcionada por teléfono tampoco me solucionó el problema en ninguna de las diez llamadas que he hecho en los últimos 12 días, que es el tiempo que han tardado en activar la multisim, cuando deberían haberlo hecho en 24 horas. Sin duda han perdido la oportunidad de demostrar que cumplen lo que dicen cuando llamas al 1004, aquello de “… Y me comprometo a buscarle la mejor solución”. Otro cliente descontento con Movistar. Muy mal!

Mi conclusión es que hoy en día hay que llevar la atención al cliente a aquellos foros donde se encuentren nuestros clientes y ser proactivo en la escucha y en aportar soluciones a problemas. Twitter, Facebook, foros, etc… deberían ser hoy canales habituales de relación con clientes.

Cada vez más empresas entienden la fuerza y capacidad de los medios sociales como herramientas de marketing, pero pocas todavía lo entienden como herramientas de atención al cliente. En el caso de twitter las empresas deberían tener varias cuentas (comunicación, marketing, atención al cliente, etc…) y en el caso de Facebook los equipos de atención al cliente deberían tener acceso a las páginas corporativas para poder atender de manera online. Creo que no tardaremos mucho en ver perfiles de community managers adaptados a atención al cliente.

Si estuviera involucrado en un negocio con atención al cliente no dudaría en ser proactivo en todos los canales posibles.

Entrevista en Hoy en Madrid


El pasado 26 de noviembre tuve la oportunidad de participar en el espacio de emprendedores del programa Hoy en Madrid de OndaMadrid. Y tuve esta oportunidad gracias a Enrique O’Connor que es quien está coordinando los invitados que participan en el programa. Grandísimo trabajo el que está haciendo Enrique de ayuda y promoción de proyectos y emprendedores y muy importante el apoyo que poco a poco nos brindan los medios como OndaMadrid. Espero que puedan seguir haciéndolo mucho tiempo y muchos otros emprendedores puedan beneficiarse de esta gran oportunidad.

El programa se complementa con el blog emprendeahora.com, donde van publicando con antelación los siguientes invitados, dando la opción de mandar tus preguntas para que se puedan tratar en antena. Aquí os dejo el enlace al post sobre mi entrevista y el audio de la misma.

Para mi fue una experiencia nueva el participar en un programa de radio en directo. En OndaMadrid todo el mundo me trató perfectamente y sin duda disfruté mucho del momento, aunque se me hizo muy corto. Cuando quise darme cuenta ya se había pasado el tiempo y la entrevista llegaba a su fin.

Espero que esta no sea el último programa de radio en el que participo y pueda seguir hablando de tagUin, red social para videojuegadores, en más medios.