Checklist para elegir proveedor de etiquetas electrónicas

Esta checklist puntúa a un proveedor de etiquetas electrónicas en cinco bloques, casi todos centrados en una pregunta: cuánto te costaría irte. Cada bloque tiene cinco preguntas que se puntúan de 0 a 3. El resultado sirve para comparar ofertas con el mismo criterio y para decidir qué negociar antes de firmar.

Para qué sirve y para qué no

Un proyecto de etiquetas se compra una vez y se usa durante años. Las etiquetas están colgadas de las baldas, el software de gestión sabe qué precio va en cada una y el contrato fija quién puede tocar qué. Si cuando ya hay veinte mil etiquetas instaladas descubres que los datos no salen, que la API es de pago o que las etiquetas de otro fabricante no se pueden mezclar con las tuyas, la negociación ya la tiene el proveedor.

La checklist no te dice qué marca comprar. Tampoco sustituye al pliego, que es el documento que mandas a los proveedores. Aquí se hace el trabajo contrario: recibes las respuestas, las cotejas con lo que dice el contrato y asignas puntos. Si necesitas entender primero por qué la dependencia del proveedor es un riesgo en este sector, está desarrollado en el artículo sobre lock-in en etiquetas electrónicas; aquí solo se mide.

Cómo se puntúa

Cada pregunta vale de 0 a 3 puntos y la puntuación sale de lo que el proveedor te da por escrito, no de lo que dice en una reunión.

Hay 25 preguntas, así que el máximo es 75. Los bloques pesan igual de entrada, pero la columna de peso de la tabla final te deja subir el que más te preocupe. Una tienda con un solo local y una cadena con cuarenta no tienen el mismo miedo a quedar atadas.

Bloque A. Salida de datos

Las etiquetas muestran un precio, pero el activo que importa está en la plataforma: la asignación de cada etiqueta a cada artículo y a cada balda, los gráficos de las plantillas, los históricos de cambios y las reglas de actualización. Si eso no sale en un formato legible, cambiar de proveedor significa reconstruirlo a mano.

1. Exportación completa. ¿Puedes descargar en cualquier momento, sin ticket y sin coste, la asignación etiqueta-artículo-ubicación de todas las tiendas?
2. Formato. ¿El formato de exportación es abierto y documentado (CSV, JSON, XML) o es un volcado que solo importa su propia plataforma?
3. Plantillas. ¿Puedes exportar las plantillas de visualización de la etiqueta (diseño, campos, reglas) de modo que otro sistema pueda reproducirlas, aunque sea con trabajo?
4. Histórico. ¿El registro de cambios de precio por etiqueta y fecha, que puede hacerte falta para justificar un precio ante una reclamación, es exportable y durante cuánto tiempo se conserva?
5. Propiedad escrita. ¿El contrato dice expresamente que los datos de tu tienda son tuyos y que el proveedor no los usa para otros fines sin tu autorización?

La tentación es dar un 3 en la pregunta 1 porque la plataforma tiene un botón de exportar. Antes de dar el punto, haz la prueba: pide una exportación real de un entorno de demostración y comprueba que se puede abrir y que contiene lo que esperas.

Si la plataforma es un servicio en la nube, el cambio de proveedor puede estar además cubierto por el Reglamento europeo de Datos (Reglamento (UE) 2023/2854). Según los análisis jurídicos consultados, para los servicios de tratamiento de datos que entren en su ámbito el proveedor debe facilitar el cambio con un periodo de transición de 30 días, ampliable hasta siete meses si es técnicamente inviable, y las tarifas por cambiar de proveedor quedan prohibidas a partir del 12 de enero de 2027. Si una plataforma de gestión de etiquetas cae dentro de esa definición es una cuestión jurídica que debe confirmar tu asesor, no esta página; pero sirve de argumento para exigir una cláusula de salida clara. El texto original está en EUR-Lex y los comentarios, en Mishcon de Reya y Travers Smith.

Bloque B. API abiertas e integración

