Cuando comenzamos a trabajar en Sopunto, la parte técnica no era nuestro principal problema. Sabíamos desarrollar landing pages, sitios corporativos, automatizaciones, integraciones y aplicaciones a medida. También teníamos experiencia diseñando interfaces, levantando requerimientos y convirtiendo procesos manuales en sistemas que pudieran utilizarse de verdad. Lo difícil era responder una pregunta mucho más básica: ¿qué negocio estábamos construyendo con todas esas capacidades? Tener muchas cosas que ofrecer puede parecer una ventaja, pero también puede convertirse rápidamente en una forma bastante eficiente de no tener ningún foco. Una empresa puede presentarse diciendo que hace páginas web, aplicaciones, diseño, inteligencia artificial, automatizaciones, consultoría y prácticamente cualquier otra cosa que suene digital. El problema aparece cuando un posible cliente intenta entender por qué debería contratarla, para qué tipo de problema es especialmente buena o qué la diferencia de las otras veinte empresas que dicen exactamente lo mismo. Nuestra primera definición de Sopunto se parecía más a una lista de servicios que a un modelo de negocio. Podíamos explicar qué éramos capaces de construir, pero todavía no habíamos resuelto con suficiente claridad para quién queríamos hacerlo, qué resultado esperaban esas personas y cómo podíamos entregar ese valor de una manera sostenible. Para ordenar esas preguntas utilizamos el Business Model Canvas.

Qué es el Business Model Canvas y para qué sirve

El Business Model Canvas es una herramienta visual para describir, diseñar y cuestionar un modelo de negocio. Organiza la empresa en nueve bloques relacionados entre sí: segmentos de clientes, propuesta de valor, canales, relaciones con clientes, fuentes de ingresos, recursos clave, actividades clave, socios clave y estructura de costos. Su utilidad no está solamente en resumir el negocio en una página, sino en permitir que sus diferentes partes se observen como un sistema. Esa relación entre los bloques es importante porque un modelo de negocio no funciona como una colección de respuestas independientes. Una fuente de ingresos tiene que venir de un segmento de clientes que esté dispuesto a pagar por una propuesta de valor concreta. Esa propuesta necesita actividades y recursos para poder entregarse, y todo ese trabajo genera costos. Esto parece obvio cuando se explica de esa manera, pero es muy fácil perderlo de vista cuando estamos entusiasmados con una idea. Podemos imaginar una aplicación técnicamente interesante sin saber cómo conseguirá usuarios. Podemos definir una suscripción mensual sin comprobar que el servicio entregue valor todos los meses. También podemos decidir que nuestro cliente será “cualquier pyme” y descubrir más adelante que ese grupo incluye negocios con problemas, presupuestos y formas de comprar completamente diferentes. El Canvas no resuelve esas contradicciones por nosotros. Lo que hace es dejarlas a la vista, que ya es bastante más de lo que ocurre cuando las ideas están repartidas entre conversaciones, documentos, mensajes de WhatsApp y una planilla llamada modelo-negocio-final-ahora-si-v3.xlsx.

El primer problema de Sopunto: podíamos hacer demasiadas cosas

Nuestro punto de partida estaba definido por las capacidades del equipo. Sabíamos crear sitios, sistemas internos, formularios, paneles administrativos, integraciones y automatizaciones. Desde una perspectiva técnica, eso tenía sentido. Desde la perspectiva del cliente, sin embargo, seguía faltando una explicación. Un negocio no suele comenzar el día pensando que necesita una integración mediante API. Lo que sabe es que alguien está copiando información desde una plataforma hacia otra varias veces por semana y que, tarde o temprano, ese proceso termina con un dato incorrecto. Un consultor tampoco sueña necesariamente con tener una landing page. Lo que quiere es explicar mejor su servicio, recibir solicitudes de personas interesadas y dejar de coordinar cada reunión intercambiando ocho mensajes para encontrar un horario disponible. Esa diferencia fue uno de los primeros aprendizajes importantes. Nosotros pensábamos en soluciones porque veníamos del mundo del desarrollo, mientras que el cliente pensaba en problemas, aunque no siempre los formulara de esa manera. Podía pedir una página web, pero lo que realmente necesitaba era generar confianza. Podía pedir una aplicación, cuando su necesidad inmediata era ordenar un proceso. Podía pedir una automatización, aunque todavía no tuviera claro qué pasos del proceso debían mantenerse y cuáles convenía eliminar. Por eso el Canvas nos obligó a dejar de describir Sopunto exclusivamente mediante lo que podíamos construir. Las funcionalidades son importantes, pero no constituyen por sí solas una propuesta de valor. Decir que una plataforma tiene usuarios, notificaciones y un panel administrativo explica cómo funciona. Explicar que permite reducir el tiempo dedicado a coordinar reservas aclara por qué alguien podría querer utilizarla.

