Las funcionalidades y características que debe tener una aplicación B2B, más allá del código
11 oct 2023 . Actualizado a las 05:00 h.No hay cosa que más me aterre que el cierre de trimestre. Candela, mi mujer y principal responsable de que no arruine a la familia mientras juego a ser empresario, me pide todas las facturas que hacen falta para presentar las respectivas declaraciones de impuestos y justificar las salidas de caja.
Comienzo entonces un penoso peregrinaje por un montón de servicios digitales donde no es para nada sencillo obtener una factura válida para la Hacienda española: Loom, Momentum Dash, Kahoot… hasta Apple. En muchísimas ocasiones, la única forma de conseguirlo es contactando con el servicio de soporte y —aun así— un gran número no contiene la información mínima imprescindible como la razón social o el NIF.
Esta es solo una de las características básicas que debería tener cualquier servicio o producto tecnológico que nazca con el espíritu de tener empresas como clientes, más allá del código que lo sostenga.
Las grandes corporaciones suelen utilizar su enorme caja para adquirir participaciones en potenciales proveedores. Especialmente, de tecnología.— Alex Berenson
Si queremos construir el próximo Jira, Salesforce, Zendesk o Tableau ¿qué deberíamos tener en cuenta?
Lo primero, una mínima seguridad de acceso a la misma. Pero a las grandes corporaciones no les va a bastar una simple dupla de usuario/contraseña, sino que te van a pedir que implementes Single Sign On, o lo que es lo mismo, que sus empleados no tengan que registrarse en tu aplicación de juguete, sino que les baste con su cuenta corporativa.
Para conseguirlo tendrás que desarrollar integraciones con cada uno de los proveedores externos de autenticación con los que quieras trabajar: Google, Okta, Azure, Tivoli de IBM, el Cognito de Amazon o lo que sea. Pero eso, no será más que el comienzo...
También te van a pedir que implementes un sistema de autorización basada en roles o grupos, o lo que es lo mismo, que no tengan que ir usuario por usuario dando o quitando permisos para ver o hacer según qué cosas.
Por supuesto, no van a configurar esos grupos en tú aplicación sino en su propio sistema, así que, te exigirán que te integres con su sistema de directorio, la plataforma donde gestionan su plantilla. Para conseguirlo, una vez más tendrás que desarrollar integraciones con cada uno de esos sistemas: GSuite, el Active Directory de Microsoft, Rippling, Zluri o lo que toque.
Además, tendrás que implementar un sistema de auditoría que registre quién y cuando ha hecho cada cosa. Porque si alguna vez hay un marrón, tiene que quedar claro quién se lo tiene que comer.
Y esa es la clave. Por si aún no te ha quedado claro, lo más prioritario para el cliente corporativo no es que tu software tenga una UI con el estilo «refachero» o tecnología puntera, sino minimizar al máximo el riesgo de cagarla por usarla.
Por eso suelen exigir un servicio de soporte y una disponibilidad mínima garantizados, mediante SLAs o «acuerdos de nivel de servicio» que, en su nivel más alto, llegan a la atención 24/7 y los famosos «5 nueves»: garantizar que tu software estará disponible el 99,999 % del tiempo —lo que deja un margen de 5,26 minutos al año— y que siempre habrá alguien a quien llamar si hay algún problema, sea la hora que sea, sea el día que sea. Proporcionar ese nivel de servicio cuesta MUCHO, así que, intenta que no se te olvide cobrarlo de forma proporcional.
Pero para algunas empresas tampoco eso será suficiente y te pedirán garantías suplementarias, como certificaciones de terceros que demuestren, desde tu solvencia técnica hasta la solidez de tu tecnología.
Prepárate para superar auditorías técnicas que demuestren que, si alojas sus datos en la nube, implementes una arquitectura multi-tenant que asegure a nivel de diseño que ningún otro cliente podrá acceder a los mismos. Para algunas empresas tampoco será suficiente, así que, te conminaran a instalar tu software en sus propios servidores o en su nube privada, una práctica conocida como on-premise.
Ese nivel de paranoia puede llegar hasta comprobar si la tecnología que usas en tu stack tiene versiones LTS o Long Term Support —olvídate de usar el último framework de moda— o incluso obligarte a depositar tu código fuente en un notario, por si tu empresa desaparece o es adquirida por un pez más gordo. Todo es posible, dependiendo de la asimetría entre tu tamaño y el suyo; y del impacto que tenga el posible contrato en tu cuenta de resultados, claro.
¿Por qué carallo deberíamos meternos en el berenjenal que supone hacer software B2B? Principalmente, por una sola cosa: la pasta.
Porque después de toda esta retahíla de requisitos y exigencias, ¿por qué carallo deberíamos meternos en el berenjenal que supone hacer software B2B? Principalmente, por una sola cosa: la pasta.
PASTA GANSA. Panoja mayor. Big Billete. Contratos de cientos de miles o millones de euros que pueden cambiar el rumbo de una empresa. Tanto que, hasta las aplicaciones más guay del planeta se esfuerzan en dejar claro que son herramientas corporativas, como Notion o GitHub.
Y jugar en esa liga, evidentemente, no sale barato. Por eso, vemos esas rondas millonarias para construir software que, aparentemente, «no hace tanto». Y, por eso, el Valle sigue mirando con desdén a esas startups que pretenden poner su MVP a competir en el mercado B2B con unos pocos cientos de miles de euros.
Afortunadamente, desarrollar software corporativo hoy es más accesible que nunca. Hasta hay empresas cuyo único modelo de negocio es hacer que tu software sea corporación-compatible, como WorkOS o Replicated.
Para mí, la diferencia entre un software B2C y otro B2B es la misma que entre tener una ferretería o una fábrica de tornillos. Ser capaz de montar una tienda rentable es guay, pero levantar toda una factoría mola mucho más.
Parece que el mercado piensa igual, porque entre las 10 empresas tecnológicas con más ingresos del mundo, solo dos no generan la mayoría de sus ingresos con modelos B2B, Apple y Sony.
Por eso, puede que no sean tan sexis como otro tipo de negocios, puede que levantarlos sea mucho más complejo y costoso, pero… ojalá en nuestro país haya cada día más y más fábricas de tornillos.
ESTA BONILISTA CUENTA CON EL APOYO DE
¿Quieres sacar el máximo partido de la nube pública?
Como empresa global de tecnología multicloud, DoiT está especializada maximizar la productividad de los ingenieros frente a los retos de la nube de Google Cloud y AWS. Todo ello a COSTE CERO, incluyendo:
Soporte técnico ilimitado: acceso 24/7 a un pool global de +270 Sr. Cloud Architects para cualquier necesidad relacionada con AWS/GCP a través de videoconferencia, ticket o Slack.
Consultoría experta: sus ingenieros cuentan colectivamente con cientos de certificaciones y años de experiencia trabajando en la nube pública y te ayudarán a alcanzar tus objetivos: revisiones de arquitectura, FinOps & optimización de costes, migraciones, seguridad, datos y analítica, kubernetes, IA...
Tecnología inteligente: aprovecha DoiT Console para obtener ahorros de costes automatizados de hasta el 20%. Su consola te ayudará a mantenerte al tanto de tu gasto en la nube con alertas de detección de anomalías.
Únete a sus programas de AWS y Google Cloud sin riesgo ni ningún tipo de compromiso ¡Y estarán en la TRG23! Ve a verles a su stand o reserva una cita con su equipo en España ?
Este texto se publicó originalmente en la Bonilista, la lista de correo de noticias tecnológicas relevantes para personas importantes. Si desea suscribirse y leerlo antes que nadie, puede hacerlo aquí ¡es bastante gratis!