Tu ERP o tu sistema de precios tiene que hablar con la plataforma de etiquetas. La integración se paga una vez, pero lo que la hace cara de cambiar es que sea propietaria.

6. Documentación pública. ¿La API tiene documentación accesible sin firmar un contrato, con ejemplos y versiones?
7. Cobertura. ¿Lo que se hace en la interfaz (asociar etiquetas, cambiar precios, lanzar actualizaciones, leer estados) también se puede hacer por API, o hay funciones que solo existen en la pantalla?
8. Coste y límites. ¿El acceso a la API está incluido en el precio, y los límites de llamadas por minuto son compatibles con tus actualizaciones en hora punta (cambio masivo de precios, promoción)?
9. Integración existente. ¿Hay integración ya hecha con tu ERP o TPV, mantenida por el proveedor o por un tercero, y quién la corrige cuando tu ERP cambia de versión?
10. Propiedad del conector. Si el conector lo ha escrito el proveedor para ti, ¿tienes derecho a su código o a su especificación para que otro pueda mantenerlo?

La pregunta 10 es la que más se deja pasar. Un conector que solo el proveedor puede tocar es dependencia disfrazada de servicio incluido.

Bloque C. Interoperabilidad de las etiquetas

Es el bloque donde más se confunde la teoría con la realidad. Existe una especificación pública, el perfil de etiquetas electrónicas de estantería (ESL) del Bluetooth SIG, que define cómo un cliente puede controlar y actualizar etiquetas sobre Bluetooth (versión 1.0.1 en su página oficial, con documentos de conformidad y pruebas). Pero que exista un estándar no significa que todo el parque instalado lo use. Las fichas de homologación de la FCC estadounidense dan una pista de lo lejos que puede estar una marca de otra: la etiqueta STELLARP-154 de Hanshow está registrada en la banda de 2402 a 2480 MHz, y el modelo Newton EL043DWWRA de SoluM, en la de 902,4 a 927,6 MHz. Son versiones para Estados Unidos, pero el razonamiento vale aquí: dos etiquetas que no emiten en la misma banda no van a compartir pasarela. Las fichas públicas no dicen qué protocolo corre por encima. Eso es justo lo que hay que preguntar.

11. Protocolo. ¿El proveedor declara por escrito qué protocolo de radio usan las etiquetas y si cumple el perfil ESL del Bluetooth SIG o es propietario?
12. Mezcla de marcas. ¿Pueden convivir en tu tienda etiquetas de otro fabricante bajo la misma plataforma, o solo las suyas?
13. Plataforma ajena. ¿Las etiquetas que compras pueden ser gobernadas por una plataforma de software distinta de la del fabricante, si llegara el caso?
14. Reposición. ¿Se comprometen a seguir vendiendo etiquetas compatibles con las ya instaladas durante un número de años concreto, y qué pasa con las que ya no se fabriquen?
15. Infraestructura. ¿Los puntos de acceso o las pasarelas de radio son específicos del proveedor, o sirven con otras etiquetas? ¿Quién es propietario de ellos?

Si el proveedor responde “propietario, pero estable y con soporte garantizado”, puntúa 2 en la pregunta 11 y deja que la puntuación baje en las demás: lo que mide el bloque no es la tecnología, sino cuántas salidas te deja.

Bloque D. Condiciones de salida del contrato

Todo lo anterior es papel mojado si el contrato dice otra cosa. Léelo con las cinco preguntas siguientes delante, y si el contrato es un renting o una cuota por etiqueta, léelo dos veces; cómo afecta eso al coste está en renting frente a compra.

16. Duración y renovación. ¿La renovación es automática, con qué preaviso se cancela y a qué precio se renueva?
17. Propiedad al terminar. ¿Quién conserva las etiquetas, las pasarelas y las licencias al final: tú, el proveedor o depende de pagar un valor residual?
18. Cláusula de salida. ¿Hay un procedimiento escrito con plazos para entregar tus datos y colaborar en la migración, y se aplica también si cancelas por incumplimiento del proveedor?
19. Precio de la salida. ¿Se fija ya, en el contrato, lo que costaría exportar, desinstalar y retirar, o queda como «según presupuesto»?
20. Cambios unilaterales. ¿Puede el proveedor subir cuotas, retirar funciones o cambiar la plataforma durante la vigencia sin tu consentimiento, y qué derecho de resolución te queda si lo hace?

