Caso de sistemas custom Shopify
MP Health: de Squarespace a Shopify con un sistema custom de inventario médico
Cómo una clínica migró a Shopify y conectó cada tratamiento IV vendible con los múltiples componentes de inventario que consume, junto con POS, descubrimiento local y UX móvil.
Publicado
Resumen de lectura
Qué obtendrás de esta guía
Cómo una clínica migró a Shopify y conectó cada tratamiento IV vendible con los múltiples componentes de inventario que consume, junto con POS, descubrimiento local y UX móvil.
Qué demuestra este caso
Cómo Shopify se adaptó a un negocio de servicios donde un tratamiento comprado consume varios componentes físicos y las transacciones también ocurren en clínica.
Para quién es relevante
Negocios de servicios y merchants especializados que evalúan Shopify cuando el modelo estándar de un producto/una unidad no representa la operación real.
MP Health no necesitaba que Shopify se comportara como un catálogo retail convencional. La clínica vende tratamientos IV donde una sola compra puede consumir varios componentes físicos de inventario. Si la tienda únicamente descontara una unidad del “producto final”, el stock visible no representaría lo que el equipo realmente necesita para prestar el tratamiento.
El proyecto migró MP Health de Squarespace a Shopify en un engagement de 4–6 semanas a alcance fijo, creó lógica custom de inventario para paquetes IV, integró Shopify POS para uso en clínica e incluyó SEO local, schema markup y mejoras de UX móvil.
| Resultado del proyecto | Resultado registrado |
|---|---|
| Plataforma de origen | Squarespace |
| Destino | Shopify |
| Plazo | 4–6 semanas |
| Modelo de inventario | Una venta de IV puede descontar varios componentes en tiempo real |
| Comercio en clínica | Shopify POS integrado |
| Adquisición | SEO local y schema |
| Experiencia | Mejoras de UX móvil |
No añadimos una cifra de tráfico, revenue o conversión porque no forma parte del registro verificado del proyecto. El valor de este caso es operativo: el sistema de comercio se adaptó a cómo la clínica consume inventario de verdad.
El problema central era tener una verdad de inventario
El inventario ecommerce estándar suele asumir una relación sencilla: se vende un producto y su cantidad baja en uno.
Un tratamiento IV puede funcionar de otra manera. El cliente compra un servicio o paquete, pero la clínica consume varios componentes físicos para entregarlo. Esos componentes, además, pueden compartirse entre tratamientos distintos.
Si el storefront solo rastrea el paquete vendible, la disponibilidad visible puede separarse de los suministros físicos necesarios para atender la siguiente cita.
Eso genera problemas operativos reales:
- un tratamiento puede parecer disponible aunque falte uno de sus componentes;
- el equipo puede verse obligado a reconciliar ventas y suministros manualmente;
- ventas online y ventas en clínica pueden crear registros de inventario distintos;
- las decisiones de compra de insumos se complican porque el ecommerce no refleja el consumo real.
Para MP Health, la migración tenía que empezar por esta relación de inventario, no por el theme.
Por qué pasar de Squarespace a Shopify tenía sentido
Squarespace puede funcionar bien como sitio orientado a contenido, pero MP Health necesitaba una base de comercio capaz de soportar comportamiento custom de inventario y conectar transacciones online con ventas en clínica.
El cambio a Shopify proporcionó una base transaccional e inventario más adecuada sin renunciar a que el sitio explicara tratamientos, apoyara descubrimiento local y funcionara bien en móvil.
La decisión no fue simplemente “Shopify tiene más funciones ecommerce”. Fue más concreta: la plataforma de destino tenía que modelar la diferencia entre lo que compra el paciente y lo que consume el negocio para entregar el tratamiento.
Ese tipo de requisito es el que debería determinar una migración de plataforma.
Relacionar cada tratamiento con sus componentes
La funcionalidad custom clave era la relación entre un tratamiento IV y los artículos de inventario que utiliza.
Un cliente puede comprar un único tratamiento, pero el evento de fulfilment necesita actualizar varias cantidades. El sistema de comercio debe entender que el artículo vendible no equivale a una sola unidad física de stock.
La lógica custom creó un modelo de descuento en tiempo real: cuando se compra el tratamiento correspondiente, los componentes definidos bajan de inventario según la relación configurada.
No se trata de un bundle visual. El objetivo no es mostrar varios productos juntos, sino mantener el stock alineado con lo que la clínica consume físicamente.
La diferencia importa porque la precisión de inventario afecta directamente a la capacidad de prestar el servicio. Si falta un componente obligatorio, la clínica puede no estar en condiciones de entregar el tratamiento que el storefront presenta como disponible.
Un modelo de stock para ventas online y en clínica
MP Health también necesitaba Shopify POS para uso presencial.
Sin un punto de venta conectado, el negocio podría terminar con dos sistemas parcialmente independientes: uno para compras online y otro para actividad en clínica. Eso debilitaría el valor de la lógica custom porque el consumo de componentes tendría que reconciliarse entre canales.
Integrar Shopify POS llevó las transacciones presenciales al mismo entorno comercial que el storefront online.
Para el cliente final, el beneficio es consistencia. Puede relacionarse con la marca online o en clínica mientras el equipo trabaja desde un registro de comercio más unificado.
Para el equipo interno, el beneficio es aún más relevante: el sistema tiene más posibilidades de reflejar qué está disponible realmente porque las transacciones no están repartidas entre inventarios desconectados.
La migración tenía que preservar el negocio de servicios, no copiar páginas
Una migración de Squarespace a Shopify se puede plantear mal si el objetivo es reproducir página por página el sitio anterior en un editor distinto.
En MP Health, la pregunta útil era qué debía ser capaz de hacer el nuevo sistema después del lanzamiento:
- los tratamientos debían seguir siendo comprensibles para posibles clientes;
- las compras online tenían que conectar con la realidad de inventario de la clínica;
- las transacciones presenciales debían participar en ese mismo sistema;
- las señales de búsqueda local tenían que ayudar a usuarios cercanos a entender el negocio;
- la experiencia móvil necesitaba un camino más claro desde información hasta acción.
Eso convierte una migración web en un cambio de sistema operativo comercial.
Entrega de 4–6 semanas con alcance fijo
El directorio de Shopify registra el proyecto como completado en un engagement fixed-scope de 4–6 semanas.
Definir el alcance era especialmente importante porque el desarrollo custom de inventario puede expandirse rápidamente si cada workflow clínico o administrativo se incluye dentro del rebuild ecommerce.
El proyecto se centró en los requisitos directamente vinculados a Shopify: migración, lógica de inventario de tratamientos, integración POS, SEO local, schema y UX móvil.
Ese enfoque acotado hace que el plazo sea significativo. Describe una implementación comercial concreta, no una promesa abierta de transformación digital.
El SEO local formaba parte del customer journey
MP Health es una clínica, así que su adquisición es geográficamente distinta a la de una marca nacional DTC.
Un posible cliente puede buscar tratamiento y ubicación a la vez, comparar opciones cercanas, revisar credibilidad y después decidir si compra, llama o visita.
Por eso el proyecto incluyó optimización de SEO local y schema markup como workstreams explícitos.
La función del structured data era reforzar información visible del negocio y los servicios en un formato legible por máquinas. No era un atajo para rankings.
Lo importante era que contenido, ubicación, servicios y señales técnicas fueran coherentes entre sí.
Para una clínica, esa alineación ayuda a buscadores y clientes a responder las mismas preguntas: qué se ofrece, dónde se ofrece y cuál es la siguiente acción.
UX móvil porque la intención local suele ser móvil
El proyecto también incluyó mejoras de UX móvil.
Esto importa para una clínica porque muchas búsquedas locales ocurren en teléfono. El usuario puede estar comparando opciones, revisando información poco antes de acudir o moviéndose entre Google, Maps y el sitio del negocio.
La experiencia móvil debe reducir fricción alrededor de la información que impulsa la acción. Explicación del tratamiento, disponibilidad, señales de confianza y CTAs no deberían quedar enterrados en una composición pensada para desktop.
El objetivo no era solamente hacer responsive el contenido anterior dentro de Shopify. Era mejorar la experiencia en el contexto real en el que el cliente probablemente la utiliza.
El desarrollo custom representaba una regla de negocio
El custom development es más valioso cuando representa una regla que el negocio no puede ignorar.
En este caso, la regla era sencilla de expresar pero crítica: vender un tratamiento IV debe descontar los múltiples componentes necesarios para realizarlo.
Es una razón más sólida para escribir código custom que añadir novedad visual al storefront.
La función existe porque el supuesto estándar de un producto/una unidad no corresponde con la operación de la clínica.
La implementación crea una relación más clara entre eventos de comercio y eventos de inventario y reduce el conocimiento que el equipo debe mantener manualmente fuera del sistema.
Qué cambió para MP Health
El resultado verificado no es una vanity metric. Es un modelo operativo más coherente.
Después de la migración, el entorno Shopify podía soportar:
- un storefront de tratamientos sobre una plataforma orientada a comercio;
- descuentos de componentes vinculados a compras de paquetes IV;
- transacciones presenciales mediante Shopify POS;
- mejoras de SEO local y schema alrededor del descubrimiento;
- una experiencia móvil refinada;
- una migración completada dentro del alcance registrado de 4–6 semanas.
La web quedó más conectada con la forma en que la clínica realmente entrega sus servicios.
Por qué no añadimos un uplift de revenue inventado
Un case study no necesita un porcentaje para ser comercialmente útil.
En MP Health, la evidencia más fuerte publicada en el directorio de Shopify es el alcance entregado y la capacidad operativa creada. No existe en esa fuente una cifra verificada de tráfico, revenue o conversión post-launch, así que no añadimos una.
El resultado para el cliente es que Shopify se adaptó a un modelo de inventario no estándar y conectó ese modelo con la actividad POS de la clínica.
Para otra empresa con un problema similar, esa evidencia puede ser más relevante que una cifra genérica de CVR.
Qué demuestra este caso y qué no
Este caso demuestra que Shopify puede adaptarse a un negocio de servicios donde el paquete vendido y las unidades de inventario consumidas no son lo mismo, y que storefront y POS pueden diseñarse alrededor de un único entorno comercial.
No significa que Shopify deba reemplazar un practice-management system, un sistema de historia clínica o workflows sanitarios regulados. El caso se limita a ecommerce, inventario, POS, descubrimiento local y UX de storefront.
Tampoco significa que todos los modelos de componentes deban implementarse igual. La arquitectura depende de cómo funcionen paquetes, componentes, devoluciones, ajustes, sustituciones y propiedad del stock en cada negocio.
Qué debería definir primero un negocio de servicios similar
Antes de migrar un catálogo de servicios no estándar a Shopify, el equipo debería poder expresar la regla de inventario en lenguaje sencillo.
Preguntas clave:
- ¿Qué compra el cliente?
- ¿Qué artículos físicos se consumen para cumplir esa compra?
- ¿Esos componentes se comparten entre varios servicios vendibles?
- ¿Qué transacciones ocurren online y cuáles presencialmente?
- ¿Qué sistema debe ser la fuente de verdad del inventario después de cada operación?
La migración de MP Health se orientó alrededor de esa regla de negocio. Shopify no obligó a la clínica a comportarse como un retail estándar; la capa de comercio se adaptó a la operación que el negocio necesitaba ejecutar.
Fuentes y evidencia
Referencias públicas y datos del proyecto utilizados para validar el contexto, alcance y resultados publicados.
Continúa explorando
Commerce que refleja la operación
Modela la regla de negocio antes de elegir el stack de apps.
Definimos relación de inventario, canales de transacción, ownership del sistema, casos de fallo y requisitos de storefront antes de comenzar desarrollo custom Shopify.
Solicitar alcance de sistemas