Nuestro cliente no podía ser simplemente “una pyme”

En una de las primeras versiones del Canvas, nuestros segmentos incluían emprendedores, profesionales independientes, pequeñas empresas, restaurantes, clínicas, tiendas y negocios que trabajaban mediante Excel o WhatsApp. Era una lista lo bastante amplia como para que casi cualquier empresa de Chile pudiera sentirse incluida, lo que también significaba que no nos ayudaba demasiado a tomar decisiones. Una clínica que necesita gestionar horas y pacientes tiene un problema diferente al de una empresa industrial que recibe solicitudes de cotización. Un profesional independiente puede contratar una landing para presentar un servicio específico, mientras que una organización con varias áreas probablemente necesite una arquitectura de contenidos mucho más amplia. Aunque todos puedan describirse como negocios que requieren apoyo digital, no evalúan las soluciones del mismo modo ni esperan el mismo tipo de relación. Comenzamos entonces a observar los segmentos no solamente por rubro o tamaño, sino también por la situación en la que se encontraban. Nos interesaban negocios que ya tuvieran una operación real, pero cuya experiencia digital no estuviera a la altura de esa operación. Empresas que entregaban un buen servicio, aunque su sitio no fuera capaz de explicarlo. Profesionales que dependían de recomendaciones, correos y mensajes para organizar actividades que podrían resolverse de una forma mucho más simple. También aparecía otro grupo: empresas que habían crecido utilizando herramientas manuales hasta llegar al punto en que esas herramientas comenzaban a mostrar sus límites. Excel, el correo y WhatsApp pueden sostener una parte importante de una operación, y no tiene sentido reemplazarlos solo porque existan tecnologías más nuevas. El problema comienza cuando la información se duplica, los procesos dependen de la memoria de una persona, nadie sabe cuál es la última versión de un archivo o una tarea sencilla requiere revisar cuatro conversaciones distintas. Esto nos ayudó a formular un segmento más concreto: negocios en crecimiento que tienen una necesidad digital identificable y para los cuales podemos proponer una solución proporcional. No significa que todos tengan que necesitar software a medida. De hecho, una parte importante del trabajo consiste en reconocer cuándo no lo necesitan.

La propuesta de valor debía explicar nuestro criterio

Una de las primeras formas en que describimos Sopunto fue como un nexo entre el diseño y el desarrollo de software. La idea representaba algo que habíamos visto muchas veces: sitios visualmente atractivos que no ayudaban al negocio a conseguir nada y sistemas técnicamente funcionales que parecían diseñados sin considerar a la persona que tendría que utilizarlos. No queríamos elegir entre una solución bonita y una solución útil. Nuestra intención era combinar diseño, tecnología y comprensión del negocio para crear algo que pudiera utilizarse, mantenerse y cumplir una función concreta. Sin embargo, esa explicación todavía estaba demasiado centrada en cómo trabajábamos y no necesariamente en lo que recibía el cliente. Durante este proceso aparecieron principios que siguen siendo importantes para nosotros, como vender soluciones en lugar de humo y acompañar al cliente hacia una alternativa mejor pensada como producto. El desafío estaba en convertir esas ideas internas en una propuesta comprensible para alguien que no vive hablando de experiencia de usuario, arquitectura o automatización. La definición comenzó a tomar forma cuando dejamos de presentar cada servicio como un producto aislado. Sopunto no tenía que ser solamente una empresa que vendiera páginas o software. Podía ser una empresa que entendiera un problema y recomendara una solución digital adecuada para ese problema, incluso cuando la solución fuera más pequeña que la imaginada inicialmente. Esto cambia bastante la conversación comercial. Si una persona necesita comenzar a recibir reservas, tal vez pueda resolver la primera etapa con una landing, una agenda conectada y correos automáticos. No tendría mucho sentido construir desde cero una plataforma con usuarios, calendarios y notificaciones antes de comprobar que existe una demanda real. En cambio, si una empresa necesita distintos permisos, trazabilidad, estados, documentos e integraciones, probablemente ya estamos frente a un problema que requiere software a medida. Nuestra propuesta de valor, por lo tanto, no consiste en vender siempre el proyecto más grande. Consiste en entender qué parte del negocio necesita mejorar y construir algo acorde con ese momento, ese problema y esa capacidad de inversión.

