¿Vamos a jugar bingo de inicio? Plataforma, ecosistema, integración, mercado, api, sinergia. Bingo!
El tema de los mercados internos de soluciones integradas es muy candente en el mundo de los supermercados. En Poster POS, entendimos los beneficios de una API abierta y la construcción de un ecosistema durante mucho tiempo. Me impresionó especialmente el capítulo "La plataforma" en The Facebook Effect, que reforzó la comprensión de que es necesario ir a las plataformas. Hace 3 años abrimos la API, hace 2 años lanzamos Marketplace, hace un año lanzamos una tecnología que permite expandir sin problemas la funcionalidad del producto principal e influir en su comportamiento, hace aproximadamente 3 meses reiniciamos el catálogo de integración y comenzamos a comercializar activamente las aplicaciones de los socios.
Cuando comenzamos, no tenía suficientes casos públicos sobre este tema, una guía de acción. En este artículo, le diré cómo convertirse en un servicio SaaS sin un catálogo de integración y convertirse en un servicio SaaS con un catálogo de integración. Mi artículo será útil para productos que ya han pasado la etapa de ajuste del mercado de productos y están listos para comenzar a construir su ecosistema.
Acerca de nosotros
Para dar un poco de contexto,
Poster es un sistema de automatización SaaS para el restaurante y el negocio minorista. Lo que hacemos se llama Punto de Venta o "taquilla". Nuestro producto se divide en dos partes: terminal y panel de administración. El terminal se ejecuta en tabletas iPad y Android o dispositivos Windows. En la terminal, los cajeros y los camareros conducen en un pedido, aceptan pagos, imprimen cheques. El administrador de la institución, el gerente, el almacenista trabajan en el panel de administración: mantienen registros de almacén y administración, observan estadísticas de ventas, administran mercancías, etc. Ahora el producto es utilizado por 6,000 instituciones activas en 53 países.
Un poco de historia
El tema de los mercados y plataformas no es nuevo. Las primeras plataformas fueron los sistemas operativos, que permitieron a los desarrolladores administrar de forma independiente la memoria, la E / S, el tiempo del procesador, etc. Luego comenzaron a aparecer aplicaciones de escritorio con complementos y complementos. Mi conocimiento de los complementos comenzó con Total Commander y Winamp. Luego estaban los applets de Java para teléfonos inteligentes, en iOS 2.0 lanzó la App Store. Los servicios web también comenzaron a crecer con integraciones y complementos, por ejemplo, Facebook, SalesForce, Basecamp, Xero, etc. La API abierta y los mercados se han convertido en parte de nuestra vida diaria y los encontramos constantemente.
¿Qué dan los mercados?
Más funciones, mayor compromiso del usuario.
Seamos realistas: su cartera de pedidos siempre crecerá. Siempre tendrá recursos insuficientes para ejecutar todas las funciones que solicitan sus usuarios. Además, si agrega constantemente nuevas funciones al producto, tarde o temprano se convertirá en un terrible e incómodo desorden de botones, marcas de verificación e interruptores. Es mejor hacer un producto que resuelva cualitativamente 3-7 problemas que 50, pero mediocre. Por lo tanto, las integraciones ayudan al producto a crecer cualitativamente a los ojos del usuario, expandir su funcionalidad, lo que significa que es menos probable que su cliente vaya a competidores.
Impulsor del crecimiento de sus ventas.
Las integraciones con otras compañías en el mercado pueden ser un buen impulsor para las ventas de su producto principal. Por ejemplo, en nuestro caso, los clientes potenciales con o sin software de caja registradora obsoleto pueden acudir a socios que participan en sistemas de fidelización. En este punto, el socio recomendará esa caja con la que tiene integración y buenas relaciones.
Capacidad para crear soluciones personalizadas para grandes clientes.
Anteriormente, cuando recibimos una solicitud para finalizar un producto en una red grande con requisitos atípicos, tuvimos que rechazar para no enterrarnos en el pozo de soluciones empresariales, en el que en cada paso del código hay ramas como:
if (account==='very_important_enterprise_customer') { ... }
Ahora podemos implementar casi cualquier complemento en el sistema sin afectar el núcleo del producto. O, mejor aún, externalizar las mejoras.
Canal de ganancia adicional
Por lo general, los directorios se encargan de la venta de aplicaciones alojadas en él. El tamaño de la comisión es del 30 (estándar de la industria) al 80% (en casos muy extremos, por ejemplo en Odnoklassniki). Pero al mismo tiempo, personalmente tengo poca fe en la idea de que el modelo de negocio de la compañía se puede construir alrededor del mercado. Por ejemplo, Apple tiene el 62% de los ingresos de la venta de iPhone, y toda la categoría de servicios (aplicaciones en AppStore, Apple Music, iCloud, Apple Pay) - 13%. En nuestro caso, configuramos el mercado para que sea autosuficiente.
¿Cuáles son la integración?
Dividimos las opciones de integración en 3 tipos principales: backend, plataforma de gestión, plataforma POS.
Integración de backend
La opción de integración más básica, comenzamos con ella y las primeras integraciones funcionaron de esta manera. El backend del socio de servicio a través de la API HTTP JSON recupera los datos, de alguna manera los procesa y los muestra al cliente, tal vez algo se actualice dentro de nuestro sistema. Un ejemplo es analítica, lealtad, sistemas de correo, sistemas de video vigilancia.
Administrar plataforma
De hecho, la misma integración de back-end, pero integrada en la cuenta personal del usuario. Debajo del capó para esto hay un iFrame regular y su propio protocolo para una autorización perfecta. Es mucho más conveniente para el usuario ya que No es necesario dejar el sistema en ningún lado. Adecuado para aplicaciones con una interfaz simple.
Plataforma POS
En algún momento, nosotros y nuestros socios comenzamos a perder la integración del backend. Necesitaba una solución para integrarme directamente con el cajero, quería expandir la funcionalidad, integrar de forma nativa en el cajero y cambiar su comportamiento. Por lo tanto, hace un año lanzamos la plataforma POS con la mecánica de complementos o widgets. Podrías ver soluciones similares en la web, por ejemplo en Trello.
Ejemplos de integraciones en esta tecnología son los sistemas de fidelización que requieren identificación del huésped cerca del cajero, billeteras móviles y otros sistemas de pago. Aquí, por ejemplo, hay una aplicación de Paytomat que le permite pagar su pedido con criptomonedas:
A continuación, hablaré sobre el componente técnico de la implementación de esta tecnología.
Cómo hacer una aplicación JS de terceros
Nuestra solución de efectivo se basa en tecnologías híbridas, lo que nos permite admitirla en todas las plataformas: iOS, Android, Windows. Toda la interfaz y la lógica empresarial están escritas en HTML / JS. Y para las plataformas nativas, escribimos envoltorios alrededor de WebView e implementamos controladores para trabajar con equipos periféricos (impresoras, registradores fiscales, escalas, etc.)
Si también escribe la aplicación en la pila web, le ahorraré tiempo para investigar y le diré cómo hemos hecho que la aplicación sea extensible. Durante el estudio, se inspiraron en Trello, Shopify y Atom.io. Como resultado, llegamos al siguiente modelo.
La instancia principal de la aplicación crea un contenedor separado para cada widget de terceros conectado. Un contenedor es un iFrame en el que se carga un archivo JS con el código ejecutable de la aplicación asociada. Los métodos con nuestra API están disponibles automáticamente en el contenedor. El contenedor se almacena en caché en la parte frontal (Appcache o Service Workers) y se puede iniciar, trabajar sin Internet.
La solución con iFrame le permite aislar la lógica de una aplicación de terceros de la principal y, en caso de algunos problemas con el widget, no rompa la aplicación de flujo de efectivo principal. También consideramos la opción de WebWorkers, pero las secuencias de comandos dentro del trabajador no tienen acceso al DOM, y les damos a los widgets la capacidad de mostrar interfaces, por lo que de inmediato descartamos esta opción.
Los desarrolladores escriben su aplicación usando JS o cualquier lenguaje que se compila en JS (CoffeeScript, Typecript ...), con cualquier marco o biblioteca. A continuación, el código y todos los recursos del paquete web se recopilan en un paquete.js, que la utilidad de la consola implementa en nuestros servidores y entrega a los usuarios.
Los widgets en iFrame intercambian mensajes con la aplicación principal a través de postMessage y pueden enviar comandos de pago a través del póster incorporado al ámbito global. Por ejemplo:
Poster.interface.popup({width: 500, height: 300, title: " "});
Hemos implementado una cola de devolución de llamada que permite que aplicaciones de terceros se suscriban a eventos de pago, respondan a ellos y cambien la lógica de la aplicación. Por ejemplo:
Poster.on('beforeOrderClose', (data, next) => { alert(" "); next(); });
Por cierto, en el caso de los eventos antes *, que, de hecho, bloquean el trabajo de realizar algún tipo de operación en el proceso de pago, tuvimos que ingresar el tiempo de respuesta desde un widget de terceros. Por ejemplo, hay una aplicación que escucha el evento beforeOrderClose y realiza una solicitud con los detalles del pedido que el cajero planea pagar a su servidor. Para que la experiencia del usuario no sufra, le damos a la aplicación no más de 5 segundos para implementar nuestra lógica y llamar a next () o mostrar una interfaz que mostrará el progreso del usuario.
Modo de desarrollo
Cada vez, la recopilación de la aplicación completa y su implementación en los servidores durante el proceso de desarrollo es inconveniente, por lo que hicimos el modo de desarrollo. En él, el widget se recopila constantemente utilizando webpack-dev-server con recarga en caliente y en la aplicación de caja en la cuenta del desarrollador, el código de la aplicación no se inicia desde la producción, sino desde la máquina del desarrollador local. Al mismo tiempo, la interfaz siempre tiene la capacidad de cambiar entre dev y prod. Pronto presentaremos otra rama: beta. El código beta también se implementará en nuestros servidores, pero solo estará disponible para los probadores beta de la aplicación.
Gabinete de desarrollador
Durante mucho tiempo, registramos aplicaciones y cambiamos la configuración manualmente, a solicitud de los desarrolladores. Cada contacto en la etapa de creación de la aplicación nos permitió comunicarnos más con los desarrolladores, para conocer qué productos desean integrar, qué métodos les falta en la API.
Pero cuando alcanzamos la marca de 40-50 integraciones simultáneas, el trabajo mecánico comenzó a tomar mucho tiempo del equipo de integración. Por lo tanto, lanzamos la oficina del desarrollador, en la que automatizamos todos estos procesos.
Documentación, ejemplos, soporte de socios
Contamos con soporte técnico de calidad en el ADN de nuestra empresa. Por lo tanto, cuando comenzamos a hacer crecer la historia con socios de desarrollo, decidimos ofrecer el mejor soporte para desarrolladores del mercado.
Con cada socio, llamamos, ayudamos a crear un flujo de integración e incluso preparamos un seguimiento detallado con una lista de métodos que necesitan usar para implementar. Respondemos preguntas en un chat general de Telegram con desarrolladores asociados.
Por cierto, a veces surge un problema cuando los desarrolladores menos experimentados hacen preguntas no en nuestra plataforma, API, sino simplemente en la programación o no quieren depurar cuando el problema está de su lado. En tales situaciones, utilizamos la técnica de "no responder dentro de 1-2 horas", en la mayoría de los casos, durante este tiempo, el desarrollador resuelve el problema por su cuenta :)
Para la documentación usamos Slate. La generación automática de documentación a partir de los comentarios sobre los archivos de origen no nos convenía porque necesitamos admitir versiones de la documentación en varios idiomas: ruso e inglés.
Y, por supuesto, es importante comprender que para los desarrolladores de terceros somos solo una integración adicional más, por lo que deben hacerlo lo más rápido posible y con el máximo beneficio para su negocio. Por lo tanto, hacemos
repeticiones , ejemplos de código y hacemos todo lo posible para ayudar en el proceso.
Comercialización de aplicaciones
Para que todos se beneficien: instituciones: funcionalidad adicional y solución de sus problemas comerciales, desarrolladores: nuevos clientes y nosotros: un cierre más profundo de clientes en nuestro ecosistema, las aplicaciones deben comercializarse. Para aplicaciones de marketing entre nuestros usuarios, utilizamos las siguientes herramientas.
Anuncio de integración
Esto es lo más simple que se puede hacer: estamos anunciando una nueva integración en las redes sociales y un boletín mensual sobre nuevas características. Los mensajes se reciben sin objetivo, en todos nuestros contactos, y pueden perderse en medio del ruido informativo.
Enviar correos
Seleccionamos a los clientes que pueden estar interesados en una u otra categoría de aplicaciones (sistemas de fidelización, videovigilancia, gestión de documentos, etc.), y les hacemos correos dirigidos con la oferta para ver lo que tenemos en el mercado de esta categoría.
Por ejemplo, para los establecimientos que obtuvieron más de 100 datos de contacto de sus invitados en la base de datos, activamos la integración con los sistemas de lealtad y nos dicen que puede trabajar con sus invitados de manera aún más eficiente y devolverlos a su institución. Para las instituciones con más de 5 empleados (esto ya no es una empresa familiar), enviamos un disparador sobre la integración con sistemas de videovigilancia basados en la nube para facilitar el control de los empleados.
Agregamos esta carta y la enviamos a nuestra estructura de incorporación, llega al cliente cuando ya se le ha pagado y ha comenzado a usar todas las funciones básicas. Si le envía información sobre la expansión de la funcionalidad antes de que aprenda a usar el básico, será absolutamente inútil.
Banners informativos dentro del producto
Los usuarios a menudo ignoran las letras y empujan el flujo de basura informativa, por lo que agregamos pancartas discretas en el propio producto. Descubrimos que esta es una de las formas más efectivas de dirigir el tráfico a la página de la aplicación. Los banners aparecen en contexto. Por ejemplo, un banner sobre productos para análisis profundo aparece en la sección con recibos, donde el propietario analiza sus ventas.
Que mas
Ahora estamos experimentando con el formato de artículos de blog con estudios de casos para resolver problemas comerciales utilizando soluciones integradas. Pronto lanzaremos seminarios web conjuntos con socios.
Con las herramientas enumeradas anteriormente, aprendimos cómo llevar a los desarrolladores de terceros 20-100 clientes potenciales por mes, y esto es solo el comienzo.
Después de la transferencia de plomo
Naturalmente, la venta no se produce por sí sola después de presentar el cliente potencial a un desarrollador externo. Por lo general, los productos b2b son más difíciles de dominar y funcionan de forma independiente, por lo tanto, transferimos la información de contacto del cliente (con su consentimiento) a los socios e insistimos en que se contacten y ayuden con el proceso de incorporación.
¿Qué tenemos en el trabajo?
Facturación
Creemos que debe facturar al cliente en un solo lugar para simplificar el flujo de trabajo y las conexiones tanto como sea posible. Ahora estamos finalizando el soporte de facturación para aplicaciones de terceros.
Por cierto, hay muchas dificultades en la implementación, por ejemplo:
- Las aplicaciones pueden tener un modelo de monetización completamente diferente: suscripción mensual, pagos de transacciones, suscripción según el uso
- El cliente debe ser notificado automáticamente en caso de un cambio de tarifa
- Los clientes pueden pagar desde diferentes países, y un contrato con un socio generalmente está en uno
- El cliente puede tener una tarjeta adjunta para pagos, o puede haber pago de facturas en el jur. la cara
Revisión de solicitud
Ahora la revisión de la solicitud se lleva a cabo una sola vez cuando la aplicación ingresa al mercado. Queremos presentar una revisión obligatoria, pero rápida en cada implementación para ayudar a rastrear algunos casos extremos.
Pautas para aplicaciones de terceros
Para preservar una experiencia común del uso de nuestro producto y productos integrados, brindamos recomendaciones sobre diseño y flujo a los socios, pero no existe un conjunto formal de reglas.
Desarrollamos pautas para uso interno por parte de diseñadores y desarrolladores de pósters, y luego los abrimos a desarrolladores externos.
Eso es todo
De hecho, solo estamos al comienzo del viaje. Todavía hay mucho trabajo para convertirse en una plataforma completa, pero ya hemos aprendido mucho durante este tiempo. Además, solo que más interesante. Si tiene preguntas, escriba los comentarios, intentaré responder lo más completo posible.
Y si está haciendo un producto para cafeterías, restaurantes, tiendas, ¡cambiemos el mercado juntos! Escriba ahora a
dev@joinposter.com , estoy seguro de que podemos ser útiles el uno al otro.