496 | Los 10 dolores de cabeza al gestionar webs de membresía (y cómo resolverlos)

En el episodio 496 de WordPress semanal repasamos los 10 dolores de cabeza más habituales cuando gestionamos una web de membresía. Y lo mejor de todo, te voy a contar cómo solucionarlos de forma práctica. Vamos allá. Hola, hola. Soy Gonzalo Navarro y Bienvenidos al episodio 496 de WordPress Semanal, el podcast en el que aprendes a crear y gestionar tus propias webs con WordPress en profundidad. Y hoy vamos a ver 10 problemas que te puedes encontrar por el camino cuando gestionas una web de membresía y que pueden llegar a ser un verdadero dolor de cabeza. Así que te voy a intentar guiar por las soluciones de cada uno de ellos, pero antes, como siempre, novedades. ¿Qué está pasando en Gonzalo Navarro es esta semana? Pues tenemos nuevo vídeo de la zona código y en él aprendes a bloquear el acceso desde fuera a tu web a no ser que se inicie sesión. Es decir, logramos crear una intranet pero sin plugins. Simplemente copias el código, lo pegas, le cambias los detalles que necesites, porque hay veces que sí que vas a querer algunas páginas visibles y lo tienes. Por cierto, en ese vídeo comento que si quieres un mini plugin chiquitito con algunas opciones de configuración directamente desde el panel de admin, porque al final este plugin digamos que tiene su código, pues en algunos casos va a ser más sencillo que lo gestiones desde un pequeño panel de ajustes y no tanto desde tu plugin de funciones o donde sea que tú pegas el código. Así que escribidme desde vuestra cuenta o por la comunidad privada de Telegram, por donde queráis. Y si interesa, pues también lo convierto en un pequeño plugin para que podáis descargar en la zona de recursos. Siguiente novedad, estoy terminando de grabar el curso de Generate Blogs y lo que voy a hacer es que voy a ir publicando las clases poco a poco conforme las vaya teniendo, porque me queda una parte de edición, entonces las voy a ir sacando para que podáis acceder a las clases del curso cuanto antes y no esperar a que lo tenga ya todo editado. Este es uno de los cursos con más votos, ya sabéis que podéis proponer los cursos que queráis. Y luego en la comunidad privada de Telegram pues voy preguntando o más bien sacando votaciones cada cierto tiempo para ver cuál preferís que salga antes. Todo esto que comento lo tenéis en Gonzalo Navarro es y si no en las notas de este episodio podéis verlo. Si vuestra app de podcast no muestra bien los enlaces, pues entonces GonzaloNavarro es 496 que esas son las notas del episod en mi web, con todo el contenido, todos los enlaces y todo muy a mano. Y ahí mismo también encontraréis el enlace al plugin de la semana que se llama Easy Action Scheduler Cleaner. Este plugin es novísimo y ayer echando un vistazo por Twitter vi que lo recomendaba Jose Conti y vi que era de Fernando Tellado de Ayuda WordPress puntocom y básicamente él comentaba que lo usa para sus clientes y es un limpiador del programador de acciones, que esto sobre todo es útil cuando llevas webs hechas con woocommerce, entonces puedes borrar pues de las muchísimas acciones transitorias que lleva a cabo WordPress, pues las que ya han terminado o no sirven para nada, pues borrarlas. Por ejemplo, las acciones completadas, es decir, las que ya se han ejecutado correctamente, las fallidas que han dado algún error durante la ejecución, las canceladas, las vencidas, las pendientes, pero que son muy antiguas y con mucha probabilidad no se van a necesitar ejecutar, o registros históricos que se van acumulando, porque todo esto a pesar de que una acción empiece y acabe o que se quede ahí, que no continúe, es información que se queda guardada en la base de datos. Entonces en una web grande puede llegar a acumularse muchísimo y a dar problemas de espacio y de rendimiento. Así que lo dejo enlazado, también está en español el plugin, se llama Limpiador sencillo del programador de acciones. Básicamente es la traducción de lo que te he comentado al principio en inglés. Y si no, pues tienes el enlace como digo en las notas. Venga, pues ahora sí, vámonos con el tema central del episodio, los 10 dolores de cabeza al gestionar webs de membresía y cómo resolverlos. Y vámonos con el número uno, que son los pagos fallidos, pero que permiten a los usuarios seguir accediendo a su contenido. Ya sabéis, cuando tú tienes una web de membresía, normalmente vas a restringir un cierto contenido a unos pagos. No tiene por qué ser recurrente la membresía, pero habitualmente lo es. Entonces si alguien por lo que sea deja de pagar o le falla un pago porque le ha fallado la tarjeta o porque no tiene fondos, pues puede ocurrir que pese a ello siga teniendo acceso a los contenidos y no debería. ¿Cuál es la solución de esto? Bueno, la solución pasa por, por supuesto utilizar un plugin fiable tipo Restrict Cont, woocommerce Subscriptions, Paid Membership Pro, Easy Restrict y aquí en su configuración destaco dos aspectos importantes que pueden hacer que esto te esté pasando. Uno es que no tengas correctamente configurados los webhooks, ya sea de Stripe o de Paypal o la pasarela que uses. El webhook lo que hace es asegurarse de que la información entre lo que ocurre en tu pasarela de pago y la web esté correctamente conectada, de modo que si hay un pago fallido, eso esté sincronizado entre ambas partes, la pasarela de pago y tu plugin de membresía, o si tú cancelas, imagínate que cancelas manualmente desde uno de los dos lados, bien desde tu web o bien desde Stripe, pues que eso esté vinculado. Esto es lo que permite el webhook, la conexión entre todas las acciones y todos los estados que se dan entre estas dos partes, ya digo, el plugin de membresía y tu pasarela de pago. Esto es una de las cosas más habituales. Pero también me he encontrado con otra casuística, de hecho a mí me ha pasado, y es que algunos plugins de restricción de contenido, como puede ser Restrict Content Pro y otros, pues tienen un shortcode y tú ese shortcode lo puedes utilizar de distintas formas y puede tener parámetros y configuraciones. ¿Entonces me pasó concretamente en WordPress puntocom, que fue esto? Fue un negocio ya funcionando que yo compré, es una bolsa de empleo que pone en contacto a profesionales WordPress con personas que necesitan a profesionales WordPress y uno de los antiguos miembros me contactó avisándome de que él ya no era miembro, pero que podía seguir accediendo, no me acuerdo a qué era, no sé si era una zona de descargas, pero bueno, podía seguir accediendo a algo o incluso a ver las ofertas de empleo que no debería, si no paga no debería de poder acceder a ellas. Y es que la persona que llevaba antes esa web había dejado un shortcode que sí que restringía ese acceso a una membresía concreta, pero no especificando que esa membresía debía estar activa. Entonces todo el que lo hubiese comprado antes, independientemente de que siguiera pagando o no tenía acceso. Y menos mal que este usuario me avisó, porque al final yo veía el shortcode, parecía que todo estaba correcto, pero no. Y como yo ya había visto esto en el pasado, no con Restrict Content Pro, pero sí con Easy Digital Downloads, que es el plugin originalmente del mismo creador y que con su extensión de restricción de contenidos el comportamiento era muy similar, pues esto yo ya lo había visto en una web anterior hacía años. Y entonces en cuanto me avisó este suscriptor o antiguo suscriptor, yo ya sabía que podía ir por ahí el tema y fue lo primero que miré y efectivamente ese era el problema. Entonces bueno, si os pasa algo por el estilo, además de por supuesto el webhook, que puede que suele ser algo bastante habitual e importante, pues también revisad que lo que sea que uséis para restringir esté configurado para que lo haga a suscripciones activas. Perfecto. Vámonos con el segundo dolor de cabeza. Son los emails críticos que no llegan a su destino. Esto es muy habitual no solo en webs de membresía, sino en webs de ecommerce o incluso en cualquier tipo de web con WordPress. Imagínate un email de bienvenida, un email de renovación, de cancelación, que no llegan, que no llegan a su destino, a su usuario. Pues puede ser un desastre. Primero tienes a la gente, a los usuarios totalmente desinformados y luego puede llevar un soporte saturadísimo. Aunque si te encuentras muy saturado con el soporte precisamente por esto, pues básicamente te lo están diciendo que lo tienes que arreglar. Entonces la solución es sencilla, tienes que configurar un sistema de SMTP, es decir, un sistema de envío propio y no depender del que hace WordPress automáticamente, porque tarde o temprano va a fallar. Hay veces que falla desde el principio en una web con WordPress, pero otras veces acaba fallando con el tiempo. Y lo único que tienes que hacer, como digo, es utilizar un plugin que te permita configurar esto. Te voy a dejar un enlace, es un plugin gratuito que está bien, si no puede ser, si por ejemplo utilizáis Ase Agua se Pro también tiene una parte para configurar esto lo vemos en el curso, pero si buscáis un plugin específico, os dejo uno que a mí me gusta, es el que suelo utilizar y va acompañado de un episodio del podcast donde explico su uso y luego un vídeo que si eres suscriptor, si eres miembro lo puedes ver, pero vamos, no es muy complicado y básicamente lo que le estás diciendo es los envíos quiero que se hagan a lo mejor desde tu servidor o con un servicio especializado, que esto es lo que mejor funciona. Si tu web manda muchísimos emails puedes contratar un pequeño servicio como Sendgrid o hay otros que están pensados para esto, para que tú configures en un plugin y los envíos se hagan desde ahí y así te asegures de que no fallen nunca y si fallan lo vas a ver porque este plugin, los plugins de este tipo te muestran un registro de si los correos que se han enviado de forma automática han llegado a su destino o no y en el caso de que no, podrías darle a reintentar o podrías investigar un poco, muchas veces es que los usuarios te dan un correo que no existe o tienen el buzón lleno o algo de eso, pero bueno, ahí ya poco puedes hacer más allá de intentar contactarles por otro método, que por cierto yo cada vez me estoy inclinando más a pedir algún otro tipo de contacto teléfono para poder escribirles por WhatsApp o incluso alguna red social para que les puedas escribir por ahí en el caso de que el email que te dieran tenga algún error o ya digo, buzón lleno o alguna historia de estas. Tercer dolor de cabeza, olvido de contraseñas por parte de los usuarios ¿Por qué puede ser un dolor? Pues porque te escriben, mira no puedo entrar, mi contraseña no funciona, lo que sea. ¿Entonces aquí qué es lo que puedes hacer? Pues estar pendiente del soporte y generarles tu contraseña, explicarles cómo la pueden generar ellos, decirles que después la pueden cambiar cuando inicien sesión desde su cuenta o si te quieres evitar todo esto, pues porque hay algunos tipos de webs, dependiendo del público al que vas o del tipo de servicio, donde es más habitual todavía que la gente olvide sus credenciales. Entonces en estos casos puedes probar habilitando un login social, lo típico de que inicias sesión con tu cuenta de Google, de Apple o de Amazon o también está bien esto del login mágico, del Magic Login, que es básicamente que tú le das al visitante la opción de iniciar sesión o con su usuario y contraseña si la recuerdan o con un botoncito que pone envíame un enlace de acceso y entonces pone su. Lo que sí se tiene que acordar es de su correo, claro, pone su correo, el correo con el que está registrado, le llega un enlace y ahí puede hacer clic y entrar. Es temporal por supuesto, pero puede entrar. Os dejo un plugin que me gusta, que lo probé el otro día para el login mágico, lo pongo enlazado, se llama, si no, si no quieres ir a las notas, se llama Magic Login básicamente. Sí, hace poco iba a poner un ejemplo porque hace poco vi un servicio que lo hacía, no sé si era Notion o alguno de este tipo, pero bueno, es cada vez más habitual. Venga, vámonos con el cuarto dolor de cabeza, los conflictos con la caché. Y en el caso de las webs de membresía, aquí lo que puede ocurrir es que los usuarios logueados vean contenido que no le toca, ya sea páginas abiertas que no deberían estarlo o bloqueadas que tampoco deberían estarlo. Entonces esto casi siempre cuando pasa esto tiene que ver con la caché, más allá de que si el usuario es un poquito experto o está acostumbrado a utilizar navegar por web y demás, pues muchas veces si el propio usuario ya limpia la caché de su navegador se soluciona. Pero claro, esto es un rollo, no tendría por qué estar haciendo esto. Así que si esto ocurre lo que puedes hacer es excluir cookies y páginas restringidas de la caché. De hecho hay veces que los plugins de caché tienen una configuración específica para esto, para cuando el usuario está logueado y en algunos casos te marcan directamente que se guarde la caché para usuarios logueados. Entonces si estás teniendo todo este problema, lo que puedes hacer es desmarcarlo. Esto por ejemplo en WordPress Rocket hay una opción para ello y en casi todos los plugins con bastantes opciones de configuración de la caché vas a tener cosas de este estilo, o puede ser que tenga que tengas cachés muy agresivas. Ya sabes que hay muchos tipos de caché y sobre todo las relacionadas con procesos de consulta de base de datos, más relacionada con la venta o con los usuarios y demás, pues pueden dar problemas en este sentido. Y si no sabes muy bien qué tocar para comprobar que viene de esto, desactiva toda la caché que tengas en tu web, ya sea desde un plugin o desde el propio hosting, que muchas veces tú piensas que no hay caché activa y sí está desde el hosting, tienes que irte a tu hosting, a la parte de rendimiento, caché o lo que sea y desactivarlo y ahí prueba si ese problema que había se quita, si es que se quita, es que es de la caché. Entonces ya puedes ir poco a poco, solo activando lo que necesitas para no perder tiempo tocando detallitos. Primero quita todo, asegúrate de que será el problema y ya vas activando poco a poco. Venga, vámonos con el dolor de cabeza número 5, que son las renovaciones bloqueadas por tu pasarela de pago, o casi mejor dicho, por el banco de la persona que se hizo miembro de tu web. Aquí el problema puede llegar a ser que los pagos recurrentes sean rechazados por bancos europeos. ¿Por qué? Porque en Europa hay una normativa que se llama PSD que obliga a utilizar un sistema de verificación. Esto te habrá pasado, pagas en un sitio y en tu aplicación del banco tienes que confirmarlo, más allá de haber puesto el número de tarjeta, el código, que encima lo tienes que generar cada vez que. Eso me parece a mí un rollo total, cada vez que está bien porque es seguridad, pero cada vez que quieres pagar tienes que volver a generar el código del CVC. Pues más allá de eso, en el primer pago tienes que autorizarlo. Pero claro, ¿Qué pasa cuando se va a renovar? ¿Tiene que volver a hacer esa autorización la persona que ya hizo el primer pago, que ya autorizó, que ya puso todos los detalles? No, pero si no utilizas un plugin de membresía que configure correctamente todo esto. Básicamente esto puede pasarte con Stripe, que es cuando se paga con tarjeta. Entonces tienes que asegurarte de que el plugin de membresía utilice la API de Stripe Billing con soporte SCA, que es lo que te comento de esta acción que tienes que hacer en tu aplicación del banco, aceptarlo y también compatible con la actualización automática de tarjetas, porque eso te ayuda cuando la gente le caduca la tarjeta y tiene una nueva. Muchos bancos ya permiten la actualización automática y Stripe es compatible con esto, con lo cual aquí te ahorras muchísimos problemas. La gente muchas veces aprovecha el cambio de tarjeta para no volver a ponerla porque le da pereza y ahí ya has perdido un suscriptor de nuevo, por si vas a usar alguna vez alguna pasarela y quieres revisar esto, la normativa se llama PSD y debes asegurarte que tenga soporte SCA y actualización automática de tarjetas. Si quieres revisarlo, ya sabes, notas del episodio, venga, Dolor de cabeza número 6 evitar que se compartan credenciales. Un usuario paga y Ahora tienes a 10 tíos o tías ahí accediendo a tu contenido. ¿Cómo lo puedes solucionar? Bueno, puedes limitar las sesiones activas o bloquear accesos simultáneos desde IPs diferentes. Lo más sencillo es limitar las sesiones activas, es decir que si una persona está conectada con un usuario que no se pueda conectar ninguna otra. Esto algunos plugins de membresía lo traen, por ejemplo Easy Restrict lo trae, pero vamos es bastante fácil ponerlo por código, en la zona código tenéis un vídeo donde os explico cómo es, simplemente lo copias, lo pegas en tu plugin de funciones o donde tú pegues código y ya está, ya te va a empezar a funcionar y no vas a permitir que en esa web, independientemente que sea de membresía o de lo que tú quieras, se use el mismo usuario a la vez. Dolor de cabeza número 7. Una alta tasa de bajas, lo que se conoce como churn, que la gente llama como quiere Charn Churn, pero bueno si decís tasa de bajas nos entendemos. ¿Cuál es aquí el problema? Pues que puedas ver que de repente los suscriptores se dan de baja súper rápido y aquí asumiendo que lo que ofrece veces es bueno, también es importante cómo lo presentes que des una buena bienvenida a la persona para que sepa todo lo que tiene a su alcance. ¿Cuál es el siguiente paso que tiene que hacer? Dependiendo del tipo de membresía puede ser buena idea ir enviando emails de reactivación o emails cada vez que haya un contenido nuevo y funciona también muy bien al principio ofrecer pequeñas victorias, que la gente ya vea que desde que se ha apuntado eso le está aportando valor, no tiene que ser grandes cosas porque a lo mejor en ese primer mes la persona no tiene mucho tiempo o lo que sea, pero sí que sientas que ya le está mereciendo la pena e incluso algunos de estos problemas de alta tasa de baja puede venir por problemas comentados anteriormente, como por ejemplo que es que no te están funcionando los envíos de correos y no le llega a la persona los emails de bienvenida, esos emails donde le dices que hay contenido nuevo, entonces pueden estar relacionados unos errores con otros. Dolor de cabeza número 8. Tener un soporte súper saturado por preguntas repetitivas. Pues gente que siempre te manda las mismas dudas sobre acceso a la web, sobre facturación, sobre dónde está una cosa u otra, es decir, dudas donde la respuesta va a ser siempre la misma. Pues esto, la solución está clara, que tengas una base de conocimiento, una wiki, unos docs, que crees vídeos rápidos explicando varios detalles, que pongas un chatbot con respuestas automáticas, que esto cada vez es más fácil y te va a aliviar muchísimo trabajo, de hecho en algunos casos va a mejorar la experiencia de tus usuarios. Imagínate un chatbot o una zona bien curada o cuidada de documentación donde la persona encuentra la respuesta en un momento y no tiene que estar esperando a que tú o alguien de tu equipo de soporte le responda. Por cierto te dejo enlace al curso de cómo crear una base de conocimiento en WordPress, lo que se conoce como una wiki y también un curso sobre cómo crear un chatbot con IA en WordPress y muchas más cosas relacionadas con la inteligencia artificial aplicada a WordPress. Dolor de cabeza número 9, problemas con upgrades y downgrades, Es decir, que cuando los suscriptores quieren cambiar de plan que surjan problemas como pagos duplicados o frustración porque no pueden cambiar de plan, ni subir a uno más alto, ni bajar a otro. Y aquí básicamente hay dos o que tengas un plugin con gestión nativa de cambio prorrateado como Restrict Content Pro, Easy Restrict PM Pro o que estés atento para hacer esto manualmente. Yo por ejemplo tengo un sistema que detecta cuando un usuario lleva X meses suscrito y por estadística en algunos casos le envía un email ofreciéndole apuntarse a un plan anual con un descuento, entonces este propio sistema se vincula con Stripe y ya hace el cambio de plan prorrateado. Sin embargo cuando hago por ejemplo oferta, yo casi no hago ofertas, pero por ejemplo en Black Friday si la hago, ahí simplemente lo que mando es un enlace a la suscripción de ese plan con esa oferta, entonces si el cliente ya estaba suscrito anteriormente hago la baja y si encarta pues la devolución de ese mes, porque al final está pasando de un plan mensual a un plan gratuito, entonces con que devuelva el mes o la parte correspondiente del mes que no ha consumido pues ya está. Entonces me voy ese tiempo durante esa campaña sí que estoy pendiente de esto y lo hago manualmente. Esto es porque yo uso Easy Digital Downloads que no está tan preparado para esto si utilizara Restrict Content Pro o algún otro plan de membresía sí que podría hacerlo. Entonces ya digo, están las dos soluciones, o que te venga en el sistema que tú uses o tienes que estar atento para hacerlo de forma manual. Y vámonos con el dolor de cabeza número 10 que es la migración de suscriptores desde otra plataforma. Aquí el riesgo es perder tus usuarios activos cuando quieras cambiar de sistema, ya sea que te pases de algo externo, como por ejemplo ya vimos en otro episodio de Mumbler a WordPress o dentro del propio WordPress que cambies de plugin de membresía. El otro día por cierto en WordPress puntocom hubo una persona que solicitaba precisamente un cambio de este estilo. Entonces la clave aquí es que sobre todo si vienes de un sitio externo, los datos de pago van a estar en la pasarela correspondiente en Stripe, en Paypal, pero no en tu web. Entonces si haces la migración mal, pues puedes perder un montón de suscriptores porque depende de la confianza que tengas con ellos y si les expliques el proceso o no, pero que tengan que volver a suscribirse o que se les llegue a cobrar doble sin querer, pues imagínate la frustración que puede generar eso y puede llevarte a bajas masivas o a muchísimo soporte y tiempo perdido. Entonces, posibles soluciones dependiendo por ejemplo si ya cobrabas con Stripe, ahí vas a tener todos los clientes, sus tarjetas y sus suscripciones activas y siempre y cuando esa cuenta fuese tuya, esa cuenta de Stripe, porque hay veces que incluso tú contratas un servicio externo y ellos cobran con su cuenta de Stripe y luego pasan dinero a tu cuenta de Stripe, o sea que ni siquiera tienes tú el control de esas suscripciones. Si tú no lo tuvieras, Stripe tiene una característica para exportar toda esa información e importarla a otra cuenta distinta, pero claro, tienes que confiar en que esa otra empresa te va a dar esos datos. Por ejemplo Mumbler si te los daba, pero bueno, suponiendo que es tu propia cuenta de Stripe y que tienes ahí todo, la clave es llevar esa información o conectarla con tu nuevo sistema. De hecho muchas veces lo vas a poder hacer desde el propio plugin. Por ejemplo Easy Restrict tiene un importador que conecta Stripe y crea los usuarios en WordPress con una suscripción activa, incluyendo el estado que tuvieran y la próxima fecha de renovación, los métodos de pago y todo. Paid vpro tiene un addon que te permite importar desde Stripe y también asignar planes de forma masiva. Y luego Restrict Content Pro y otros no tienen un importador nativo, pero entonces aquí tienes el paso manual, que es importar los usuarios con un CSV, que los usuarios si los puedes importar y luego vincular manualmente sus suscripciones a las que estén funcionando de forma activa en Stripe. Entonces aquí lo que harías es decir, venga, tengo este usuario, lo añades al plan que sea dentro de Restrict Content Pro y luego editando las opciones de suscripción y de pago, les tienes que poner los mismos ID o los mismos códigos que tengan en Stripe. Esto es un proceso mucho más manual, mucho más tedioso, pero puede llegar a hacerse. Yo haría pruebas con un pequeño grupo de usuarios, por supuesto, comunicaría todo el proceso de cambio a los suscriptores e intentaría por todos los medios que no tuviesen que hacer nada extra. Seguramente este décimo y último dolor de cabeza sea de los más delicados, sí. Así que espero que te haya servido de guía y si quieres tener acceso a todas las formaciones que he ido comentando, más, muchísimas más, ya Sabes, más de 90 cursos publicados, cientos y cientos de vídeos de la zona código, recursos para descargar, acceso a la comunidad privada de Telegram, acceso a soporte conmigo, pues ve a GonzaloNavarro es y apúntate porque no te vas a arrepentir. Nada más por este episodio, nos seguimos escuchando. Adiós.