Los canales debían formar un recorrido y no solamente una lista de contactos

En el bloque de canales escribimos inicialmente alternativas bastante evidentes: sitio web, correo, WhatsApp, recomendaciones y reuniones. Todas podían servir para comunicarse con un cliente, pero el Canvas nos llevó a preguntarnos algo distinto: ¿cómo pasa una persona desde no conocer Sopunto hasta considerar que podemos ayudarla? Ese recorrido comienza normalmente antes del formulario de contacto. Una empresa detecta que algo no está funcionando bien, aunque todavía no sepa cómo nombrarlo. Luego encuentra una recomendación, un artículo, un mensaje o un caso parecido al suyo. Recién después revisa nuestros servicios, intenta entender cómo trabajamos y decide si vale la pena iniciar una conversación. El blog forma parte de ese proceso. No esperamos que alguien termine de leer un artículo sobre el Canvas y contrate inmediatamente un sistema administrativo. Su función es mostrar cómo analizamos un problema, qué preguntas hacemos y por qué no comenzamos ofreciendo una tecnología antes de entender la situación. Este enfoque también cambia el tipo de contenido que tiene sentido publicar. En lugar de escribir artículos genéricos sobre tendencias tecnológicas, podemos utilizar experiencias reales para explicar decisiones que otros negocios también enfrentan: cuándo conviene una landing, qué incluye una mantención, cómo reconocer un proceso automatizable o por qué una aplicación no siempre es el mejor punto de partida.

La relación con el cliente debía ser cercana, pero también clara

Otro bloque relevante fue la relación con clientes. Desde el comienzo sabíamos que no queríamos funcionar únicamente como ejecutores de una lista de requerimientos. El cliente conoce su negocio mucho mejor que nosotros, pero eso no significa que la primera solución que imagine sea necesariamente la más conveniente. Parte de nuestro trabajo consiste en preguntar por qué necesita algo, quién lo utilizará, qué ocurre actualmente y qué resultado espera obtener. Esas preguntas no buscan complicar el proyecto, sino evitar que terminemos construyendo correctamente la solución equivocada. La relación consultiva también tiene un límite. Acompañar a un cliente no debería significar hacerlo dependiente de nosotros para siempre. Debe saber qué se construyó, qué accesos posee, qué servicios externos utiliza, cuáles son sus costos y qué ocurriría si en algún momento decide trabajar con otro proveedor. La cercanía sin transparencia puede transformarse fácilmente en dependencia, y ese no es el tipo de relación que queremos construir. Por eso el acompañamiento debe convivir con alcances claros, entregables comprensibles y condiciones comerciales que expliquen qué está incluido. La confianza no se construye prometiendo que todo será fácil, sino permitiendo que cada parte entienda qué se está haciendo y por qué.

Ingresos, costos y la parte menos romántica del modelo