Un 0 aquí no se compensa con 3 en otro bloque. Es el mismo criterio que con la salida de datos: lo que no se pacta antes de firmar rara vez se consigue después.

Bloque E. Dependencia del firmware y del software

Una etiqueta electrónica es un pequeño ordenador con una pantalla y una pila. Lo que hace depende de un firmware, y quien controla las actualizaciones controla cuánto tiempo seguirá siendo útil tu inversión.

21. Política de actualizaciones. ¿Hay compromiso escrito de actualizar el firmware de etiquetas y pasarelas, incluidas correcciones de seguridad, durante un número de años concreto?
22. Fin de vida. ¿Qué ocurre cuando una generación de etiquetas deja de recibir soporte: sigue funcionando sin actualizaciones, hay que sustituirla, y a cargo de quién?
23. Modelo de licencias. ¿Las funciones de la plataforma se licencian por etiqueta, por tienda o por usuario, y puede una licencia caducar y dejar las etiquetas sin gestión?
24. Funcionamiento sin conexión. Si la nube del proveedor deja de estar disponible, ¿qué pasa con las etiquetas ya cargadas, y existe una opción de instalación local?
25. Seguridad documentada. ¿El proveedor documenta el cifrado de la comunicación con las etiquetas, cómo se gestionan las claves y cómo se notifica una vulnerabilidad?

Las fichas de homologación citadas antes hablan de bandas de frecuencia, no de cifrado ni de claves. Esa información no suele estar en ningún registro público, y por eso la pregunta 25 pide que el proveedor la ponga por escrito y se comprometa a mantenerla.

Resumen y lectura de la puntuación

Anota los puntos de cada bloque (máximo 15) y multiplícalos por el peso que decidas. Si no tienes razones para otra cosa, deja 1 en todos.

Para leer el resultado, no te quedes solo con la suma:

• Más de 60 sobre 75, sin ningún 0: riesgo de dependencia contenido. Aun así, comprueba que las respuestas están en el contrato y no en el correo comercial.
• Entre 40 y 60: hay dependencia aceptable si se compensa con otros factores, pero cada punto perdido es una cláusula para negociar. Empieza por las preguntas con 0 o 1.
• Menos de 40, o algún bloque por debajo de 5: el proveedor puede ser bueno en otras cosas, pero en esa oferta la salida está cerrada. Pide cambios por escrito o compara con otra propuesta.

Estos tramos son una regla práctica nuestra, no un estándar de la industria. Adáptalos al tamaño y al riesgo de tu proyecto.

Cómo usarla en la práctica

1. Envía las 25 preguntas junto con el pliego y pide respuesta numerada. Cuando todos responden lo mismo, comparar es mucho más fácil.
2. Puntúa por separado, dos personas: alguien de sistemas para los bloques B, C y E, y alguien de compras o jurídico para A y D. Después se contrastan los puntos.
3. Verifica una respuesta por bloque: una exportación real, una llamada de API de prueba, un fragmento del contrato. Un proveedor que acepta que lo compruebes te está dando información.
4. Lleva los resultados al piloto. Las dudas que queden abiertas pueden convertirse en criterios del proyecto piloto.
5. Pon el coste de la salida en el cálculo. La calculadora de coste total mide el coste de comprar y operar; la puntuación de esta checklist te dice cuánto vale la libertad de dejarlo.

Para ver qué fabricantes hay y con qué datos públicos, consulta la comparativa de fabricantes.

Transparencia

Este sitio lo publica Keonex, que fabrica e implanta sistemas de etiquetas electrónicas. Las preguntas de la checklist se aplican igual a Keonex que a cualquier otro proveedor, y deberías pedirle las mismas respuestas por escrito. Esta página no puntúa a ningún proveedor concreto.