Cuando uno piensa en comenzar una empresa de software, es bastante más entretenido hablar de productos, diseño e innovación que de reuniones no cobradas, licencias, soporte, impuestos y horas destinadas a corregir algo que parecía pequeño. El bloque económico del Canvas existe precisamente para recordar que una buena idea también tiene que sostenerse. La fuente de ingreso más evidente para Sopunto era el desarrollo por proyecto. El cliente contrata un alcance, se define una forma de pago y se construye una solución. Sin embargo, después de la entrega pueden aparecer necesidades reales de continuidad: infraestructura, dominio, soporte, correcciones, nuevas funcionalidades, monitoreo o mejoras. El punto importante era no agrupar todas esas cosas bajo una palabra ambigua como “mantención”. Un pago recurrente debería corresponder a un servicio recurrente. Si existe hosting, soporte o administración técnica, debe explicarse. Si no hay una actividad continua, cobrar mensualmente solo porque el modelo de suscripción está de moda no mejora el negocio; solamente lo vuelve más difícil de justificar. El Canvas también nos hizo mirar los costos menos visibles. El precio de un proyecto no se transforma automáticamente en utilidad. Antes de entregar una solución hubo investigación, reuniones, diseño, desarrollo y pruebas. Después puede existir documentación, despliegue, soporte y coordinación. A eso se suman las herramientas, la infraestructura, la administración y el tiempo comercial necesario para conseguir el siguiente proyecto. Esta revisión es importante porque una funcionalidad aparentemente pequeña puede esconder bastante complejidad. Agregar un botón puede ser sencillo. Conseguir que ese botón valide información, consulte un proveedor externo, registre la operación, controle errores y notifique correctamente ya es otra historia.

Los recursos y actividades clave no se reducían al código

En nuestro Canvas, los recursos clave incluían conocimiento técnico, diseño, herramientas, infraestructura y componentes reutilizables. Con el tiempo entendimos que también debíamos considerar recursos menos evidentes, como el criterio para definir alcances, la capacidad de comprender procesos, la documentación, la marca y la disponibilidad real del equipo. En una empresa de servicios, el tiempo es un recurso especialmente delicado. Podemos tener la capacidad técnica para aceptar varios proyectos y, aun así, no tener la capacidad operativa para ejecutarlos con el nivel de cuidado que prometemos. Un calendario lleno no siempre es señal de un negocio saludable; a veces solo significa que nadie calculó correctamente cuánto trabajo había detrás de cada entrega. Algo parecido ocurrió con las actividades clave. Al principio era tentador resumirlas como diseñar y desarrollar software. En la práctica, un proyecto comienza bastante antes del código y termina bastante después. Hay que investigar, comprender el problema, definir usuarios, delimitar el alcance, diseñar, desarrollar, probar, desplegar, documentar y acompañar la puesta en marcha. Además, Sopunto necesita actividades que no están ligadas a un proyecto específico: encontrar oportunidades, preparar propuestas, hacer seguimiento, registrar aprendizajes y mejorar la oferta. Si toda la capacidad se destina solamente a producir, tarde o temprano deja de existir un flujo comercial que sostenga el trabajo.

Los socios clave también forman parte de la solución

Ninguna solución digital existe completamente aislada. Incluso un sitio relativamente sencillo puede depender de un proveedor de dominio, hosting, correo, analítica, formularios o agenda. Un sistema más complejo puede sumar servicios de almacenamiento, pagos, autenticación, notificaciones e infraestructura en la nube. Estos proveedores permiten construir soluciones mejores y más rápidas, pero también introducen dependencias, condiciones y costos. Por eso el bloque de socios clave no puede completarse simplemente escribiendo “proveedores tecnológicos”. Necesitamos comprender qué función cumple cada uno, cuánto cuesta y qué ocurriría si cambia sus precios o deja de prestar el servicio. Este análisis también ayuda a comunicar mejor las propuestas. Si una solución depende de una agenda externa o de una pasarela de pago, el cliente debe saberlo. El costo de desarrollar una integración no elimina las tarifas del servicio integrado. Es mejor aclararlo al comienzo que descubrirlo después, cuando la plataforma ya está lista y alguien pregunta por qué apareció una nueva suscripción en la tarjeta.

Lo que realmente aprendimos del Canvas

El principal aprendizaje no fue completar correctamente nueve bloques. Fue entender que el modelo debía tener una lógica completa. Los clientes, la propuesta, los canales, las actividades y los ingresos tenían que describir el mismo negocio, no cinco versiones diferentes de lo que nos gustaría que Sopunto fuera. También aprendimos que una lista de servicios no reemplaza una propuesta de valor. Decir que hacemos landings, automatizaciones y software ayuda a comprender nuestras capacidades, pero no explica el resultado que buscamos producir. La propuesta aparece cuando conectamos esas capacidades con un problema concreto. Otro aprendizaje fue que el Canvas contiene hipótesis, no certezas. Escribir que nuestro cliente ideal es un negocio en crecimiento no convierte automáticamente a todos esos negocios en buenos clientes. Esa idea debe probarse mediante conversaciones, cotizaciones, proyectos, rechazos y resultados. Algunos segmentos mostrarán mejor encaje que otros, ciertos servicios serán más rentables y algunas propuestas que parecían evidentes terminarán descartándose. Por eso un Canvas no debería completarse una vez y quedar archivado como evidencia de que hicimos planificación estratégica. Tiene sentido revisarlo cuando aparecen nuevos aprendizajes. Si el modelo sigue exactamente igual después de hablar con clientes y ejecutar proyectos, probablemente no estamos prestando suficiente atención a lo que está ocurriendo.

Cómo aplicar bien un Business Model Canvas

La mejor forma de utilizar el Canvas es escribir situaciones concretas en lugar de conceptos demasiado amplios. “Empresas que quieren digitalizarse” puede incluir prácticamente a cualquier organización. “Consultoras que coordinan reuniones manualmente y pierden tiempo buscando horarios” describe una situación que podemos observar, investigar y resolver. También conviene separar los problemas de las soluciones. “Agenda online” no es un problema; es una posible herramienta. El problema puede ser que un profesional dedica varias horas a la semana a coordinar reuniones. Una vez que entendemos eso, podemos evaluar si la respuesta correcta es una agenda, un formulario, una automatización o un cambio más sencillo en el proceso. Después de completar los bloques, hay que buscar contradicciones. ¿El segmento tiene capacidad para pagar? ¿El canal realmente llega a esas personas? ¿La fuente de ingresos cubre las actividades y costos? ¿La propuesta depende de recursos que todavía no tenemos? ¿Existe un proveedor del que dependa una parte demasiado importante del servicio? Finalmente, las hipótesis más riesgosas deberían convertirse en pruebas pequeñas. Antes de desarrollar una plataforma completa, podemos validar una propuesta con una landing. Antes de automatizar toda una operación, podemos probar una parte del flujo. Antes de asumir que una empresa pagará una mantención mensual, debemos entender qué servicio continuo considera realmente valioso.

Un modelo para decidir qué vale la pena construir

El Business Model Canvas no nos entregó una respuesta definitiva sobre Sopunto, pero nos ayudó a ordenar la conversación. Nos obligó a pasar desde “estas son todas las cosas que podemos hacer” hacia preguntas bastante más útiles: qué problemas queremos resolver, para qué negocios podemos hacerlo bien, cómo llegaremos a ellos y qué necesitamos para sostener el trabajo. También nos dejó una idea que hoy parece obvia, aunque al comienzo no siempre lo era: la tecnología debería aparecer como consecuencia del problema y del modelo de negocio. No tiene sentido comenzar por una aplicación si todavía no sabemos quién la necesita, qué valor recibirá o cómo se sostendrá después de su lanzamiento. A veces la solución será una página sencilla. En otras ocasiones será una automatización o una integración. También habrá problemas que justifiquen desarrollar una plataforma completa. El trabajo no consiste en utilizar siempre la tecnología más compleja, sino en reconocer cuál es suficiente para producir un cambio real. Eso es, finalmente, lo que el Canvas aportó a Sopunto. No convirtió una idea en un negocio de forma automática, pero nos dio una estructura para discutirla, detectar vacíos y tomar decisiones con algo más de criterio que el entusiasmo inicial. Y cuando uno está comenzando un proyecto, tener una herramienta que obligue a pensar antes de construir ya es una ventaja bastante importante.