# Kaizen: consultoría Salesforce > Kaizen es una consultora especializada en Salesforce, partner de Salesforce desde 2011 y con más de 300 proyectos realizados. Trabaja el CRM partiendo de la pregunta de negocio (cómo vende, atiende, hace marketing y opera la organización) antes que de la herramienta. Concentra experiencia en manufacturing, hospitality y servicios profesionales. Sede en Barcelona, con clientes en toda España y despliegues en filiales de varios países europeos. - El sitio está íntegramente en español de España. - El catálogo entra por dos vías según si el visitante ya usa Salesforce o lo está evaluando; es la bifurcación de la home y de /salesforce/consultoria. - La navegación ordena los servicios en dos ejes: por tipo de servicio y por producto. Las páginas de producto viven bajo /salesforce/consultoria/ y dicen qué cubre cada pieza de la plataforma y qué no, no qué hacemos con ella. - Las cifras de los casos las midió cada cliente sobre su propio punto de partida y no son una promesa de resultado. Este fichero contiene, completos, las fichas de caso, las páginas de producto y los artículos, más el índice del resto del sitio. La versión resumida está en /llms.txt. --- ## Vincci Hotels: De base de datos dormida a motor de reserva directa - URL: https://kaizenstep.com/casos-exito/vincci-hotels - Sector: Hospitality - Escala: 36 hoteles de 4 y 5 estrellas en España, Portugal y Túnez - Duración del proyecto: 18 semanas - Productos Salesforce: Marketing Cloud, Data Cloud, MuleSoft, Loyalty Vincci tenía cientos de miles de huéspedes que habían dormido en sus hoteles y un 68% de las reservas entrando por intermediarios con comisiones de entre el 15% y el 20%. Unificamos el perfil del huésped desde el PMS, la web y el CRM, y montamos los journeys de todo el ciclo de estancia junto con el programa de fidelización. ### La compañía Vincci Hotels es una cadena hotelera española fundada en 2000, con 36 hoteles de 4 y 5 estrellas en los principales destinos urbanos y de costa de España, Portugal y Túnez. Combina un perfil de cliente corporativo en sus hoteles urbanos de Madrid, Barcelona y Sevilla con un perfil de ocio en sus resorts de Tenerife, Lanzarote y Mallorca. Esa doble naturaleza es la que obliga a segmentar: el mismo mensaje no sirve para los dos. ### El punto de partida Vincci operaba con una dependencia fuerte de las grandes agencias en línea para captar demanda, pagando comisiones de entre el 15% y el 20% por reserva. Su herramienta de email marketing era básica, sin conexión con el historial de estancias y sin capacidad de automatizar secuencias. La base de datos era de baja calidad: correos duplicados, sin segmentación por perfil de viaje ni por comportamiento. El equipo de marketing central enviaba el mismo boletín mensual a toda la base, y la conversión a reserva desde el canal de email era prácticamente nula. Problemas concretos: - El 68% de las reservas llegaba a través de intermediarios, con una comisión alta por cada una - Tasa de apertura del 11%, por ausencia de segmentación y personalización - Conversión de email a reserva del 0,4%, frente a una referencia de sector del 1,8% al 2,5% - El 34% de los contactos estaba duplicado o tenía datos incompletos - El programa de fidelización no estaba integrado con el email marketing ni podía activarse de forma automática ### Cita del cliente > Teníamos una base de datos de cientos de miles de clientes que habían dormido en nuestros hoteles y no estábamos haciendo nada con ella. Cada reserva que volvía por una OTA era dinero que pagábamos dos veces: primero la comisión del canal, y encima perdíamos la relación directa con ese huésped para siempre. Aixa Rodríguez, Directora de Marketing y Comunicación, Vincci Hotels ### Qué se puso en marcha #### Journeys de todo el ciclo de estancia Automatización de las comunicaciones desde la reserva hasta la fidelización posterior, con personalización según destino, tipo de hotel (urbano o resort) y perfil del viajero. - Confirmación personalizada con propuesta de mejora contextual: cambio de habitación, aparcamiento, salida tardía - Secuencia previa a la estancia con información del destino y servicios del hotel siete días antes - Recordatorio 48 horas antes con registro de entrada en línea y plano del hotel - Reenganche a los 60, 120 y 365 días con oferta según los destinos ya visitados #### Activación del programa de fidelización Integración del programa con Marketing Cloud para activar comunicaciones según el nivel del miembro, su historial de reservas y su comportamiento digital. - Bienvenida automatizada a nuevos miembros con la explicación del programa - Avisos de puntos próximos a caducar acompañados de oferta de reserva - Campañas de subida de nivel con propuesta según el patrón de viaje - Segmentación por tipo de viajero (corporativo, familia, pareja, individual) inferida del historial #### Perfil unificado del huésped Consolidación de los datos del PMS, el motor de reservas y el histórico de email en un perfil único que alimenta la personalización en tiempo real. - Deduplicación de los cientos de miles de registros históricos acumulados - Enriquecimiento con comportamiento web: páginas vistas, búsquedas y fecha de consulta - Segmentos de propensión a reservar calculados según el patrón estacional - Sincronización con el PMS para activar journeys en el momento de la entrada y la salida #### Captación de reserva directa Recuperación sistemática del huésped que llegó por intermediario, para convertirlo en reserva directa en estancias futuras. - Captura de correo en el registro de entrada, con consentimiento - Secuencia de conversión con precio igual o inferior por canal directo - Campaña de reserva directa con ventajas exclusivas del programa de fidelización - Automatización de ofertas de reserva anticipada para la temporada siguiente ### Resultados Medidos por el cliente sobre su propio punto de partida. «pp» son puntos porcentuales, que no es lo mismo que una variación relativa. | Indicador | Antes | Después | Variación | | --- | --- | --- | --- | | Reservas directas sobre el total | 32% | 40% | +8 pp | | Comisión media pagada a intermediarios | 11,7% | 7,5% | −4,2 pp | | Tasa de apertura de email | 11% | 29% | +18 pp | | Revenue atribuido a campañas de email, primer año | Referencia | ×3 | ×3 | | NPS posterior a la estancia | 38 | 47 | +9 puntos | | Revenue de venta cruzada previa, por habitación y noche | 2,10 € | 7,80 € | +5,70 € | ### Retorno declarado - Ahorro en comisiones el primer año: 1,1 M€ - Revenue incremental de venta cruzada previa: 420.000 €/año - Revenue incremental de email marketing: 680.000 €/año - Coste por reserva del canal directo frente al intermediado: −73% ### Fases del proyecto - Descubrimiento y arquitectura de datos (3 semanas): Auditoría de la base de datos, mapeo de fuentes (PMS, motor de reservas, web) y diseño del modelo de datos unificado. - Integración y perfil unificado (5 semanas): Conexión con el PMS Protel y con Siteminder. Deduplicación y migración del histórico de registros. - Journeys principales (5 semanas): Configuración de los journeys previos, durante y posteriores a la estancia, plantillas adaptativas y reglas de personalización dinámica. - Programa de fidelización y segmentación (3 semanas): Integración del programa, segmentos de propensión y campañas de activación. - Pruebas, formación y arranque (2 semanas): Validación con el equipo de marketing central, formación y arranque escalonado por tipo de hotel. ### Qué pedía el proyecto - Conocimiento del sector hotelero español: estacionalidad, integración con PMS y la diferencia real entre el viajero urbano y el de resort - Experiencia en journeys hoteleros con múltiples destinos, tipos de viajero e idiomas, no solo certificaciones de producto - Integración en tiempo real con el PMS Protel, que era el punto crítico del proyecto - Capacidad de evolución continua: el equipo de marketing necesitaba lanzar campañas estacionales nuevas sin relanzar un proyecto cada vez --- ## Catalonia Hotels & Resorts: Activar una base de 900.000 contactos que perdía valor cada año - URL: https://kaizenstep.com/casos-exito/catalonia-hotels-resorts - Sector: Hospitality - Escala: Más de 70 hoteles en España, Portugal, República Dominicana y Cuba - Duración del proyecto: 20 semanas - Productos Salesforce: Marketing Cloud, Data Cloud, MuleSoft Más del 62% de las reservas de resort llegaba por intermediarios con comisiones superiores al 18%, mientras una base propia de más de 900.000 contactos se degradaba sin recibir nada relevante. Integramos el PMS con marketing y segmentamos por mercado de origen, idioma, destino visitado y comportamiento de reserva previo. ### La compañía Catalonia Hotels & Resorts es una cadena familiar española fundada en Barcelona en 1982, con más de 70 hoteles de 3, 4 y 5 estrellas en España, Portugal, República Dominicana y Cuba. Su oferta combina hoteles urbanos y resorts vacacionales, con un cliente predominantemente de ocio e internacional: Reino Unido, Alemania, Francia y los países nórdicos. Ese mix de mercados es lo que obliga a trabajar en cinco idiomas. ### El punto de partida La cadena dependía de las grandes agencias en línea para llenar sus resorts, lo que erosionaba el margen por habitación y dejaba la relación con el huésped en manos de un tercero. Tenía una base de datos propia de cientos de miles de contactos, pero sin capacidad de activarla de forma segmentada: las comunicaciones eran genéricas, sin distinguir mercado de origen, idioma, tipo de destino visitado ni comportamiento de reserva previo. El resultado era una base que perdía valor cada año en lugar de generar ingresos directos. Problemas concretos: - Más del 62% de las reservas de resort llegaba por intermediarios, con comisiones medias superiores al 18% - Más de 900.000 contactos propios sin segmentación ni activación sistemática - Pérdida estimada del 28% anual de la base por falta de comunicaciones relevantes - Sin integración entre el sistema de gestión hotelera y las herramientas de marketing: los datos de estancia no alimentaban ninguna comunicación posterior - Imposible identificar a un huésped repetidor y diferenciar la oferta respecto a una primera estancia ### Cita del cliente > Teníamos una base de datos enorme construida durante años, pero no éramos capaces de hacer nada útil con ella. Cada verano llenábamos los resorts pagando comisiones a las OTAs mientras nuestros propios huéspedes de años anteriores reservaban a través de Booking porque nadie les había ofrecido una razón para volver directo. Dirección de Marketing Digital, Catalonia Hotels & Resorts ### Qué se puso en marcha #### Journeys multilingües de recuperación y fidelización Secuencias orientadas a convertir a huéspedes previos en reservas directas futuras, con contenido adaptado al idioma y al mercado de origen. - Secuencia posterior a la salida, activada automáticamente 24 horas después desde SAP - Encuesta de satisfacción con el nombre del hotel y las fechas reales de estancia - Oferta de reserva anticipada para el destino visitado, con precio garantizado mejor que el del intermediario - Reactivación a los seis meses para quien no tenga reserva activa #### Perfil unificado del huésped vacacional Consolidación de todas las fuentes de datos en un perfil único que alimenta en tiempo real las decisiones de segmentación y personalización. - Unificación de registros de SAP, formularios web, historial de email y motor de reservas - Identificación de huéspedes repetidores y cálculo del valor estimado de vida del cliente - Segmentos dinámicos por destino visitado, número de estancias, mercado de origen y canal de la última reserva - Detección de contactos en riesgo de perderse, para activar la reactivación antes de que ocurra #### Integración con el sistema de gestión hotelera Conexión bidireccional con SAP para que los datos de estancia real alimenten las acciones de marketing sin intervención manual. - Sincronización automática de entradas y salidas al perfil unificado - Traslado de las preferencias registradas en recepción: tipo de habitación, régimen y peticiones especiales - Actualización del historial de estancias en tiempo real para la segmentación - Envío en sentido contrario de las preferencias de contacto: bajas y idioma preferido #### Captación de reserva directa Comunicaciones orientadas a interceptar la intención de reserva antes de que llegue a un intermediario, con la ventaja del canal directo explicada de forma explícita. - Campaña dirigida a huéspedes cuya última reserva fue por intermediario - Ventajas del canal directo: precio garantizado, mejora de habitación según disponibilidad y entrada flexible - Secuencia de urgencia en las dos semanas previas a temporada alta, con disponibilidad real integrada - Prueba sistemática de asunto y oferta por mercado para ir ajustando ### Resultados Medidos por el cliente sobre su propio punto de partida. «pp» son puntos porcentuales, que no es lo mismo que una variación relativa. | Indicador | Antes | Después | Variación | | --- | --- | --- | --- | | Reservas de resort por canal directo | 38% | 56% | +18 pp | | Comisión media pagada a intermediarios | 18,4% | 14,1% | −4,3 pp | | Revenue atribuible a email en temporada alta | Referencia | ×2,4 | ×2,4 | | Tasa de apertura de email | 11% | 31% | +20 pp | | Pérdida anual de la base de datos | 28% | 16% | −12 pp | ### Retorno declarado - Retorno de la inversión alcanzado: 6 meses - Revenue de email frente al coste de licencias, tres meses tras el arranque: ×4 ### Fases del proyecto - Descubrimiento y arquitectura de datos (3 semanas): Auditoría de la base existente, mapeo de las fuentes de SAP y definición del modelo de datos unificado. - Integración con SAP (5 semanas): Conexión bidireccional entre el PMS y Salesforce: entradas y salidas, preferencias e historial de estancias. - Perfil unificado (4 semanas): Implantación del perfil de huésped, segmentos dinámicos y reglas de identidad. - Journeys y campañas (5 semanas): Configuración de los journeys multilingües, plantillas por mercado y lógica de prueba comparativa. - Pruebas y formación (2 semanas): Validación con datos reales y formación al equipo de marketing digital. - Arranque y acompañamiento (4 semanas): Activación por mercado y seguimiento de las primeras campañas. ### Qué pedía el proyecto - Integración con SAP mediante MuleSoft, un requisito que descartó a varios candidatos en el proceso de selección - Conocimiento del cliente vacacional internacional: multilingüe, estacional y con ciclos de decisión largos - Modelado de datos de cliente y resolución de identidades para activar una base histórica de casi un millón de contactos - Capacidad de acompañamiento recurrente: optimizar campañas multilingües por mercado es trabajo continuo, no un proyecto que se cierra --- ## Derby Hotels Collection: Cada hotel era una isla, en un grupo de lujo - URL: https://kaizenstep.com/casos-exito/derby-hotels-collection - Sector: Hospitality · Lujo - Escala: 18 hoteles boutique en Barcelona, Madrid, Londres y París - Duración del proyecto: 26 semanas - Productos Salesforce: Marketing Cloud, Sales Cloud, Service Cloud, Data Cloud Un huésped que había estado en cinco hoteles del grupo no se reconocía como el mismo al llamar, las solicitudes de grupos tardaban 96 horas de media en responderse y la conversión de la web directa se quedaba en el 14%. Unificamos el perfil del huésped sobre tres sistemas de gestión distintos y centralizamos atención, personalización y el proceso comercial de grupos. ### La compañía Derby Hotels Collection es un grupo hotelero familiar fundado en 1968, especializado en hoteles boutique de 4 y 5 estrellas en ubicaciones premium de Europa. Combina patrimonio histórico (palacios y edificios emblemáticos) con servicio personalizado de alta gama. Su cliente objetivo es turismo de alto poder adquisitivo, mezclando ocio y corporativo premium. ### El punto de partida El grupo operaba con sistemas heredados que impedían ofrecer la personalización que espera un huésped de lujo. Cada hotel gestionaba su comunicación con herramientas básicas, el equipo comercial de grupos trabajaba con procesos manuales en hoja de cálculo y correo, y no existía una visión unificada del huésped que viajaba entre propiedades del grupo. En un segmento donde el precio se justifica por el servicio, no saber que alguien prefiere planta alta o que es alérgico a algo no es un detalle operativo: es la propuesta de valor incumplida. Problemas concretos: - Conversión del 14% en reservas directas por web, con los abandonos sin ningún seguimiento - Tiempo medio de respuesta a solicitudes de grupos, MICE y corporativo: 96 horas - Comunicaciones genéricas, sin personalizar por las preferencias del huésped - El 41% de los huéspedes repetidores no recibía ninguna oferta personalizada de retorno - Sin visibilidad del historial completo cuando un huésped contactaba por canales distintos - Restaurantes gastronómicos con baja ocupación por falta de venta cruzada desde el hotel ### Cita del cliente > Teníamos huéspedes que habían estado en 5 de nuestros hoteles y cuando llamaban no sabíamos si preferían planta alta, almohada de plumas o si eran alérgicos. Cada hotel era una isla. Para un grupo de lujo, eso es inaceptable. Marc Forcadell, Director of Sales, Derby Hotels Collection ### Qué se puso en marcha #### Journeys de relación Comunicaciones automáticas segmentadas por fase del viaje y perfil del huésped, diseñadas para mantener la relación sin saturar, que en el segmento premium es la línea que no se puede cruzar. - Bienvenida personalizada a contactos nuevos con la presentación de la colección - Secuencia previa a la estancia con venta cruzada contextual: spa, cenas, experiencias locales, mejora de habitación - Reactivación automática de huéspedes inactivos más de doce meses, según los hoteles ya visitados - Encuesta de satisfacción 48 horas después, con escalado automático si la valoración baja de siete #### Journeys de ingreso directo Automatizaciones orientadas específicamente a recuperar margen reduciendo la dependencia del canal intermediado. - Secuencia de tres correos a quien abandona una reserva, con incentivo progresivo - Programa de recomendación con código único tras confirmar reserva - Venta cruzada posterior a la reserva: restaurantes, spa y experiencias - Ventaja explícita del canal directo frente al intermediado, comunicada a la base #### Gestión comercial de grupos y corporativo CRM para el equipo de ventas corporativas, agencias y MICE, con generación de propuestas y previsión integrada con revenue management. - Cuentas corporativas con múltiples contactos por empresa - Avisos de renovación de contrato marco con 60 días de antelación - Generación automática de propuestas multihotel para grupos - Conexión con el sistema de tarifas para precios corporativos dinámicos #### Atención premium omnicanal Unificación de todos los puntos de contacto con identificación automática del huésped y acceso a su perfil completo. - Canales integrados: teléfono, email, chat web, mensajería y formularios - Gestión de peticiones especiales: alergias, preferencias de habitación, aniversarios - Compromisos de respuesta diferenciados: una hora para huéspedes alojados, cuatro para reservas confirmadas - Escalado automático al hotel de destino cuando la petición exige acción local #### Perfil unificado del huésped Consolidación de todas las interacciones en un perfil único accesible por marketing, comercial, atención al cliente y los propios hoteles. - Historial completo de estancias en todos los hoteles de la colección - Preferencias declaradas y observadas: tipo de habitación, planta, almohada, minibar - Consumo en restaurantes, spa y experiencias, para puntuar la propensión a la venta cruzada - Segmentación automática: VIP, viajero de negocio, pareja de ocio, familia ### Resultados Medidos por el cliente sobre su propio punto de partida. «pp» son puntos porcentuales, que no es lo mismo que una variación relativa. | Indicador | Antes | Después | Variación | | --- | --- | --- | --- | | Conversión de reserva directa por web | 14% | 20% | +6 pp | | Tiempo de respuesta a solicitudes de grupos | 96 horas | 27 horas | −72% | | Abandonos de reserva recuperados | 0% | 12% | +12 pp | | Tasa de apertura de email | 18% | 34% | +16 pp | ### Retorno declarado - Retorno de la inversión alcanzado: 11 meses - Revenue de venta cruzada previa, en el segundo año: 520.000 €/año - Revenue recuperado de abandonos: 280.000 €/año - Reservas directas frente al canal intermediado: +8,2 pp ### Fases del proyecto - Descubrimiento y diseño (5 semanas): Mapeo del recorrido del huésped de lujo, de los procesos comerciales B2B y de los requisitos de integración con los sistemas de gestión. - Integración y perfil unificado (6 semanas): Conexión con los sistemas de gestión hotelera de las distintas propiedades y con el motor de reservas. - Journeys (7 semanas): Configuración de ocho journeys automatizados, segmentación avanzada y plantillas propias de cada hotel. - Comercial B2B (4 semanas): CRM de ventas, canal de grupos y MICE, conexión con el tarifario corporativo y cuadros de mando. - Atención al cliente (4 semanas): Atención omnicanal, gestión de casos, compromisos de respuesta premium y base de conocimiento. - Pruebas y formación (4 semanas): Validación en los hoteles piloto de Barcelona y formación a los equipos de marketing, comercial y atención. - Arranque escalonado (3 semanas): Despliegue progresivo: Barcelona, Madrid, Londres y París. ### Qué pedía el proyecto - Experiencia en hotelería premium, donde la personalización es la propuesta de valor y no un añadido - Journeys de huésped complejos con segmentación avanzada, no solo campañas de envío masivo - Integración con varios sistemas de gestión hotelera distintos, uno por grupo de propiedades - Perfil unificado de cliente en producción, no como prueba de concepto - Indicadores de negocio (conversión, valor de vida del cliente, revenue) en lugar de métricas técnicas --- ## HTOP Hotels: Ochenta touroperadores en la cabeza de cada director de hotel - URL: https://kaizenstep.com/casos-exito/htop-hotels - Sector: Hospitality · Vacacional - Escala: 12 hoteles de playa en el Maresme y la Costa Brava - Duración del proyecto: 24 semanas - Productos Salesforce: Sales Cloud, Marketing Cloud, Data Cloud, MuleSoft, Experience Cloud El 75% del inventario se vendía a través de touroperadores europeos, pero la relación comercial vivía en la cabeza de cada director y la producción se controlaba en hoja de cálculo. Montamos la gestión de cuentas, contratos y cupos, y construimos el perfil del huésped final pese a que la reserva llegaba por intermediario. ### La compañía HTOP Hotels es una cadena hotelera familiar fundada en 1977, especializada en hoteles de playa de 3 y 4 estrellas en la costa catalana. Con doce hoteles y una estacionalidad marcada de mayo a octubre, opera vendiendo el 75% de su inventario a través de touroperadores europeos y agencias mayoristas, con cliente final principalmente de Francia, Alemania, Reino Unido y Países Bajos. El 25% restante es venta directa por web y agencias locales. ### El punto de partida El modelo comercial estaba fragmentado: cada director de hotel gestionaba sus propias relaciones con touroperadores y agencias sin visibilidad central. El departamento comercial corporativo controlaba la producción por agencia, las tarifas contratadas y los compromisos de cupo en hoja de cálculo, sin capacidad de previsión ni de análisis de tendencia. Y a pesar de recibir miles de huéspedes cada temporada, HTOP no tenía perfil del cliente final, porque las reservas llegaban a través de intermediarios. Se perdía la oportunidad de fidelizar directamente y de generar reserva directa en estancias futuras. Problemas concretos: - El 75% de la producción venía de touroperadores, sin ningún sistema para gestionar cuentas, contratos ni producción histórica - La renovación de un contrato marco tardaba de cuatro a seis semanas, negociada por correo y teléfono sin seguimiento estructurado - La producción por agencia se controlaba en hoja de cálculo, sin avisos de caída de volumen ni comparativa automática entre años - Tasa de repetición del 23%, frente a una media de sector del 35% al 40%, porque no había comunicación posterior a la estancia ### Cita del cliente > Teníamos 80 touroperadores y agencias activas, pero la información estaba en la cabeza de los directores comerciales de cada hotel. Si alguien se iba, perdíamos toda la relación comercial. No podíamos crecer así. Jorge A. Marín, Director Comercial, HTOP Hotels ### Qué se puso en marcha #### CRM de ventas B2B Gestión completa de las cuentas de touroperadores y agencias, con control de producción, contratos marco, tarifas negociadas y cupos comprometidos. - Ficha de cuenta con múltiples contactos: revenue manager, contratación, producto - Producción histórica comparada entre años y tarifas contratadas por hotel y temporada - Canal de renovación de contratos con avisos 90 días antes del vencimiento - Clasificación automática de agencias por volumen anual, con trato comercial diferenciado #### Journeys al huésped final Comunicación con el huésped a pesar de que la reserva llegó por intermediario, recuperando el correo en el registro de entrada para fidelizar y convertir en directo la estancia siguiente. - Secuencia previa a la llegada siete días antes, con información práctica y oferta de servicios - Encuesta de satisfacción 48 horas después de la salida, con oferta de repetición por canal directo - Segmento de repetidores con comunicaciones diferenciadas y reserva anticipada - Campañas estacionales de reserva anticipada para la temporada alta #### Perfil unificado del huésped Consolidación de los datos del huésped final agregando el PMS (donde la reserva figura a nombre del touroperador), la web y el comportamiento de email. - Emparejamiento de reservas intermediadas con búsquedas web y correos previos para identificar a la misma persona - Historial consolidado de estancias en los doce hoteles, aunque cada vez se reservara por un touroperador distinto - Segmentación por recencia, frecuencia y gasto, para priorizar a los mejores clientes - Puntuación de propensión a reservar directo según estancias previas y comportamiento con las ofertas #### Gestión de cupos y tarifas Automatización de la actualización de tarifas, cupos y disponibilidad en las extranets de los touroperadores directamente desde Salesforce. - Los cambios de precio por hotel y temporada se replican automáticamente en las extranets - Liberación de cupos no producidos con la antelación configurada por cada touroperador - Envío mensual automático a cada touroperador con su producción, comparativa anual y previsión - Aviso automático si la suma de cupos comprometidos y reservas directas supera la capacidad #### Portal para agencias minoristas Portal de autoservicio donde las agencias consultan disponibilidad y precios y reservan sin intermediarios. - Catálogo de los doce hoteles con tarifas en tiempo real según disponibilidad del PMS - Motor de reserva con cálculo de comisión y confirmación instantánea - Panel de reservas activas, modificaciones, cancelaciones y facturación descargable - Cuadro de mando por agencia con su producción anual y los hoteles que más vende ### Resultados Medidos por el cliente sobre su propio punto de partida. «pp» son puntos porcentuales, que no es lo mismo que una variación relativa. | Indicador | Antes | Después | Variación | | --- | --- | --- | --- | | Producción de agencias, en noches de habitación al año | 58.400 | 74.750 | +28% | | Tiempo de renovación de contratos | 4–6 semanas | 1,5 semanas | −65% | | Tasa de repetición de huéspedes | 23% | 31% | +8 pp | | Conversión de email posterior a la estancia en reserva directa | 0% | 4,2% | +4,2 pp | | Diferencia de precio medio del canal directo frente al intermediado | −18% | −8% | +10 pp | ### Retorno declarado - Revenue por mejor gestión de agencias: 980.000 €/año - Revenue de conversión a canal directo, sin comisión: 420.000 €/año - Ahorro de tiempo en gestión comercial: 1,5 personas equivalentes ### Fases del proyecto - Descubrimiento y diseño (4 semanas): Mapeo de los procesos comerciales B2B, análisis de los flujos de datos del PMS y diseño de la arquitectura de integración. - Integración con el PMS (5 semanas): Desarrollo del conector y sincronización bidireccional de reservas, huéspedes y disponibilidad. - Perfil unificado (4 semanas): Reglas de deduplicación y emparejamiento, e importación de cinco años de histórico: 280.000 registros. - CRM B2B (6 semanas): Cuentas de touroperadores y agencias, canal de renovación, cuadros de mando de producción y gestión de cupos. - Journeys al huésped (5 semanas): Secuencias previas y posteriores a la estancia, segmentación por perfil de viajero y conexión con el perfil unificado. - Portal de agencias (3 semanas): Motor de reserva B2B, catálogo de hoteles y panel de gestión para las agencias. - Pruebas y formación (3 semanas): Validación con el equipo comercial, formación a los directores de hotel y documentación de procesos. - Arranque escalonado (2 semanas): Por fases: primero el CRM B2B, después los journeys y por último el portal de agencias. ### Qué pedía el proyecto - Entender el modelo del hotel vacacional que vende mayoritariamente por touroperador, distinto del urbano, que es más directo - Integrar no solo el PMS sino también las extranets de los principales touroperadores, para actualizar tarifas y cupos - CRM B2B complejo: cuentas corporativas con contratos marco, cupos comprometidos y producción histórica - Perfil unificado del huésped a pesar de la reserva intermediada, que exige lógica avanzada de emparejamiento - Indicadores de negocio acordados de partida, no métricas técnicas genéricas --- ## Cadena hotelera urbana española: Ciento diez hoteles comunicando cada uno por su cuenta - URL: https://kaizenstep.com/casos-exito/grupo-hotelero-espana - Sector: Hospitality · Urbano - Escala: Más de 110 hoteles urbanos - Duración del proyecto: 22 semanas - Productos Salesforce: Service Cloud, Marketing Cloud, Agentforce, Data Cloud Marketing, atención al cliente y los equipos comerciales de grupos trabajaban con herramientas desconectadas: un tercio de las incidencias no se resolvía en 24 horas y las peticiones de grupos se contestaban desde bandejas personales en 72 horas. Unificamos la atención, el perfil del huésped y el proceso de grupos, con un agente de IA generando las propuestas. ### La compañía Una de las cadenas hoteleras españolas de referencia, especializada en hoteles urbanos situados en el centro de las principales ciudades. Combina hoteles en propiedad, en gestión y en franquicia, con un cliente corporativo de lunes a jueves y de ocio los fines de semana. Esa alternancia semanal es la que obliga a segmentar la comunicación por tipo de estancia y no solo por hotel. ### El punto de partida La cadena operaba con sistemas fragmentados que dificultaban ofrecer una experiencia consistente en más de cien hoteles. El equipo central de marketing, el centro de atención y los equipos comerciales de grupos trabajaban con herramientas desconectadas entre sí. El email marketing se gestionaba con una herramienta básica sin segmentación avanzada, las solicitudes de grupos se respondían desde bandejas de correo personales, y el programa de fidelización no podía activar comunicaciones según el comportamiento del huésped. Problemas concretos: - Tiempo medio de respuesta a solicitudes de grupos: 72 horas - Conversión de peticiones de grupos y eventos a reserva confirmada: solo el 18% - El 34% de las incidencias de huésped no se resolvía en 24 horas - Tasa de apertura de email del 12%, por falta de personalización - Sin visibilidad del perfil completo del huésped al atenderle por teléfono - Los equipos de revenue y de marketing trabajaban con datos distintos y desconectados ### Cita del cliente > Teníamos 110 hoteles enviando comunicaciones por su cuenta, un contact center que no sabía si el huésped que llamaba era miembro del programa de fidelización o no, y un equipo de grupos respondiendo solicitudes desde bandejas de email personales. No podíamos escalar así. Dirección de Transformación Digital ### Qué se puso en marcha #### Atención al huésped centralizada Unificación de todos los canales en una sola consola, con identificación automática y acceso al historial completo de estancias e incidencias. - Canales unificados: teléfono, email, chat web y mensajería - Identificación automática del huésped al contactar - Historial completo de estancias, incidencias previas y preferencias - Escalado automático al hotel cuando la resolución exige acción local #### Gestión de grupos y eventos con IA Automatización de la respuesta a solicitudes de grupos: el agente genera una propuesta completa en minutos en lugar de días. Es el bloque que explica la mayor parte del resultado. - Consulta automatizada de disponibilidad y precio en los hoteles que encajan con la solicitud - Visibilidad de la disponibilidad de salas, recursos y restauración - Recepción de la petición por correo y redacción de la propuesta en el tono de la cadena - Sugerencia de servicios adicionales: pausas de café, cenas, traslados #### Cotización de series para el canal B2B Reservas periódicas para empresas y agencias, que antes se cotizaban a mano una por una. - Recepción de peticiones por correo, formulario y mensajería - Creación automática de la cotización con fechas y precios del sistema de gestión - Envío de la propuesta en documento formateado - Gestión de los cambios de fecha que solicita el cliente y envío de la reserva al PMS #### Journeys de huésped Comunicaciones personalizadas en cada fase del viaje, desde la confirmación hasta después de la estancia, con personalización según historial y preferencias. - Confirmación con venta cruzada contextual: aparcamiento, salida tardía, restaurante - Recordatorio 48 horas antes con información práctica del destino - Oferta de mejora de habitación automática cuando hay disponibilidad - Encuesta de satisfacción posterior a la estancia #### Perfil unificado del huésped Consolidación de todos los datos en un perfil único, accesible por marketing, atención al cliente y los hoteles, para personalizar en tiempo real. - Historial de estancias en todos los hoteles de la cadena - Preferencias declaradas: tipo de habitación, almohada, planta - Incidencias previas y cómo se resolvieron - Situación en el programa de fidelización: nivel, puntos y ventajas ### Resultados Medidos por el cliente sobre su propio punto de partida. «pp» son puntos porcentuales, que no es lo mismo que una variación relativa. | Indicador | Antes | Después | Variación | | --- | --- | --- | --- | | Tiempo de respuesta a solicitudes de grupos | 72 horas | 23 horas | −68% | | Conversión de peticiones de grupos a reserva | 18% | 22% | +4 pp | | Incidencias resueltas en menos de 24 horas | 66% | 91% | +25 pp | | NPS posterior a la estancia | 42 | 51 | +9 puntos | ### Retorno declarado - Retorno de la inversión alcanzado: 14 meses - Revenue de venta cruzada previa a la estancia: 340.000 €/año - Coste por caso en atención al cliente: −22% - Grupos cerrados por comercial y mes: +35% ### Fases del proyecto - Descubrimiento y diseño (4 semanas): Mapeo de los journeys de huésped, del proceso de grupos y de los requisitos de integración con el sistema de gestión. - Integración con el PMS (5 semanas): Conexión bidireccional con el sistema de gestión hotelera y el motor de reservas. - Atención al cliente (4 semanas): Consola de atención, categorías de caso, compromisos de respuesta y cuadros de mando operativos. - Journeys de marketing (6 semanas): Configuración de journeys, plantillas, segmentación y conexión con el perfil unificado. - Agente de IA para grupos (3 semanas): Configuración del agente, sus instrucciones y el flujo de propuesta automática. - Pruebas y formación (3 semanas): Validación y formación a los equipos de marketing, atención al cliente y grupos. - Arranque escalonado (2 semanas): Por áreas, empezando por atención al cliente, que era el mayor punto de dolor, y siguiendo con marketing. ### Qué pedía el proyecto - Experiencia en hotelería: estacionalidad, integración con sistemas de gestión y gestión de grupos y eventos - Integración con dos sistemas de gestión hotelera distintos, porque la cadena opera en propiedad, gestión y franquicia - Journeys de huésped ya implantados en proyectos anteriores, no diseñados por primera vez aquí - Un arranque por fases que diera resultado pronto, empezando por el área con más dolor en lugar de por la más fácil - Capacidad de evolución continua de la plataforma después del arranque --- ## Alifarma: Tres formulaciones casi idénticas, desarrolladas en paralelo sin saberlo - URL: https://kaizenstep.com/casos-exito/alifarma - Sector: Ingredientes para alimentación - Escala: 100 empleados · España y Portugal - Duración del proyecto: 17 semanas - Productos Salesforce: Sales Cloud, Salesforce Mobile Cada comercial llevaba sus proyectos de formulación en su propio Excel, con las especificaciones repartidas en correos y carpetas compartidas. Modelamos el proceso de venta técnica con el equipo de I+D dentro, la gestión de muestras y una biblioteca de soluciones reutilizable. ### La compañía Alifarma desarrolla y comercializa ingredientes funcionales, aditivos y soluciones a medida para fabricantes de alimentación. Su propuesta de valor son las formulaciones personalizadas que resuelven un reto técnico concreto de cada cliente: textura, conservación, sabor, etiqueta limpia o reducción de azúcar. Eso convierte cada venta en un proyecto técnico de meses, no en un pedido. ### El punto de partida El modelo de negocio es consultivo: cada cliente requiere un proceso de venta técnica que puede durar meses e involucrar múltiples interacciones entre comerciales, el equipo de I+D y el propio cliente. Antes del proyecto, ese proceso se gestionaba con hojas de cálculo individuales donde cada comercial llevaba sus proyectos, correos dispersos con las especificaciones técnicas de cada desarrollo, carpetas compartidas con fichas y muestras enviadas, y una reunión semanal para que dirección supiera el estado de todo. Problemas concretos: - Pérdida del histórico cuando un comercial dejaba la empresa o cambiaba de zona - Desarrollos duplicados: I+D trabajaba en formulaciones similares para clientes distintos sin saberlo - Seguimiento manual de las muestras enviadas y del retorno del cliente - Sin visibilidad del embudo: dirección no sabía qué proyectos tenían más probabilidad de cerrar - Ciclos de venta largos, sin ningún aviso de proyecto estancado - El conocimiento técnico no se capitalizaba: las soluciones desarrolladas no se documentaban para reutilizarlas ### Cita del cliente > Descubrimos que I+D estaba trabajando en tres formulaciones casi idénticas para clientes distintos, sin saberlo. Cada comercial pedía su desarrollo desde cero porque no había forma de saber qué habíamos hecho antes para problemas similares. Jesús Navas, Business Director, Alifarma ### Qué se puso en marcha #### Cuentas técnicas La ficha de cada fabricante deja de ser datos de contacto y pasa a describir su realidad técnica, que es lo que permite anticipar qué se le puede vender. - Qué productos fabrica, qué retos técnicos tiene y qué ingredientes ya usa - Historial de desarrollos realizados, tanto los que funcionaron como los que no - Mapa de contactos: compras, I+D, calidad y producción - Segmentación por sector: panadería, lácteos, cárnicos, aperitivos #### Embudo de proyectos de desarrollo Etapas que describen el proceso real de una venta técnica, en lugar de las etapas genéricas de una venta transaccional. - Detección de necesidad, propuesta técnica, muestras, pruebas industriales, homologación y pedido - Probabilidad de cierre según la etapa y el retorno recibido del cliente - Valor estimado del proyecto: volumen anual por precio - Fecha objetivo de cierre y avisos de proyecto estancado #### Gestión de muestras y pruebas El seguimiento que antes vivía en correos y carpetas, dentro del sistema y vinculado a la oportunidad. - Registro de cada muestra enviada: formulación, fecha y cantidad - Seguimiento del retorno del cliente tras las pruebas - Vinculación de los resultados de laboratorio a la oportunidad - Histórico de iteraciones hasta llegar a la formulación final #### Biblioteca de soluciones técnicas El bloque que resolvió el problema de la cita: convertir el conocimiento acumulado en algo que se puede encontrar y reutilizar. - Base de conocimiento con los desarrollos anteriores que funcionaron - Búsqueda por aplicación, funcionalidad o ingrediente - Reutilización de formulaciones base para proyectos nuevos - Menos tiempo de I+D en desarrollos parecidos a otros ya hechos #### Previsión e informes La reunión semanal para que dirección supiera el estado de los proyectos deja de ser necesaria. - Embudo por comercial, sector y tipo de aplicación - Previsión de facturación construida con los proyectos en curso - Análisis de la tasa de conversión por etapa - Tiempo medio de ciclo de venta por tipo de proyecto ### Resultados Medidos por el cliente sobre su propio punto de partida. «pp» son puntos porcentuales, que no es lo mismo que una variación relativa. | Indicador | Antes | Después | Variación | | --- | --- | --- | --- | | Tiempo de desarrollo de una formulación personalizada | 45 días | 29 días | −16 días | | Conversión de proyecto de I+D a pedido | 23% | 30% | +7 pp | | Proyectos gestionados por comercial | 12 | 18 | +50% | | Tiempo dedicado a informes | 4 h/semana | 30 min/semana | −87% | ### Retorno declarado - Retorno de la inversión alcanzado: 18 meses - Ahorro en I+D por reutilización de desarrollos: +6% - Incremento de proyectos cerrados al año: +7% ### Fases del proyecto - Descubrimiento y diseño (4 semanas): Mapeo del ciclo de venta técnica y definición de las etapas y los campos. - Configuración del CRM (6 semanas): Cuentas, oportunidades y objetos propios para muestras y formulaciones. - Biblioteca de soluciones (3 semanas): Migración de los desarrollos históricos y estructura de búsqueda por aplicación. - Migración de datos (2 semanas): Cuentas, contactos y proyectos en curso. - Formación y arranque (2 semanas): Formación a comerciales y a I+D, y acompañamiento posterior. ### Qué pedía el proyecto - Experiencia en fabricación de producto a medida, donde la venta es un proyecto técnico y no un pedido - Integración con el ERP para no duplicar el maestro de clientes y artículos - Enfoque consultivo: el proceso había que modelarlo, no recogerlo de un pliego de requisitos --- ## Consultoría de Salesforce Sales Cloud - URL: https://kaizenstep.com/salesforce/consultoria/sales-cloud - Producto: Sales Cloud El sistema donde vive la relación comercial: a quién vendes, en qué punto está cada operación y qué va a cerrar este trimestre. Sales Cloud es el núcleo comercial de Salesforce: cuentas, contactos, oportunidades, previsión y la actividad que las sostiene. Es la pieza que más se implanta y también la que más se implanta mal, porque es fácil configurarla como un registro de lo que ya pasó en lugar de como una herramienta para decidir. Trabajamos Sales Cloud desde el proceso comercial real (quién decide, quién compra, cuántas manos toca una venta) y no desde el catálogo de campos. ### Cuatro problemas que no se arreglan con licencias Casi nunca es «queremos Sales Cloud». Es una de estas cuatro, y las cuatro se resuelven en el modelo, no en la licencia. - **La previsión no se sostiene.** Las etapas del embudo describen lo que hace el comercial y no lo que hace el cliente, así que una oportunidad en «propuesta enviada» puede estar viva o muerta. Cuando la etapa no tiene criterio de salida, la previsión es una suma de opiniones. - **El pipeline se rellena para el informe.** El equipo actualiza el CRM la víspera de la reunión porque el sistema no le devuelve nada durante la semana. El dato existe, pero llega tarde y sesgado, y la dirección decide sobre una foto que ya no es cierta. - **El canal indirecto es una caja negra.** Cuando se vende a través de distribuidores, agencias o prescriptores, el CRM ve el pedido pero no la relación. Falta saber quién prescribe, qué produce cada cuenta y cuándo toca renovar. - **La venta la tocan cuatro personas.** Preventa, oficina técnica, dirección y administración intervienen en la misma operación y cada una guarda su parte en otro sitio. La oportunidad en Salesforce solo cuenta un tramo del recorrido. ### Primero se decide qué modela el sistema El trabajo está en decidir qué modela el sistema y qué no. Configurar viene después y es la parte corta. - **Modelar el proceso que existe.** Etapas con criterio de entrada y de salida verificable, no con nombres de intención. Si nadie puede decir por qué una oportunidad está en una etapa y no en la siguiente, la etapa no sirve para prever. - **Estructurar cuenta, contacto y decisor.** En venta compleja quien firma, quien usa y quien recomienda son personas distintas. El modelo tiene que poder representar eso sin obligar a inventar cuentas duplicadas. - **Hacer visible el canal.** Distribuidores, agencias y prescriptores como cuentas con su producción, sus contratos y sus renovaciones, para que la relación deje de vivir en la cabeza de una persona. - **Devolver algo al comercial.** Que abrir Salesforce ahorre trabajo el mismo día: su cartera priorizada, la actividad pendiente, el histórico del cliente y la propuesta a un clic. Es la única forma conocida de que el dato entre a tiempo. - **Previsión y cuadros de mando.** Previsión por responsable, por producto y por canal, con el criterio explicado, y los informes que la dirección va a mirar de verdad. Un informe que nadie se cree no lo usa nadie. - **Conectar con quien manda el dato.** El ERP suele ser el dueño del cliente facturable, del producto y del precio; Sales Cloud, el de la relación. Esa frontera se decide campo a campo antes de integrar. ### Lo que Sales Cloud no resuelve La mitad de los proyectos que se atascan lo hacen por pedirle a Sales Cloud algo que no es suyo. Conviene saberlo antes de comprar licencias. - **La atención posventa no es suyo.** Casos, colas y compromisos de respuesta son Service Cloud. Se puede forzar con oportunidades, y se acaba deshaciendo. - **La automatización de marketing tampoco.** Journeys, segmentación y campañas viven en Marketing Cloud o en Account Engagement; Sales Cloud consume el resultado, no lo produce. - **No es el maestro de producto ni de precio.** Eso casi siempre es del ERP. Duplicarlo aquí crea dos maestros que divergen y un equipo que no se fía de ninguno. - **No arregla un proceso que no existe.** Si la organización no tiene un criterio para calificar una oportunidad, el CRM no se lo va a inventar: lo va a hacer visible, que ya es algo, pero el criterio hay que decidirlo. - **No compra adopción.** Que el sistema esté bien montado es condición necesaria y no suficiente; por eso la adopción es un servicio aparte y no una fase del proyecto. ### Proyectos con ficha de caso - Derby Hotels Collection (https://kaizenstep.com/casos-exito/derby-hotels-collection): Gestión de cuentas corporativas, agencias, MICE y grupos, con previsión del negocio B2B - HTOP Hotels (https://kaizenstep.com/casos-exito/htop-hotels): CRM B2B para touroperadores y agencias mayoristas y minoristas, con canal de renovación de contratos y producción por cuenta - Alifarma (https://kaizenstep.com/casos-exito/alifarma): Gestión de cuentas técnicas, oportunidades y proyectos de desarrollo, con objetos propios para muestras y formulaciones ### Preguntas frecuentes **¿Qué incluye un proyecto de Sales Cloud con Kaizen?** Un proyecto de Sales Cloud parte del proceso comercial real (cómo se capta, se califica, se propone y se cierra) y de ahí sale el modelo de datos, las etapas con criterio verificable, la previsión, los informes de dirección y la integración con el sistema que sea dueño del producto y del precio, normalmente el ERP. La configuración es la parte corta; el trabajo está en decidir qué modela el sistema y qué se deja fuera. **¿Cuál es la diferencia entre Salesforce y Sales Cloud?** Salesforce es la plataforma y Sales Cloud es su producto de ventas: cuentas, contactos, oportunidades, previsión y actividad comercial. Cuando alguien dice «tenemos Salesforce» casi siempre quiere decir que tiene Sales Cloud. La atención al cliente (Service Cloud), la automatización de marketing (Marketing Cloud o Account Engagement) y los agentes de IA (Agentforce) son productos distintos que se licencian aparte. **¿Sirve Sales Cloud si vendemos a través de distribuidores?** Sí, y es uno de los usos donde más se nota, pero exige modelarlo a propósito. Sales Cloud representa bien el canal indirecto cuando distribuidores, agencias y prescriptores se tratan como cuentas con su producción, sus contratos y sus renovaciones. HTOP Hotels lo usa así para ochenta touroperadores europeos, con un canal de renovación de contratos y producción por cuenta. **¿Podemos empezar solo con Sales Cloud y añadir el resto después?** Es lo más habitual y suele ser lo más sensato: Sales Cloud primero, y las demás piezas cuando haya un problema concreto que las justifique. Lo que conviene decidir desde el principio es el modelo de cliente, porque es lo que después comparten Service Cloud, Marketing Cloud y Agentforce. Cambiar el modelo con tres productos encima cuesta bastante más que pensarlo una vez. --- ## Consultoría de Salesforce Service Cloud - URL: https://kaizenstep.com/salesforce/consultoria/service-cloud - Producto: Service Cloud El sistema donde vive lo que el cliente pide después de comprar, con el contexto de todo lo anterior. Service Cloud es la pieza de atención: casos, colas, categorías, compromisos de respuesta y el histórico del cliente en la misma ficha que usa el equipo comercial. Su valor no está en abrir tickets, está en que quien atiende tenga delante todo lo que el cliente ha comprado, preguntado y reclamado antes. Trabajamos Service Cloud partiendo de qué pide el cliente y por qué canal, no del organigrama del departamento de atención. ### Atender a ciegas, y sin saber si se cumple lo prometido Casi siempre es una de estas cuatro, y ninguna se arregla añadiendo canales. - **Quien atiende trabaja a ciegas.** El cliente llama y al otro lado no se sabe qué compró, qué reclamó el mes pasado ni si hay una oportunidad abierta con él. Se resuelve la petición y se pierde la relación. - **Las peticiones viven en bandejas personales.** Correos que llegan a la dirección de una persona concreta. Si está de vacaciones, la petición no existe; y no hay forma de saber cuántas hay abiertas ni cuánto llevan esperando. - **Nadie sabe si se cumple lo prometido.** Se ha comprometido un plazo de respuesta por contrato o por política interna, pero no hay dato para saber si se cumple. Sin categoría y sin reloj, el compromiso es una intención. - **Cada canal es un sistema.** Teléfono, correo, formulario web y mensajería van por separado, así que el mismo cliente preguntando lo mismo por dos vías genera dos historias que nunca se juntan. ### La cola y la categoría son el diseño El diseño de la cola y de la categoría decide si el sistema sirve para dirigir el servicio o solo para archivarlo. - **Modelar el caso y su categoría.** Qué tipos de petición existen de verdad, cuál es el criterio para clasificarlas y qué información hace falta en cada una. Una taxonomía con veinte categorías que nadie distingue no mide nada. - **Colas, asignación y escalado.** Quién recibe qué, en qué orden y qué pasa cuando se supera el plazo. Incluido el caso incómodo: qué ocurre con lo que no encaja en ninguna cola. - **Compromisos de respuesta por categoría.** Plazos distintos según lo que se pide y según el cliente, con el reloj dentro del sistema. Es lo que convierte «respondemos rápido» en un indicador. - **Unificar los canales.** Teléfono, correo, web y mensajería entrando al mismo caso, para que el histórico sea uno. El canal es cómo llega la petición, no una petición distinta. - **La misma ficha que ventas.** Atención y comercial sobre la misma cuenta y el mismo contacto. Es la parte que hace que una reclamación bien resuelta se pueda convertir en una conversación comercial. - **Autoservicio, cuando compensa.** Base de conocimiento y portal para lo repetitivo, con un criterio: solo lo que el cliente prefiere resolver solo. Un portal que esconde el teléfono empeora el servicio y el dato. ### Service Cloud, Sales Cloud y el caso que parece oportunidad La confusión habitual no es entre productos: es entre lo que el negocio llama «petición» y lo que llama «venta». Conviene resolverla antes de configurar. - **Un caso se cierra; una oportunidad se gana o se pierde.** Si lo que llega hay que presupuestarlo y puede no comprarse, es una oportunidad de Sales Cloud aunque entre por el buzón de atención. - **Una petición recurrente del mismo cliente no es una oportunidad nueva.** Modelarla como tal infla el pipeline y arruina la previsión. - **El compromiso de respuesta necesita categoría, no urgencia declarada.** Si la prioridad la pone quien abre el caso, en un mes todo es urgente. - **Service Cloud no sustituye al PMS, al ERP ni al sistema de campo.** Consume su dato para dar contexto; si se convierte en su copia, empiezan a divergir. - **El volumen no justifica por sí solo el producto.** Con pocas peticiones muy valiosas, lo que hace falta es histórico y trazabilidad; con muchas y repetitivas, cola y automatización. No es el mismo diseño. ### Proyectos con ficha de caso - Derby Hotels Collection (https://kaizenstep.com/casos-exito/derby-hotels-collection): Atención omnicanal premium, con gestión de peticiones especiales y conserjería - Cadena hotelera urbana española (https://kaizenstep.com/casos-exito/grupo-hotelero-espana): Atención al huésped centralizada, con gestión de incidencias y compromisos de respuesta por categoría ### Preguntas frecuentes **¿Qué diferencia hay entre Sales Cloud y Service Cloud?** Sales Cloud gestiona la venta (cuentas, contactos, oportunidades y previsión) y Service Cloud lo que el cliente pide después: casos, colas, categorías y compromisos de respuesta. Comparten la ficha de cuenta y de contacto, y ahí está buena parte del valor de tener los dos: quien atiende ve el histórico comercial y quien vende ve las reclamaciones abiertas. Se licencian por separado. **¿Se puede medir el cumplimiento de plazos de respuesta en Service Cloud?** Sí, y es una de las razones habituales para implantarlo. Los compromisos de respuesta se definen por categoría de petición y por tipo de cliente, con el reloj dentro de la plataforma, de modo que el cumplimiento deja de ser una impresión y pasa a ser un indicador. Una cadena hotelera urbana de más de cien hoteles lo usa así: pasó de un tercio de incidencias sin resolver en 24 horas a resolver 25 puntos porcentuales más en ese plazo. **¿Hace falta tener Sales Cloud para implantar Service Cloud?** No, Service Cloud funciona por sí solo. Lo que conviene decidir antes es el modelo de cliente, porque es lo que después comparten los dos productos: si la atención se monta con su propia idea de qué es una cuenta y un contacto, unificarla más tarde con la de ventas es un proyecto en sí mismo. En la práctica la mayoría de los proyectos llegan con Sales Cloud ya en marcha. **¿En qué sectores tenéis casos de Service Cloud?** Los dos casos publicados con Service Cloud son de hotelería: Derby Hotels Collection, con atención omnicanal y conserjería en dieciocho hoteles boutique, y una cadena urbana de más de cien hoteles, con atención al huésped centralizada y compromisos de respuesta por categoría. El patrón (cola, categoría, plazo por tipo de petición) es el mismo en industria y en servicios profesionales, que son los otros dos sectores donde trabajamos. --- ## Consultoría de Salesforce Marketing Cloud - URL: https://kaizenstep.com/salesforce/consultoria/marketing-cloud - Producto: Marketing Cloud El sistema que decide a quién se le habla, cuándo y de qué, usando lo que la organización ya sabe de esa persona. Marketing Cloud es la pieza de automatización de marketing: segmentación, journeys y campañas trabajando sobre los datos que ya están en el CRM en lugar de sobre una lista exportada. La diferencia no es la herramienta de envío, es de dónde sale el criterio para decidir a quién se le habla y de qué. Es el producto que más aparece en nuestros proyectos: está en cinco de las seis fichas de caso de este sitio, todas con indicadores medidos por el propio cliente. ### El problema nunca es de envíos Rara vez es un problema de envíos. Es una de estas cuatro, y todas son de dato antes que de campaña. - **La base propia se degrada sin recibir nada.** Hay cientos de miles de contactos conseguidos a lo largo de los años y lo único que salen son campañas genéricas. Cada mes que pasa el dato vale menos y la reputación de envío empeora. - **La segmentación no puede usar lo que importa.** El criterio bueno está en otro sistema (qué compró, dónde estuvo, cuánto gastó, en qué idioma habla) y la herramienta de marketing solo ve nombre y correo. Así no hay segmentación posible. - **El intermediario se queda la relación.** Cuando la venta llega por un tercero, marketing no tiene el contacto del cliente final. Recuperarlo es un trabajo de integración y de proceso, no de creatividad. - **Marketing y ventas no comparten cliente.** La campaña habla con alguien que tiene una reclamación abierta, o se le ofrece lo que acaba de comprar. Pasa siempre que las dos áreas trabajan sobre listas distintas. ### Qué hacemos sobre Marketing Cloud El trabajo se reparte entre preparar el dato y diseñar los journeys, y en ese orden: un journey sobre un dato malo automatiza el error. - **Unificar la ficha antes de automatizar.** Traer al mismo perfil lo que está repartido entre el CRM, el sistema operativo del negocio y los canales de venta. Es la parte que decide si la segmentación va a poder usar algo más que el nombre. - **Segmentar por comportamiento, no por lista.** Mercado de origen, idioma, histórico de compra o de estancia, valor y momento del ciclo. Criterios que se recalculan solos en lugar de listas que alguien mantiene a mano. - **Diseñar los journeys del ciclo completo.** Antes, durante y después: captación, confirmación, preparación, seguimiento y reenganche. Cada mensaje con un motivo y una condición de salida, para que nadie reciba dos cosas que se contradicen. - **Recuperar abandonos y venta cruzada.** El proceso de recuperar lo que se quedó a medias y el de ofrecer lo siguiente en el momento en que tiene sentido, que casi nunca es justo después de comprar. - **Multiidioma y multimarca de verdad.** Un journey que funciona en cinco idiomas no son cinco journeys copiados: es un diseño con el idioma como dato del contacto. Mantener cinco copias garantiza que se desincronicen. - **Medir lo que aporta, no lo que se abre.** Atribución de negocio (reserva, pedido, canal) y no solo aperturas y clics. Es la única medida que permite defender la inversión. ### Cuál de los dos necesitas Salesforce tiene dos productos de automatización de marketing y elegir mal es caro. Account Engagement es el que antes se llamaba Pardot. La decisión no va del tamaño de la empresa: va de cómo se compra lo que vendes. - **Marketing Cloud.** Encaja cuando el volumen es alto, el ciclo corto y la relación es con una persona que compra para sí: hotelería, retail, ocio, servicios al consumidor. Es donde tenemos los cinco casos publicados. - **Account Engagement.** Encaja cuando la venta es B2B, el ciclo largo y hay varias personas decidiendo: industria, canal de prescripción, servicios profesionales. Su fuerte es la puntuación de interés y el traspaso ordenado a ventas. - **La señal más fiable es qué le pides al sistema.** Si le pides que active a mucha gente con el mensaje adecuado, es Marketing Cloud. Si le pides que te diga a quién de una lista corta merece la pena llamar hoy, es Account Engagement. - **Se pueden tener los dos.** , y en grupos con negocio B2C y B2B a la vez es lo razonable. Lo que no funciona es usar uno para el trabajo del otro y concluir que la herramienta es mala. - **.** Nuestros proyectos de Account Engagement son de canal industrial (como el de Abus Grúas, con ingenierías prescriptoras); los cinco casos con indicadores de esta página son de Marketing Cloud, no de Account Engagement. ### Proyectos con ficha de caso - Vincci Hotels (https://kaizenstep.com/casos-exito/vincci-hotels): Journeys automatizados al huésped, campañas de captación y reenganche, y venta cruzada previa a la estancia - Catalonia Hotels & Resorts (https://kaizenstep.com/casos-exito/catalonia-hotels-resorts): Journeys automatizados en cinco idiomas para el ciclo completo de viaje, y campañas de captación de reserva directa segmentadas por mercado de origen, historial y destino - Derby Hotels Collection (https://kaizenstep.com/casos-exito/derby-hotels-collection): Journeys segmentados por tipo de viajero, destino y comportamiento, recuperación de abandonos y fidelización - HTOP Hotels (https://kaizenstep.com/casos-exito/htop-hotels): Journeys posteriores a la estancia y previos a la llegada para el huésped final, recuperando el correo de reservas intermediadas - Cadena hotelera urbana española (https://kaizenstep.com/casos-exito/grupo-hotelero-espana): Journeys automatizados antes, durante y después de la estancia, con campañas segmentadas por comportamiento e historial ### Preguntas frecuentes **¿Qué diferencia hay entre Marketing Cloud y Account Engagement (Pardot)?** Marketing Cloud está pensado para volumen alto y ciclo corto, con la relación centrada en una persona que compra para sí misma: hotelería, retail, ocio o servicios al consumidor. Account Engagement (el producto que antes se llamaba Pardot) está pensado para venta B2B de ciclo largo con varias personas decidiendo, y su fuerte es puntuar el interés y traspasar el contacto a ventas en el momento adecuado. La decisión depende de cómo se compra lo que vendes, no del tamaño de la empresa, y en grupos con negocio B2C y B2B a la vez tiene sentido tener los dos. **¿Hace falta tener el CRM ordenado antes de implantar Marketing Cloud?** Hace falta tener ordenado el dato que va a alimentar la segmentación, que no es lo mismo que tenerlo todo ordenado. Un journey construido sobre un dato malo automatiza el error y lo hace a escala, así que en nuestros proyectos la unificación de la ficha de cliente va antes que el diseño de las campañas. Lo que no hace falta es esperar a que el CRM esté perfecto: se puede empezar por el subconjunto de datos que necesita el primer journey. **¿Se puede hacer marketing con clientes que llegan por un intermediario?** Sí, pero es un trabajo de integración y de proceso antes que de marketing. Cuando la reserva o el pedido llega por un tercero, el contacto del cliente final no viene con él y hay que recuperarlo en algún punto del ciclo. HTOP Hotels lo resolvió así: el 75% de su inventario se vendía por touroperadores europeos y montaron journeys previos a la llegada y posteriores a la estancia recuperando el correo de las reservas intermediadas. **¿Qué resultados habéis medido en proyectos de Marketing Cloud?** Los que publican las fichas de caso, medidos por el propio cliente. Catalonia Hotels & Resorts subió 18 puntos porcentuales las reservas de resort por canal directo, bajó 4,3 puntos la comisión media pagada a intermediarios y multiplicó por 2,4 el revenue atribuible a email en temporada alta, con journeys en cinco idiomas. Derby Hotels Collection recuperó 12 puntos porcentuales de abandonos de reserva. Los cinco casos con Marketing Cloud están enlazados en esta página. Artículo relacionado: [Comprar un CRM: todo lo que debes tener en cuenta](https://kaizenstep.com/blog/comprar-un-crm) --- ## Consultoría de Salesforce Agentforce - URL: https://kaizenstep.com/salesforce/consultoria/agentforce - Producto: Agentforce Agentes que resuelven o preparan trabajo dentro del CRM utilizando la información que ya tienes en Salesforce. Agentforce es la capa de agentes de Salesforce: software que interpreta una petición en lenguaje corriente, decide qué acción procede y la ejecuta o la propone dentro del CRM. Lo que lo diferencia de un asistente es que puede actuar, y por eso la decisión importante no es qué sabe hacer, es hasta dónde le dejas. No lo vendemos como un proyecto aparte. Un agente rinde sobre datos y procesos que ya funcionan, así que en la práctica es una fase de la evolución de un Salesforce en marcha. ### Cuándo tiene sentido plantearse un agente No cuando hay presupuesto para IA. Cuando existe una tarea con estas características, que son las que un agente hace bien. - **Hay una tarea repetitiva con criterio escrito.** Alguien hace muchas veces lo mismo siguiendo reglas que se pueden explicar: clasificar una petición, redactar una propuesta a partir de un formulario, preparar el resumen de una cuenta antes de una visita. - **El cuello de botella es de tiempo, no de decisión.** La respuesta tarda porque nadie ha tenido un hueco para escribirla, no porque haya que decidir algo difícil. Ahí el agente devuelve horas sin asumir ninguna decisión de negocio. - **El dato necesario ya está en el sistema.** Si para responder hay que consultar tres sitios y uno de ellos es una hoja de cálculo en el escritorio de alguien, el problema es de integración y hay que resolverlo antes. - **Hay volumen suficiente para que se note.** Un agente tiene coste de diseño, de prueba y de supervisión. Sobre veinte casos al año no lo recupera; sobre veinte a la semana, sí. ### Qué hacemos sobre Agentforce Casi todo el trabajo es anterior al agente: elegir el caso, preparar el dato y decidir la supervisión. Configurarlo es la parte corta. - **Elegir el primer caso de uso.** Uno, medible y con dueño. La forma más habitual de que un proyecto de agentes no llegue a producción es abrir cinco casos a la vez y no terminar ninguno. - **Revisar el dato que va a leer.** Qué información necesita, dónde vive, quién es su dueño y si está completa. Un agente sobre datos inconsistentes produce respuestas inconsistentes, y con más seguridad de la que merecen. - **Definir el límite de autonomía.** Qué puede hacer solo, qué propone para que una persona lo apruebe y qué no toca. Es la decisión que hay que tomar con el negocio, no con el equipo técnico. - **Escribir las instrucciones y las acciones.** Qué tiene permitido consultar, qué puede escribir en el CRM y con qué tono responde. Aquí es donde se traduce la política de la empresa a algo ejecutable. - **Probar contra casos reales.** Con peticiones que ya han pasado por la organización y respuesta conocida, incluidas las raras. Un agente que acierta en los diez casos fáciles no está probado. - **Medir y supervisar en producción.** Qué porcentaje resuelve solo, qué se corrige, qué se escala y cómo evoluciona. Sin esa medición no hay forma de ampliar el límite con criterio ni de retirarlo si hace falta. ### Lo que hay que decidir antes de encender nada Son de negocio, no de configuración, y ninguna la puede tomar el proveedor por ti. Si te interesa antes la explicación del producto en sí, está en el artículo. - **Hasta dónde llega el agente.** Resolver y ejecutar, o preparar y proponer. La segunda opción es más lenta y es la correcta cuando el error tiene coste para el cliente; empezar ahí y ampliar después es más barato que el camino inverso. - **Quién responde de lo que dice.** Un agente que escribe al cliente habla en nombre de la empresa. Hace falta saber quién revisa, con qué frecuencia y qué pasa cuando se equivoca, antes de que ocurra. - **Qué se hace con lo que no sabe.** El comportamiento por defecto ante una petición fuera de su alcance es la diferencia entre un agente útil y uno que hay que apagar. Escalar bien es un requisito, no una mejora. - **El requisito previo del que poco se habla.** El agente no arregla el CRM. Si el proceso no está modelado o el dato está repartido, lo que se automatiza es el desorden. Por eso en nuestros proyectos Agentforce llega después de la auditoría, no antes. ### Proyectos con ficha de caso - Cadena hotelera urbana española (https://kaizenstep.com/casos-exito/grupo-hotelero-espana): Agente de IA que genera las propuestas de grupos y eventos a partir de la petición recibida ### Preguntas frecuentes **¿Qué es Agentforce y en qué se diferencia de un chatbot?** Agentforce es la capa de agentes de Salesforce: software que interpreta una petición escrita en lenguaje corriente, decide qué acción procede y la ejecuta o la propone dentro del CRM. La diferencia con un chatbot clásico es que no sigue un árbol de respuestas predefinido y que puede actuar sobre los datos (crear un registro, redactar una propuesta, actualizar un caso) en lugar de solo contestar. Por eso la decisión de diseño más importante es hasta dónde se le deja actuar solo. **¿Qué hace falta tener antes de implantar Agentforce?** Un proceso modelado y el dato que el agente va a leer en su sitio. Agentforce no arregla un CRM desordenado: si la información que necesita está repartida entre tres sistemas y una hoja de cálculo, lo que se automatiza es el desorden. En nuestros proyectos Agentforce llega después de una auditoría de la instalación, y el primer caso de uso se elige entre las tareas cuyo dato ya está completo dentro de Salesforce. **¿Tenéis algún caso de Agentforce en producción?** Sí, uno publicado: una cadena hotelera urbana española de más de cien hoteles, donde un agente genera las propuestas de grupos y eventos a partir de la petición recibida. El tiempo de respuesta a solicitudes de grupos pasó de 72 a 23 horas (un 68% menos) y la conversión de petición a reserva subió del 18% al 22%. La propuesta la revisa una persona antes de salir: es un caso de preparar y proponer, no de resolver y ejecutar. **¿Por dónde se empieza con Agentforce?** Por un solo caso de uso, medible y con dueño. La forma más habitual de que un proyecto de agentes no llegue a producción es abrir cinco a la vez y no terminar ninguno. El buen primer candidato es una tarea repetitiva con criterio escrito, cuello de botella de tiempo y no de decisión, dato ya disponible en el sistema y volumen suficiente para que el ahorro compense el coste de diseño y supervisión. Artículo relacionado: [Agentforce explicado: la inteligencia artificial dentro de Salesforce](https://kaizenstep.com/blog/agentforce-explicado) --- ## Consultoría de Salesforce Data Cloud - URL: https://kaizenstep.com/salesforce/consultoria/data-cloud - Producto: Data Cloud La capa que decide qué registros son la misma persona y qué dato manda cuando dos sistemas se contradicen. Data Cloud es la pieza que reúne en un solo perfil lo que una organización sabe de un cliente y tiene repartido entre sistemas: el operativo, la web, el correo, el canal de venta y el propio CRM. No es un almacén más: es la capa que decide qué registros son la misma persona y qué dato manda cuando dos sistemas dicen cosas distintas. Es la pieza que menos se pide por su nombre y la que más aparece en nuestros proyectos: está en cinco de las seis fichas de caso de este sitio, siempre por el mismo motivo. ### Cómo se llega hasta aquí Nadie llama pidiendo unificar perfiles. Llama con una de estas cuatro, y todas terminan aquí. - **El mismo cliente existe cinco veces.** Está en el sistema operativo con un nombre, en el CRM con otro y en la herramienta de marketing con un correo distinto. Nadie sabe cuántos clientes hay de verdad, así que ningún recuento se sostiene. - **La segmentación solo puede usar nombre y correo.** El criterio bueno (qué compró, cuánto gastó, dónde estuvo, en qué idioma habla) vive en otro sistema. Mientras no llegue al mismo perfil, la segmentación es demográfica y da lo que da. - **Cada área ve una parte del cliente.** Marketing ve las campañas, atención ve las incidencias y el equipo comercial ve los pedidos. Ninguno ve al cliente completo, y por eso las tres áreas le hablan como si fuera tres personas. - **Se quiere poner IA encima de todo esto.** Es la conversación más habitual del último año. Un agente o un modelo predictivo sobre datos contradictorios produce respuestas contradictorias, y con más aplomo del que merecen. ### Qué hacemos sobre Data Cloud Casi todo el trabajo es de criterio y no de configuración: quién es la misma persona, qué campo gana y qué se hace con lo que no encaja. - **Inventariar dónde vive el cliente.** Qué sistemas guardan datos de la misma persona, con qué identificador y con qué calidad. Es la parte que suele destapar dos o tres fuentes que nadie recordaba. - **Decidir el criterio de identidad.** Qué combinación de datos convierte dos registros en la misma persona. Es una decisión de negocio con consecuencias: un criterio laxo fusiona clientes distintos y uno estricto deja duplicados. - **Resolver los conflictos campo a campo.** Cuando dos sistemas dan un teléfono distinto, cuál gana y por qué. Se decide antes de construir, porque después cada excepción se convierte en una regla escondida. - **Construir los atributos que se van a usar.** Valor acumulado, recurrencia, última interacción, categoría preferida. Calculados una vez en el perfil en lugar de recalculados en cada herramienta con criterios que divergen. - **Poner el perfil donde hace falta.** Disponible para marketing, para atención y para el equipo comercial en la misma ficha que ya usan, no en una consola aparte a la que nadie entra. - **Gobierno y consentimiento.** Qué dato se puede usar para qué, con el consentimiento asociado al perfil unificado y no a cada sistema por separado. Es un requisito legal y también lo que evita el uso que molesta al cliente. ### Data Cloud no es un almacén de datos, y no siempre hace falta Es la pieza que más se confunde con otras y también la que más se compra antes de tiempo. Dos motivos para decirlo claro. - **No sustituye al almacén analítico.** Si la pregunta es «cuánto vendimos por región el trimestre pasado», eso es un almacén y un informe. Data Cloud existe para actuar sobre una persona concreta, no para agregar. - **No sustituye a la integración.** Mover el dato entre sistemas y mantenerlo sincronizado sigue siendo trabajo de integración; Data Cloud consume lo que llega. Las dos piezas se complementan y ninguna hace el trabajo de la otra. - **No es el maestro de nada.** El sistema operativo sigue siendo el dueño de su dato. Data Cloud unifica la vista, no arrebata la propiedad, y confundirlo crea un tercer sitio donde el dato divergir. - **Con una sola fuente fiable, no hace falta.** Si el cliente existe en un único sistema y ese sistema es correcto, unificar no resuelve nada. La pieza se justifica cuando hay varias fuentes que se contradicen. - **Es el requisito previo de casi todo lo demás.** La automatización de marketing y los agentes de IA rinden en proporción a lo bueno que sea el perfil que leen. Por eso en nuestros proyectos suele ir antes, no después. ### Proyectos con ficha de caso - Vincci Hotels (https://kaizenstep.com/casos-exito/vincci-hotels): Unificación del perfil de huésped desde el PMS, la web y el CRM, y segmentación predictiva - Catalonia Hotels & Resorts (https://kaizenstep.com/casos-exito/catalonia-hotels-resorts): Perfil unificado de huésped consolidando PMS, motor de reservas, email y web, con segmentación en tiempo real - Derby Hotels Collection (https://kaizenstep.com/casos-exito/derby-hotels-collection): Perfil unificado del huésped agregando PMS, web, email y preferencias declaradas - HTOP Hotels (https://kaizenstep.com/casos-exito/htop-hotels): Perfil unificado del huésped agregando datos del PMS, la web y el comportamiento de email - Cadena hotelera urbana española (https://kaizenstep.com/casos-exito/grupo-hotelero-espana): Perfil unificado del huésped accesible por marketing, atención y los propios hoteles ### Preguntas frecuentes **¿Qué es Salesforce Data Cloud y para qué sirve?** Data Cloud es la capa de Salesforce que reúne en un solo perfil los datos de un mismo cliente repartidos entre varios sistemas (el operativo del negocio, la web, el correo, el canal de venta y el CRM) y resuelve dos cosas que ningún sistema por separado puede resolver: qué registros son la misma persona y qué dato manda cuando dos fuentes se contradicen. Sirve para que la segmentación, la atención y los agentes de IA trabajen sobre una versión única del cliente en lugar de sobre su propia copia parcial. **¿Qué diferencia hay entre Data Cloud y un almacén de datos?** Un almacén de datos está pensado para agregar y responder preguntas de conjunto: cuánto se vendió, por qué región, en qué periodo. Data Cloud está pensado para actuar sobre una persona concreta en el momento en que interactúa: reconocerla, saber qué ha hecho antes y decidir qué corresponde ahora. Se pueden tener los dos y es lo habitual en organizaciones grandes; lo que no funciona es pedirle a uno el trabajo del otro. **¿Hace falta Data Cloud para usar Agentforce o Marketing Cloud?** No es un requisito técnico, pero sí determina el resultado. Tanto un agente de IA como un journey de marketing rinden en proporción a lo bueno que sea el perfil que leen: sobre datos contradictorios producen respuestas contradictorias. Cuando el cliente existe en una sola fuente fiable no hace falta unificar nada; cuando existe en cuatro sistemas que no se hablan, unificar antes sale más barato que corregir después. **¿En qué proyectos habéis usado Data Cloud?** En cinco de los seis casos publicados en este sitio, siempre para lo mismo: construir el perfil unificado del huésped a partir del sistema de gestión hotelera, la web, el correo y el CRM. Vincci Hotels lo usa con segmentación predictiva; Catalonia Hotels & Resorts consolidando además el motor de reservas, con segmentación en tiempo real; y una cadena urbana de más de cien hoteles lo hace accesible a marketing, atención y los propios hoteles. --- ## Consultoría de MuleSoft para Salesforce - URL: https://kaizenstep.com/salesforce/consultoria/mulesoft - Producto: MuleSoft La capa que mueve el dato entre Salesforce y el resto de sistemas, con un contrato explícito en cada dirección. MuleSoft es la capa de integración de Salesforce: la que conecta el CRM con el ERP, con el sistema operativo del negocio y con los canales por los que entra la venta, en las dos direcciones y con un contrato explícito de qué se envía, cuándo y qué pasa si falla. No la vendemos como proyecto propio. Aparece cuando el problema de negocio es que hay un dato que alguien está copiando a mano entre dos sistemas, y en nuestros casos siempre ha sido eso. ### El coste que ya estáis pagando en horas Nunca es «queremos MuleSoft». Es una de estas cuatro, y las cuatro se pagan en horas de alguien. - **Alguien copia datos a mano todos los días.** Un pedido que se teclea dos veces, una tarifa que se actualiza en dos sitios, un listado que se exporta y se vuelve a importar. Es trabajo invisible en el presupuesto y muy visible en los errores. - **El comercial no se fía del CRM.** Porque el dato bueno está en el ERP y lo sabe. Mientras la información que necesita para trabajar viva en otra pantalla, el CRM será el sitio donde se apunta después. - **Las dos partes creen que mandan.** El CRM y el sistema operativo escriben sobre el mismo campo sin que nadie haya decidido quién gana. El resultado son dos verdades que se sobreescriben por turnos. - **La integración existe y nadie sabe qué hace.** Un proceso que alguien montó hace años, sin documentar, que a veces falla en silencio. Nadie se atreve a tocarlo y nadie puede explicar de qué depende. ### Qué hacemos sobre MuleSoft El trabajo está en las cuatro decisiones previas. Construir el flujo es la parte que menos discute. - **Decidir el dueño de cada dato.** Campo a campo, antes de construir. En la práctica el ERP suele gobernar el cliente facturable, el producto y el precio, y el CRM la relación comercial; pero eso se acuerda, no se hereda. - **Definir dirección y latencia.** Qué viaja en cada sentido y con qué urgencia. No todo necesita tiempo real, y pedirlo donde no hace falta multiplica el coste y los puntos de fallo. - **Decidir qué pasa cuando falla.** Si se reintenta, si se encola, si alguien se entera y quién. Es la decisión que más se salta y la que determina si la integración se puede dejar sin vigilar. - **Construir el flujo bidireccional.** Con transformación de datos explícita y un contrato en cada extremo, para que un cambio en un sistema no rompa el otro sin avisar. - **Reutilizar en lugar de duplicar.** Una interfaz por dato y no una por proyecto. Es la diferencia entre una capa de integración y una colección de conexiones punto a punto que crece hasta que nadie la entiende. - **Documentar y monitorizar.** Qué existe, qué mueve y cómo se comprueba que sigue funcionando. Sin esto, en dos años la integración es la caja negra del punto anterior. ### Cuándo no hace falta MuleSoft Es una herramienta con coste de licencia y de mantenimiento, así que conviene ser honesto sobre cuándo no compensa. Estos son los casos. - **Cuando hay un conector estándar que ya lo hace.** Muchas integraciones habituales están resueltas de serie o con un producto de terceros más barato. Montar una capa de integración para eso es pagar dos veces. - **Cuando es una sola conexión y no va a crecer.** El valor de MuleSoft está en reutilizar interfaces entre varios consumidores; con una integración aislada, una solución más simple suele ser la correcta. - **Cuando el problema es de proceso, no de datos.** Si el dato llega tarde porque nadie lo introduce, automatizar el traslado no cambia nada. Eso es trabajo de adopción. - **Cuando no hay quién lo mantenga.** Una capa de integración es infraestructura y necesita dueño. Sin eso se convierte en la caja negra que nadie se atreve a tocar, que es justo el problema del que veníamos. - **Lo que sí es siempre necesario es la decisión previa.** Quién manda sobre cada dato. Esa conversación hay que tenerla con MuleSoft y sin él, y es la que evita que dos sistemas cuenten cosas distintas. La desarrolla la [página de integraciones](/salesforce/integraciones). ### Proyectos con ficha de caso - Vincci Hotels (https://kaizenstep.com/casos-exito/vincci-hotels): Integración bidireccional con el PMS Protel y con el motor de reservas Siteminder - Catalonia Hotels & Resorts (https://kaizenstep.com/casos-exito/catalonia-hotels-resorts): Integración bidireccional con SAP para sincronizar datos de estancia, entradas y salidas, y preferencias registradas en el hotel - HTOP Hotels (https://kaizenstep.com/casos-exito/htop-hotels): Integración bidireccional con el PMS y con las extranets de los touroperadores para actualizar cupos y tarifas ### Preguntas frecuentes **¿Qué es MuleSoft y qué relación tiene con Salesforce?** MuleSoft es la plataforma de integración de Salesforce, que la adquirió en 2018. Se usa para conectar Salesforce con el resto de los sistemas donde vive la información del negocio (el ERP, el sistema operativo, el ecommerce, la facturación) en las dos direcciones, con transformación de datos explícita y un contrato en cada extremo. Es infraestructura: no la usa nadie directamente, se nota en que el dato está donde tiene que estar sin que nadie lo copie. **¿Hace falta MuleSoft para integrar Salesforce con nuestro ERP?** No siempre, y conviene comprobarlo antes de licenciarlo. Muchas integraciones habituales están resueltas con conectores estándar o con herramientas de terceros más baratas, y con una sola conexión que no va a crecer casi siempre hay una opción más simple. MuleSoft compensa cuando hay varias integraciones que comparten datos, cuando hace falta reutilizar la misma interfaz para varios consumidores o cuando el gobierno y la monitorización del conjunto importan tanto como cada conexión. **¿Qué se decide antes de construir una integración?** Cuatro cosas, y en este orden: quién es el dueño de cada dato campo a campo, en qué dirección viaja y con qué latencia, qué ocurre cuando falla (si se reintenta, si se encola, quién se entera) y quién va a mantenerla. La tercera es la que más se salta y la que determina si la integración se puede dejar sin vigilar. Ninguna de las cuatro es técnica: son decisiones de negocio con consecuencias técnicas. **¿En qué proyectos habéis usado MuleSoft?** En tres de los casos publicados, siempre con integración bidireccional. Catalonia Hotels & Resorts lo usa con SAP, para sincronizar datos de estancia, entradas y salidas y preferencias registradas en el hotel. HTOP Hotels lo usa con su sistema de gestión hotelera y con las extranets de los touroperadores, para actualizar cupos y tarifas. Vincci Hotels lo usa con el PMS Protel y con el motor de reservas Siteminder. --- ## Consultoría de Salesforce Commerce Cloud - URL: https://kaizenstep.com/salesforce/consultoria/commerce-cloud - Producto: Commerce Cloud La tienda como parte del CRM: quien compra online es la misma persona que ya existe en el sistema. Commerce Cloud es la plataforma de comercio de Salesforce: catálogo, escaparate, carrito, pago y pedido, para venta a consumidor final y para venta entre empresas. Lo que la distingue de una tienda cualquiera no es el escaparate: es que la persona que compra es la misma que ya existe en el CRM, con su histórico de atención y de relación comercial. La trabajamos cuando el problema es que la tienda y el resto de la empresa cuentan clientes distintos, no cuando lo que hace falta es una tienda. ### Ninguno es un problema de escaparate Ninguno de los cuatro es un problema de escaparate. Los cuatro son de frontera entre sistemas. - **La tienda no sabe quién está comprando.** El cliente lleva años comprando en tienda física o por comercial, y online entra como si fuera nuevo. Ni el precio, ni las condiciones, ni las recomendaciones tienen en cuenta nada de lo anterior. - **El catálogo vive en dos sitios.** Producto, atributos, imágenes y precio se mantienen en el ERP y otra vez en la tienda. Cada cambio se hace dos veces, y en cuanto uno se olvida los dos divergen. - **El pedido B2B se sigue haciendo por correo.** El distribuidor manda un Excel o llama al comercial, y alguien lo teclea. Es el caso donde una tienda B2B con su tarifa y su histórico de pedidos devuelve más horas que cualquier campaña. - **Marketing y tienda no comparten cliente.** La campaña ofrece lo que el cliente compró ayer, o le habla de un producto que no está disponible en su mercado. Pasa siempre que la tienda tiene su propia base de contactos. ### Todo empieza por decidir fronteras Casi todo es decidir fronteras: qué sistema gobierna el catálogo, el precio, el stock y el pedido. El escaparate viene después. - **Decidir el dueño del catálogo y del precio.** Normalmente el ERP o un gestor de producto dedicado, con la tienda consumiendo. Duplicar el maestro aquí es la causa de la mitad de las incidencias de una tienda en producción. - **Unificar la identidad del comprador.** Que quien compra online sea la misma cuenta y el mismo contacto que existe en el CRM, con su histórico de atención y de compra en cualquier canal. - **Modelar la venta B2B.** Tarifa por cliente, condiciones, pedido recurrente y reposición rápida, que es lo que un distribuidor pide de verdad. Es un escenario distinto del consumo, no una variante del mismo. - **Llevar el pedido hasta el ERP.** Sin que nadie lo copie, con el estado devuelto al cliente y con un comportamiento definido cuando falla. Es la integración que decide si la tienda ahorra trabajo o lo crea. - **Conectar tienda, atención y marketing.** Que atención vea el pedido y marketing vea la compra, sobre la misma ficha. Sin eso la tienda es un silo más, con el agravante de que es el que factura. - **Mercado, idioma y divisa.** Qué se vende dónde, a qué precio y con qué texto. Se modela desde el principio: reconvertir una tienda de un solo mercado en una internacional cuesta más que plantearla así. ### Cuándo Commerce Cloud no es la respuesta Es la pieza más cara del catálogo de Salesforce y la que menos veces es la opción correcta. Preferimos decirlo antes que después. - **Si lo que hace falta es una tienda, hay opciones mejores.** Para catálogo sencillo, un mercado y venta a consumidor, una plataforma de comercio convencional cuesta una fracción y se pone en marcha antes. - **Commerce Cloud se justifica por la conexión, no por el escaparate.** Compensa cuando el valor está en que la tienda comparta cliente, precio y servicio con el resto de la plataforma, y cuando esa unificación es la que se está comprando. - **No es el maestro de producto.** Si el catálogo es complejo, el dueño suele ser el ERP o un gestor de producto dedicado. La tienda lo consume; al contrario acaban divergiendo. - **No sustituye al ERP en el pedido.** El pedido se cierra en la tienda y se cumple en el ERP. Quien intenta gestionar la logística desde la tienda acaba reconstruyendo medio ERP. - **Si la venta es por canal, primero está el canal.** Cuando la mayoría del negocio pasa por distribuidores y prescriptores, lo que devuelve tiempo antes es hacer visible ese canal en el CRM. Eso lo desarrolla la [página de Sales Cloud](/salesforce/consultoria/sales-cloud). ### Otros proyectos con esta pieza En producción, citados por nombre de cliente: Lladró. Los indicadores medidos por cliente están en las fichas de /casos-exito. ### Preguntas frecuentes **¿Qué es Salesforce Commerce Cloud?** Commerce Cloud es la plataforma de comercio electrónico de Salesforce: catálogo, escaparate, carrito, pago y pedido, tanto para venta a consumidor final como para venta entre empresas. Su diferencia con una plataforma de comercio convencional no está en la tienda sino en que el comprador es la misma cuenta y el mismo contacto que ya existe en el CRM, con su histórico de atención y de relación comercial disponible para el precio, las condiciones y la recomendación. **¿Cuándo compensa Commerce Cloud frente a otra plataforma de ecommerce?** Compensa cuando lo que se está comprando es la unificación y no el escaparate: que la tienda comparta cliente, precio y servicio con el resto de la plataforma. Si el catálogo es sencillo, hay un solo mercado y la venta es a consumidor final, una plataforma de comercio convencional cuesta una fracción y se pone en marcha antes. Es la pieza más cara del catálogo de Salesforce, así que la pregunta correcta es qué parte del valor viene de estar dentro de la plataforma. **¿Sirve Commerce Cloud para venta B2B a distribuidores?** Sí, y es uno de los usos donde más se nota, pero hay que modelarlo como escenario propio y no como una variante del consumo. Un distribuidor necesita su tarifa, sus condiciones, el pedido recurrente y la reposición rápida sobre su histórico. Cuando hoy ese pedido llega por correo o por teléfono y alguien lo teclea, una tienda B2B devuelve más horas que cualquier campaña de captación. **¿Qué se decide antes de montar una tienda con Commerce Cloud?** Cuatro fronteras, y todas antes de construir: qué sistema gobierna el catálogo y el precio (normalmente el ERP o un gestor de producto dedicado, con la tienda consumiendo), cómo se identifica al comprador para que sea la misma persona que existe en el CRM, cómo llega el pedido al ERP y qué pasa cuando esa integración falla, y en qué mercados, idiomas y divisas se vende. Duplicar el maestro de producto es la causa de la mitad de las incidencias de una tienda en producción. --- ## Consultoría de Tableau con Salesforce - URL: https://kaizenstep.com/salesforce/consultoria/tableau - Producto: Tableau La capa que responde preguntas de dirección cruzando el CRM con los datos que viven fuera de él. Tableau es la pieza de analítica de Salesforce, que la adquirió en 2019. Sirve para responder preguntas de dirección cruzando datos del CRM con datos que están fuera de él (el ERP, el sistema operativo, la contabilidad, la web) en cuadros de mando que se exploran, no en informes que se leen. El trabajo que hacemos aquí es menos técnico de lo que parece: la mayor parte se va en acordar qué significa cada cifra antes de dibujarla. ### Cuando el dato no sirve para decidir Casi siempre es uno de estos cuatro, y ninguno se arregla con una herramienta mejor. - **Dos informes dan cifras distintas.** Ventas dice una cosa y finanzas otra, y las dos tienen razón porque cada uno cuenta un momento distinto del pedido. Mientras la definición no esté acordada, la reunión se dedica a discutir el dato en lugar de decidir. - **La pregunta cruza sistemas.** Margen real por cliente, coste de captación, rentabilidad por producto o por canal. Ninguna se responde solo con el CRM, y por eso no existe informe que la conteste. - **Cada área tiene su hoja de cálculo.** Alguien la actualiza a mano cada mes, con su propia lógica y su propio criterio. Funciona hasta que esa persona se va o el negocio crece, y entonces no hay forma de reconstruir de dónde salían los números. - **El cuadro de mando existe y nadie lo abre.** El síntoma más habitual. Se construyó respondiendo a lo que era fácil medir en lugar de a lo que alguien tiene que decidir, así que no cambia ninguna conversación. ### Qué hacemos sobre Tableau Empezamos por la decisión que hay que tomar y vamos hacia atrás hasta el dato. Nunca al revés. - **Partir de la pregunta, no del dato.** Qué decisión se toma con esto, quién la toma y cada cuánto. Un cuadro de mando que no cambia ninguna decisión es trabajo perdido aunque esté bien construido. - **Acordar la definición de cada métrica.** Qué cuenta como venta, en qué momento, con qué signo y qué se excluye. Escrito y firmado por quien lo va a usar, porque es lo que evita las dos cifras distintas. - **Localizar y preparar la fuente.** De dónde sale cada dato, con qué frecuencia se refresca y qué calidad tiene. Aquí es donde aparece que la mitad de lo que se quería medir no se está registrando. - **Diseñar para leer, no para lucir.** Una pregunta por vista, jerarquía clara y la comparación que da sentido a la cifra. Un panel con veinte gráficos no se mira; uno con tres se mira todas las semanas. - **Ponerlo donde se trabaja.** Embebido en Salesforce cuando la decisión se toma sobre un registro, y en su propio sitio cuando es una revisión periódica. La herramienta que hay que abrir aparte se abre menos. - **Decidir quién lo mantiene.** Un cuadro de mando es un producto vivo: cambian las preguntas y cambian las fuentes. Sin dueño acaba siendo la siguiente hoja de cálculo que nadie se cree. ### Por qué no basta con los informes de Salesforce, y cuándo sí bastan Es la pregunta que se hace todo el mundo antes de plantearse Tableau, y la respuesta honesta es que muchas veces los informes nativos son suficientes. - **Si la pregunta se responde con datos que están en Salesforce, usa los informes de Salesforce.** Son gratis, los mantiene el equipo y se integran con la ficha. Comprar analítica para eso es pagar por algo que ya tienes. - **Tableau empieza a compensar cuando la pregunta cruza sistemas.** Margen real, coste de captación, rentabilidad por canal: eso necesita datos del ERP o de la contabilidad, y ahí el informe nativo se queda corto. - **También cuando lo que hace falta es explorar y no consultar.** Un informe responde una pregunta fija; un cuadro de mando permite preguntar la siguiente. Si nadie va a preguntar la siguiente, el informe basta. - **No es la solución a un dato malo.** Una herramienta de analítica hace más visible la inconsistencia, no la arregla. Si el problema es que el dato no se registra o que dos sistemas se contradicen, eso es trabajo de proceso y de unificación. - **No sustituye la conversación de definición.** La misma cifra calculada de dos maneras seguirá dando dos resultados en Tableau. Esa conversación es la mitad del proyecto y no la resuelve ninguna licencia. ### Otros proyectos con esta pieza En producción, citados por nombre de cliente: Diari de Tarragona, Honext. Los indicadores medidos por cliente están en las fichas de /casos-exito. ### Preguntas frecuentes **¿Qué es Tableau y qué relación tiene con Salesforce?** Tableau es la plataforma de analítica y visualización de datos de Salesforce, que la adquirió en 2019 por 15.700 millones de dólares. Se usa para responder preguntas de dirección cruzando datos del CRM con datos que viven fuera de él (el ERP, la contabilidad, el sistema operativo, la web) en cuadros de mando que se exploran en lugar de informes fijos. Se puede consumir de forma independiente o embebida dentro de Salesforce, junto al registro sobre el que se decide. **¿Por qué no bastan los informes nativos de Salesforce?** Muchas veces bastan, y conviene comprobarlo antes de licenciar nada: si la pregunta se responde con datos que ya están en Salesforce, los informes nativos son gratuitos, los mantiene el propio equipo y viven junto a la ficha. Tableau compensa cuando la pregunta cruza sistemas (margen real por cliente, coste de captación, rentabilidad por canal) o cuando lo que hace falta es explorar y preguntar la siguiente cosa, no consultar una cifra fija. **¿Por qué dos informes de la misma empresa dan cifras distintas?** Casi siempre porque cada uno cuenta un momento distinto del mismo proceso (el pedido confirmado, el facturado, el cobrado) y ninguna de las dos definiciones está mal. El problema no es la herramienta: es que la definición no está acordada por escrito. Por eso en nuestros proyectos la definición de cada métrica (qué cuenta, en qué momento, con qué signo, qué se excluye) se acuerda y se firma antes de construir el primer cuadro de mando. **¿Sirve Tableau si nuestros datos están desordenados?** Sirve para verlo, no para arreglarlo. Una herramienta de analítica hace más visible la inconsistencia y eso ya tiene valor como diagnóstico, pero si el problema de fondo es que el dato no se registra o que dos sistemas se contradicen, la solución es de proceso y de unificación, no de visualización. En ese caso el orden que recomendamos es auditar primero, unificar después y medir al final. --- ## Artículos --- ### Claudeforce: qué es y qué puede cambiar para Ventas, Marketing y Atención al Cliente - URL: https://kaizenstep.com/blog/que-es-claudeforce-salesforce-anthropic - Materia: Evolución de la plataforma - Publicado: 2026-09-08 Claudeforce es la alianza entre Salesforce y Anthropic para conectar el razonamiento de Claude con los datos, procesos, permisos y acciones de Salesforce. Su primer producto es Salesforce in Claude, que empieza por Ventas y permite trabajar con contexto del CRM y ejecutar determinadas acciones sin salir de Claude. No todo lo anunciado está disponible todavía: la primera fase está centrada en Ventas y las capacidades que Salesforce ha mostrado para Marketing y Service siguen anunciadas como próximas. Un Director Comercial quiere saber qué oportunidades necesitan atención esta semana. Hoy puede tener que abrir el pipeline, revisar varias operaciones, buscar conversaciones anteriores y reconstruir el contexto antes de decidir dónde actuar. **Claudeforce apunta a que una parte de ese trabajo pueda empezar desde una conversación con Claude utilizando el contexto de Salesforce.** Antes de entrar en qué significa eso para tu equipo, conviene separar lo que ya existe de lo que Salesforce ha anunciado para más adelante. #### ¿Qué es exactamente Claudeforce? Claudeforce no es un nuevo CRM. Tampoco es una aplicación llamada Claudeforce que sustituya a Salesforce, a Claude o a Agentforce. Es el nombre que Salesforce y Anthropic han dado a la ampliación de su alianza, [anunciada el 26 de agosto de 2026](https://www.salesforce.com/news/press-releases/2026/08/26/salesforce-and-anthropic-announce-claudeforce/). La idea es conectar dos piezas diferentes. Por un lado está Claude, que aporta capacidades de razonamiento e interacción con IA. Por otro está Salesforce, donde una empresa puede tener sus cuentas, oportunidades, casos, procesos, permisos y reglas de negocio. La combinación busca que Claude no se limite a responder una pregunta genérica. **Puede trabajar sobre el contexto empresarial al que el usuario tiene acceso y, en determinados escenarios, ejecutar acciones a través de Salesforce.** El primer producto de esta alianza se llama **Salesforce in Claude**. #### ¿Qué es Salesforce in Claude? Salesforce in Claude es un plugin que permite trabajar desde Claude con información y procesos de Salesforce. Salesforce ha presentado la primera versión alrededor del trabajo de los equipos comerciales, con **37 skills preconfiguradas orientadas a Ventas**. Entre los casos de uso que Salesforce está mostrando aparecen tareas como: - Preparar una reunión. - Revisar el pipeline. - Analizar el estado de una oportunidad. - Identificar qué necesita atención. - Actualizar información del pipeline. - Registrar actividad. La diferencia importante no está en poder escribir: > Resume esta oportunidad. Eso ya sería posible con muchas herramientas de IA si les proporcionas el contenido. La diferencia aparece cuando la IA puede trabajar con **el contexto que ya existe en Salesforce y las reglas bajo las que trabaja la empresa**. ##### Un ejemplo: preparar una reunión comercial Piensa en una cuenta importante. Antes de hablar con el cliente, el comercial necesita saber: - Qué oportunidades están abiertas. - Qué ocurrió en las últimas conversaciones. - Qué compromisos existen. - Qué ha cambiado. - Qué personas participan. - Cuál debería ser el siguiente paso. El trabajo no consiste solamente en encontrar datos. Consiste en leerlos, relacionarlos y decidir qué importa. La propuesta de Salesforce in Claude es que el usuario pueda pedir ese contexto directamente desde Claude. > ¿Qué necesito saber antes de mi reunión con esta cuenta? > ¿Qué ha cambiado en esta oportunidad desde la última reunión? La IA puede entonces trabajar sobre la información para la que ese usuario tiene permisos. Esto reduce una fricción bastante habitual: **tener la información en Salesforce no significa que sea rápido convertirla en contexto útil para tomar una decisión.** #### ¿Qué puede cambiar para un Director Comercial? Ventas es el área donde el anuncio es más concreto. Salesforce ha empezado precisamente por el ciclo comercial. Y tiene sentido. Un Director Comercial no suele necesitar más información. Necesita entender mejor la que ya tiene. ##### Saber qué necesita atención Un pipeline puede contener cientos de oportunidades. Un dashboard ayuda a ordenarlas. Pero el manager sigue teniendo que interpretar: - Qué ha cambiado. - Qué operaciones llevan demasiado tiempo paradas. - Qué oportunidades tienen señales contradictorias. - Dónde faltan próximos pasos. - Qué debería revisarse con cada comercial. Una IA capaz de razonar sobre ese contexto puede cambiar la interacción. En lugar de navegar primero por los datos para encontrar la pregunta, puedes empezar por la pregunta: > ¿Qué oportunidades debería revisar hoy con el equipo? Eso no convierte la respuesta en una verdad automática. Pero puede reducir el trabajo necesario para llegar a las situaciones que necesitan atención. ##### Preparar reuniones de pipeline Muchas reuniones comerciales empiezan reconstruyendo información. ¿Qué pasó con esta oportunidad? ¿Ha hablado alguien con el cliente? ¿Por qué sigue cerrando este mes? ¿Cuál es realmente el siguiente paso? Si ese contexto está correctamente registrado, una interacción con IA puede ayudar a preparar la conversación antes de entrar en la reunión. Entonces el tiempo puede dedicarse más a decidir qué hacer y menos a reconstruir qué ha pasado. ##### Mantener Salesforce actualizado Aquí aparece otro punto interesante. En muchas organizaciones, el comercial hace el trabajo y después tiene que documentarlo. La reunión sucede. El correo se envía. La llamada termina. Y Salesforce queda pendiente de actualizar. Si determinadas acciones pueden ejecutarse desde el mismo flujo donde el usuario está trabajando con Claude, parte de esa fricción podría reducirse. Para un Director Comercial esto conecta directamente con un problema conocido: **un forecast no puede ser más fiable que las oportunidades sobre las que se construye.** Si los datos llegan tarde, el forecast llega tarde. #### ¿Significa que Claude puede hacer cualquier cosa dentro de Salesforce? No. Este punto es más importante que muchas de las demos. Salesforce indica que Salesforce in Claude utiliza los permisos y las reglas de negocio que ya existen en Salesforce. Eso significa que Claude no debería tener acceso libre a toda la organización simplemente por estar conectado. El contexto y las acciones dependen de aquello para lo que el usuario está autorizado. Salesforce también plantea controles sobre las acciones de escritura. > **Consultar y actuar no tienen el mismo riesgo.** Consultar una oportunidad no es lo mismo que modificar un importe, cambiar una fase, actualizar datos, enviar una comunicación o ejecutar un workflow. Cuanta más capacidad tenga la IA para actuar, más importante resulta decidir qué puede hacer, con qué información y bajo qué condiciones. #### Los datos siguen importando. Quizá más que antes Conectar una IA potente con Salesforce no arregla unos datos deficientes. Puede hacer que el problema sea más visible. Imagina que preguntas: > ¿Qué oportunidades están en riesgo este trimestre? La respuesta dependerá del contexto disponible. Si hay oportunidades que no se actualizan desde hace semanas —porque [el trabajo real sigue ocurriendo en una hoja de cálculo](/blog/excel-paralelo-salesforce), por ejemplo—, Claude no conoce mágicamente lo que el comercial todavía no ha registrado. Si cada persona interpreta las fases de venta de forma diferente, la IA recibe esa inconsistencia. Si las fechas de cierre se mantienen por inercia, el dato continúa siendo poco fiable. Y si el proceso comercial real ocurre en correo, en el ERP o en conversaciones privadas, Salesforce solo contiene una parte de la historia: ahí la conversación no es de IA, es de [integrar Salesforce con los sistemas donde está el resto del contexto](/salesforce/integraciones). **La calidad del razonamiento depende también de la calidad del contexto empresarial que ponemos detrás.** Por eso la llegada de este tipo de herramientas no reduce la importancia de tener un Salesforce bien planteado. La aumenta. #### ¿Qué puede cambiar para Marketing? Aquí hay que distinguir entre **dirección del producto** y **capacidad disponible**. Salesforce ha anunciado que Salesforce in Claude se ampliará a otros equipos y presenta Marketing entre los siguientes ámbitos. A fecha de este artículo, las capacidades específicas de Marketing aparecen todavía como **coming soon**. Por tanto, no deberíamos presentarlas como algo que un Director de Marketing pueda activar hoy. Lo interesante es entender hacia dónde apunta el modelo. Un Director de Marketing puede utilizar IA generativa hoy para crear un asunto, proponer un email o generar variantes de contenido. Eso es útil, pero no es necesariamente lo más relevante de Claudeforce. La diferencia aparece cuando la IA puede razonar teniendo en cuenta **el contexto real del cliente y de la actividad comercial**. Por ejemplo, preguntas como: - ¿Qué cuentas están mostrando señales relevantes? - ¿Qué segmentos están respondiendo mejor? - ¿Qué está ocurriendo en Ventas con estas cuentas? - ¿Qué contexto debería tener en cuenta una campaña? - ¿Qué clientes necesitan una comunicación diferente? El salto no sería simplemente generar más contenido. Sería **utilizar el contexto del negocio para decidir mejor qué contenido o acción tiene sentido**. Salesforce ha mostrado como futuras áreas de Marketing la creación y el ajuste de campañas, el contenido y la personalización. Pero mientras sigan en roadmap hay que tratarlas como lo que son: **capacidades anunciadas, no funcionalidades disponibles.** #### ¿Y para Atención al Cliente? La situación es similar. Salesforce también presenta capacidades de Service dentro de las siguientes fases de Salesforce in Claude, y actualmente aparecen como próximas. Por tanto, tampoco hay que venderlas como funcionalidad disponible hoy. Pero el problema de negocio al que apuntan es claro. Un agente recibe una incidencia. Para responder necesita entender: - Quién es el cliente. - Qué ha ocurrido antes. - Qué producto o servicio tiene. - Qué incidencias siguen abiertas. - Qué conversaciones anteriores son relevantes. - Qué proceso debe seguir. - Qué acciones puede ejecutar. Cuando esta información está repartida, buena parte del tiempo del agente se dedica a reconstruir contexto. Una IA conectada con los datos y procesos de Salesforce puede cambiar esa dinámica. La oportunidad no consiste únicamente en redactar respuestas más rápido. Consiste en **reducir el trabajo necesario para entender una situación y llegar a la siguiente acción adecuada**. Para un responsable de Customer Service, las preguntas interesantes serían: - ¿Cuánto tiempo dedica el equipo a buscar información? - ¿Qué contexto falta habitualmente cuando se abre una incidencia? - ¿Qué consultas son repetitivas? - ¿Qué tareas requieren navegar por varios sistemas? - ¿Qué acciones podrían recibir asistencia? - ¿Cuáles deberían seguir requiriendo una decisión humana? Estas preguntas deberían venir antes de: > ¿Cómo implantamos Claudeforce en Atención al Cliente? #### Claudeforce, Salesforce in Claude, Claude y Agentforce: ¿son lo mismo? No. Conviene separar los conceptos, porque los nombres se parecen lo suficiente para llevar a confusión. | Concepto | Qué significa | | --- | --- | | Claude | La plataforma y los modelos de IA de Anthropic | | Claudeforce | La alianza ampliada entre Salesforce y Anthropic | | Salesforce in Claude | El primer producto de esa alianza: trabajar desde Claude con contexto y acciones de Salesforce | | Agentforce | Las capacidades de Salesforce para crear y operar agentes de IA en su ecosistema | Claude ya tenía relación con el ecosistema Salesforce antes del anuncio de Claudeforce. Por tanto, Claudeforce no significa simplemente que «Salesforce ahora utiliza Claude». La alianza amplía esa relación y, sobre todo, lleva Salesforce hacia el entorno donde el usuario está trabajando con Claude. #### ¿Estamos dejando atrás las pantallas de Salesforce? No necesariamente. Pero el anuncio sí apunta hacia un cambio en la forma de acceder a los procesos. Durante años, utilizar una aplicación empresarial ha significado navegar por una interfaz previamente diseñada. En Salesforce, por ejemplo: cuenta, oportunidad, actividad, informe, dashboard. Una interfaz conversacional permite empezar desde otro sitio: la intención. - Prepárame la reunión con esta cuenta. - ¿Qué oportunidades necesitan atención? - ¿Qué ha cambiado en mi pipeline? - Resume la situación de este cliente. - ¿Qué deberíamos revisar antes de cerrar el forecast? La interfaz tradicional sigue teniendo valor. Pero puede dejar de ser la única manera de acceder al contexto y ejecutar determinadas tareas. Para un responsable de Ventas, Marketing o Atención al Cliente, esta es probablemente una lectura más importante del anuncio que las características concretas del modelo de IA utilizado. #### El reto no es tener Claudeforce. Es encontrar un caso de uso útil Es fácil empezar al revés. Salesforce anuncia una nueva capacidad. La empresa pregunta: > ¿Cómo podemos utilizar Claudeforce? Pero «utilizar Claudeforce» no es un objetivo de negocio. Formulaciones mucho más útiles serían: - Los comerciales dedican demasiado tiempo a reconstruir el contexto de una cuenta antes de una reunión. - El pipeline llega desactualizado porque registrar determinados cambios exige demasiado trabajo. - Los agentes de Atención al Cliente tienen que consultar varios sistemas antes de responder. - Marketing y Ventas trabajan con información distinta cuando deciden qué cuentas priorizar. Ahora sí existe un problema que evaluar. La tecnología viene después. #### ¿Qué deberías revisar antes de plantearte Salesforce in Claude? Hay cinco preguntas que resultan más útiles que empezar por las funcionalidades. ##### 1. ¿Qué proceso queremos mejorar? Definir un caso de uso concreto. No: > Queremos aplicar IA a Ventas. Sí: > Queremos reducir el tiempo que dedica cada comercial a preparar una reunión con una cuenta compleja. Cuanto más concreto sea el proceso, más fácil será valorar si la tecnología aporta algo. ##### 2. ¿Salesforce contiene el contexto necesario? Una IA conectada con Salesforce puede trabajar con la información disponible. No con la que debería estar pero no está. Antes de automatizar o asistir una decisión hay que saber: - Qué datos necesita. - Dónde están. - Quién los mantiene. - Si son fiables. - Si existe contexto relevante fuera de Salesforce. ##### 3. ¿Qué puede recomendar y qué puede ejecutar? No todas las acciones necesitan el mismo nivel de autonomía. Puedes permitir que una IA prepare un resumen. Otra cosa es que modifique una oportunidad. Y otra distinta que envíe una comunicación a un cliente. Hay que diseñar los límites según el proceso y su riesgo. ##### 4. ¿Qué debe seguir decidiendo una persona? La pregunta no es únicamente si la IA puede hacerlo. También es si queremos que lo haga. En Ventas, Marketing y Atención al Cliente existen decisiones con contexto comercial, reputacional y relacional. Automatizar una tarea repetitiva y delegar una decisión relevante son cosas diferentes. ##### 5. ¿El proceso funciona correctamente hoy? Una IA no arregla por sí sola un proceso mal diseñado. Si las oportunidades no se actualizan, hay que entender por qué. Si Marketing y Ventas trabajan con criterios distintos, hay que resolver esa diferencia. Si cada agente de Customer Service sigue un proceso diferente, primero hay que decidir qué comportamiento queremos. **Automatizar un proceso que no funciona puede hacer que el problema ocurra más rápido.** #### ¿Está Claudeforce disponible ya? Aquí conviene ser preciso. A fecha de **8 de septiembre de 2026**, Salesforce indica que Salesforce in Claude está disponible para un grupo seleccionado de clientes piloto. Salesforce mantiene además prevista una beta abierta durante septiembre de 2026. La primera versión está centrada en Ventas y Salesforce anuncia que irá incorporando capacidades para otros equipos. Las experiencias específicas mostradas para Marketing y Service aparecen actualmente como **coming soon**. | Capacidad | Estado según la información oficial | | --- | --- | | Claudeforce como alianza Salesforce–Anthropic | Anunciada | | Salesforce in Claude | Disponible para determinados clientes piloto | | 37 skills iniciales orientadas a Ventas | Parte del producto presentado | | Beta abierta | Prevista para septiembre de 2026 | | Capacidades específicas de Marketing | Anunciadas / coming soon | | Capacidades específicas de Service | Anunciadas / coming soon | > **Esta tabla tiene fecha.** Los estados anteriores se comprobaron el 8 de septiembre de 2026 en la nota de prensa de Salesforce y en su página de Claudeforce. La disponibilidad puede cambiar rápidamente, y Salesforce indica que además puede variar por región y queda sujeta a los acuerdos con cada cliente. Antes de tomar decisiones de proyecto hay que verificar el [estado actual que publica Salesforce](https://www.salesforce.com/claudeforce/), el acceso, el packaging y las condiciones aplicables. #### ¿Qué debería hacer una empresa que ya utiliza Salesforce? No empezaría preguntando cuándo podéis activar Claudeforce. Empezaría buscando dos o tres situaciones donde el equipo invierta tiempo en: - Buscar información. - Reconstruir contexto. - Interpretar datos. - Cambiar entre sistemas. - Actualizar Salesforce manualmente. - Preparar una decisión repetitiva. Después analizaría cuál tiene suficiente valor y un riesgo razonable. En Ventas podría ser la preparación de reuniones o la revisión del pipeline. En Marketing, cuando las capacidades estén disponibles, podría ser utilizar mejor el contexto comercial para preparar o ajustar determinadas acciones. En Atención al Cliente, podría ser reconstruir el contexto de una incidencia antes de decidir cómo responder. Después vienen los datos, los permisos, el proceso y la tecnología. No al revés. Ese orden es exactamente el trabajo de una [consultoría Salesforce](/salesforce/consultoria): decidir qué tiene que cambiar en el proceso antes de elegir la solución. #### Claudeforce importa más por el modelo de trabajo que por el nombre Es posible que dentro de unos meses cambien funcionalidades, nombres o packaging. Eso ocurre continuamente en Salesforce y en IA. Pero detrás de Claudeforce hay una tendencia que merece atención. Hasta ahora, gran parte del trabajo con un CRM empezaba buscando información dentro de una aplicación. La IA empieza a permitir otro enfoque: **explicar qué necesitas y dejar que el sistema reúna contexto, razone sobre él y ejecute determinadas acciones bajo las reglas de la empresa.** Para un responsable de Ventas, de Marketing o de Atención al Cliente, esto puede significar menos tiempo reconstruyendo información y más tiempo tomando decisiones. Pero solo si el contexto es fiable. Solo si los procesos están claros. Y solo si se ha decidido correctamente qué puede hacer la IA y qué debe seguir haciendo una persona. Ese es el punto por el que merece la pena empezar. #### Preguntas frecuentes **¿Qué es Claudeforce?** Claudeforce es la alianza ampliada entre Salesforce y Anthropic para conectar las capacidades de Claude con los datos, procesos, permisos y acciones de Salesforce. No es un nuevo CRM ni un producto independiente que sustituya a Salesforce. **¿Qué es Salesforce in Claude?** Salesforce in Claude es el primer producto presentado dentro de Claudeforce. Permite trabajar desde Claude con contexto de Salesforce y realizar determinadas acciones gobernadas por los permisos y las reglas de negocio de Salesforce. La primera versión está centrada en Ventas. **¿Claudeforce es lo mismo que Agentforce?** No. Agentforce es el conjunto de capacidades de Salesforce para crear y operar agentes de IA dentro de su ecosistema. Claudeforce es la alianza entre Salesforce y Anthropic. Claude ya puede participar en determinadas capacidades del ecosistema Agentforce, pero los conceptos no son equivalentes. **¿Salesforce in Claude está disponible actualmente?** Salesforce indica, a fecha de 8 de septiembre de 2026, que está disponible para determinados clientes piloto y mantiene prevista una beta abierta durante septiembre. La disponibilidad debe verificarse de nuevo antes de tomar una decisión de compra o de proyecto. **¿Salesforce in Claude ya está disponible para Marketing y Atención al Cliente?** La primera fase está centrada en Ventas. Salesforce ha anunciado futuras capacidades para Marketing y Service, pero en la información oficial actual aparecen como coming soon. --- ### ¿Por qué tu equipo sigue usando Excel aunque tenga Salesforce? - URL: https://kaizenstep.com/blog/excel-paralelo-salesforce - Materia: Adopción y uso - Publicado: 2026-09-08 Si tu equipo sigue utilizando Excel aunque tenga Salesforce, normalmente hay una parte del proceso real que el CRM no está resolviendo bien. Puede ser un problema de proceso, configuración, datos, utilidad para el usuario o forma de gestionar. Prohibir Excel sin entender la causa suele desplazar el problema, no resolverlo. La señal importante no es que exista una hoja de cálculo. Es **qué trabajo se está haciendo en ella y por qué el equipo prefiere hacerlo allí**. #### Si tenemos Salesforce, ¿por qué seguimos utilizando Excel? Imagina la reunión comercial del lunes. Salesforce muestra un pipeline. El Director Comercial tiene otro fichero abierto. Algunos comerciales han actualizado las oportunidades esa misma mañana. Otros envían sus previsiones por correo. Y antes de cerrar el forecast alguien termina conciliando distintas versiones de la información. Salesforce está implantado. Pero el proceso de gestión comercial no está ocurriendo realmente en Salesforce. Cuando esto sucede, es fácil concluir que el problema son los usuarios: > Los comerciales no actualizan el CRM. Puede ser cierto. Pero no explica por qué. Si quieres mejorar la adopción, la pregunta útil es otra: **¿qué consigue el comercial trabajando en Excel que no está consiguiendo trabajando en Salesforce?** La respuesta suele apuntar hacia alguno de los siguientes problemas. #### 1. Salesforce pide información, pero aporta poco al comercial Una de las primeras cosas que conviene revisar es el intercambio de valor. ¿Qué tiene que hacer el comercial dentro de Salesforce? ¿Introducir datos? ¿Actualizar campos? ¿Registrar actividades? ¿Cambiar fases? ¿Informar de la fecha de cierre? Ahora cambia la pregunta. ¿Qué obtiene a cambio? - ¿Puede saber qué oportunidades debería priorizar? - ¿Tiene contexto antes de llamar a un cliente? - ¿Puede preparar una reunión sin consultar otros sistemas? - ¿Puede ver fácilmente qué operaciones necesitan atención? ¿Salesforce le ayuda a vender o principalmente le ayuda a reportar hacia arriba? Si el CRM se percibe como el lugar donde introducir información para que otros preparen informes, Excel puede resultar más rápido para gestionar el trabajo individual. La adopción empieza a complicarse cuando **el coste de mantener Salesforce lo soporta el usuario, pero el valor lo recibe principalmente otra persona**. No siempre hace falta añadir funcionalidad. A veces hay que revisar qué información se pide, para qué sirve y qué obtiene el usuario de ese proceso. #### 2. El proceso configurado no coincide con cómo se vende realmente Salesforce puede estar funcionando exactamente como fue configurado y, aun así, estar mal adaptado al negocio. Quizá la implementación se diseñó hace cuatro años. Desde entonces han cambiado los equipos, el modelo comercial, los productos, el canal o la forma de gestionar las oportunidades. Pero Salesforce sigue esperando el proceso anterior. Entonces aparecen los atajos. Un comercial mantiene una columna adicional en Excel porque Salesforce no contempla una información que ahora necesita. Otro crea su propia clasificación de oportunidades. Un responsable prepara el forecast fuera porque las fases del CRM ya no representan bien la probabilidad real de cerrar. El Excel paralelo puede ser simplemente una señal de que **el proceso real ha evolucionado y Salesforce no lo ha hecho con él**. En ese caso, pedir más disciplina a los usuarios no corrige el origen. Puede ser necesario [evolucionar una implementación de Salesforce](/salesforce/evolucion) para que vuelva a representar cómo trabaja la organización. #### 3. Actualizar una oportunidad requiere demasiado trabajo También puede ocurrir algo mucho más sencillo: mantener Salesforce cuesta demasiado. Una oportunidad cambia después de una conversación con el cliente. Para reflejarlo correctamente, el comercial tiene que abrir el registro, cambiar varios campos, completar información que no utiliza, actualizar una fecha, registrar una actividad y quizá pasar por alguna validación. En Excel modifica dos celdas. ¿Cuál va a utilizar cuando tiene diez oportunidades que revisar? La respuesta no siempre es «hay que formar mejor al usuario». Antes conviene revisar: - Qué información es realmente necesaria. - En qué momento debe capturarse. - Qué campos aportan valor. - Qué automatizaciones pueden reducir trabajo. - Qué información podría llegar desde otros sistemas. - Si el diseño de la pantalla responde al trabajo del usuario. Añadir campos obligatorios puede mejorar temporalmente el porcentaje de registros completos. Eso no significa necesariamente que mejore la calidad de los datos. Un Salesforce que obliga a trabajar alrededor del sistema termina generando más trabajo fuera del sistema. #### 4. El forecast vive en Excel porque Dirección no confía en el pipeline Este es uno de los síntomas más importantes. Salesforce contiene las oportunidades, pero el forecast definitivo se prepara fuera. ¿Por qué? Quizá hay fechas de cierre vencidas. Oportunidades que llevan meses en la misma fase. Importes que no se han revisado. Operaciones abiertas que comercialmente ya están perdidas. Faltan siguientes pasos. O cada vendedor interpreta las fases de una forma diferente. Cuando Dirección deja de confiar en el pipeline, normalmente construye un mecanismo paralelo. Una hoja de cálculo. Una reunión. Un fichero enviado cada viernes. Un forecast que se rehace manualmente. > **El problema es circular.** Como Dirección no confía en Salesforce, gestiona fuera. Como la gestión ocurre fuera, el equipo tiene todavía menos motivos para mantener Salesforce al día. Y como Salesforce se actualiza menos, Dirección confía todavía menos en los datos. Romper ese ciclo requiere algo más que pedir que «se actualice el CRM». Hay que revisar qué información necesita realmente Dirección para gestionar y qué comportamiento debe ocurrir durante la semana para que esa información sea fiable. #### 5. Los managers también trabajan fuera de Salesforce La adopción no depende únicamente del comercial. Si el responsable pide por correo información que ya debería estar en Salesforce, el equipo aprende rápidamente dónde está el sistema que de verdad importa. Si la reunión de pipeline se hace sobre una hoja de cálculo, esa hoja se convierte en prioritaria. Si el forecast que llega a Dirección se construye fuera del CRM, actualizar Salesforce puede percibirse como una tarea administrativa adicional. El comportamiento de gestión importa. Salesforce empieza a formar parte de la manera de trabajar cuando también se utiliza para: - Revisar oportunidades. - Preparar reuniones. - Decidir prioridades. - Analizar el pipeline. - Hacer seguimiento. - Detectar problemas. - Pedir explicaciones sobre datos concretos. No basta con pedir al equipo que use Salesforce. **La gestión también tiene que ocurrir sobre Salesforce cuando Salesforce es el sistema que debería soportar ese proceso.** #### 6. Cada comercial ha construido su propio sistema Excel tiene una ventaja evidente: es flexible. Cada persona puede ordenar la información como quiera, añadir columnas, colores, notas y cálculos sin solicitar ningún cambio. Cuando Salesforce no responde bien a distintas necesidades del equipo, pueden aparecer pequeñas soluciones personales. Una hoja para hacer seguimiento. Otra para preparar el forecast. Una lista personal de clientes. Un fichero con proyectos prioritarios. El problema no es necesariamente cada Excel aislado. El problema aparece cuando dejan de existir criterios comunes. Entonces puedes tener: - Diferentes versiones del pipeline. - Distintas definiciones de qué significa una oportunidad prioritaria. - Información que solo conoce una persona. - Datos que no llegan a otros equipos. - Reporting que necesita reconciliación manual. Aquí la conversación deja de ser únicamente tecnológica. Hay que decidir **qué parte del proceso necesita ser común y qué flexibilidad necesita realmente cada usuario**. #### 7. Se intentó solucionar un problema de adopción con formación Cuando el equipo no utiliza Salesforce, una reacción habitual es organizar otra formación. A veces es exactamente lo necesario. Si los usuarios no saben realizar una tarea, hay un problema de conocimiento. Pero si saben perfectamente cómo actualizar una oportunidad y deciden mantenerla en Excel, probablemente estamos ante otro problema. Puede que Salesforce no encaje con el proceso. Que actualizarlo requiera demasiado esfuerzo. Que los datos no sean fiables. Que el manager no lo utilice. O que el usuario no obtenga ningún valor claro al mantenerlo. > **Un equipo formado puede tener una adopción baja.** La formación ayuda a que una persona sepa utilizar Salesforce. La adopción implica que Salesforce forme parte de su manera normal de trabajar. Son dos problemas distintos y se resuelven de forma distinta. #### ¿Cómo saber por qué aparece Excel? No empieces contando hojas de cálculo. Empieza observando qué trabajo está saliendo de Salesforce. | Lo que observas | Qué podría estar pasando | Qué conviene investigar | | --- | --- | --- | | El forecast se rehace en Excel | Dirección no confía en el pipeline | Fechas, fases y criterios de forecast | | Cada comercial tiene su propia hoja | Salesforce no cubre ese seguimiento | Qué información mantiene fuera y para qué | | El CRM se actualiza antes de la reunión | Funciona como reporting, no como herramienta diaria | Qué aporta Salesforce durante la semana | | Muchos campos incompletos | Falta de uso o demasiada carga administrativa | Qué campos son necesarios y quién los usa | | Cada equipo usa el CRM de otra forma | El proceso no está definido o ya no encaja | Criterios comunes y diferencias legítimas | | Hubo formación y el comportamiento no cambió | El problema no es solo de conocimiento | Proceso, utilidad, configuración y gestión | La tabla no es un diagnóstico automático. El mismo síntoma puede tener causas diferentes. La clave está en investigar el comportamiento antes de decidir la solución. #### ¿Hay que eliminar Excel? No. Excel no necesita desaparecer de una empresa para que Salesforce tenga una buena adopción. Puede ser perfectamente útil para: - Un análisis puntual. - Una simulación. - Trabajo exploratorio. - Cálculos específicos. - Necesidades que no forman parte del proceso compartido. La pregunta es otra: **¿Excel está complementando Salesforce o lo está sustituyendo?** Si un usuario exporta unos datos para analizarlos puntualmente, probablemente no tienes un problema de adopción. Si el pipeline real está en una hoja, el forecast se decide en otra y Salesforce se actualiza después para cumplir con el reporting, sí hay una señal que merece atención. No se trata de prohibir una herramienta. Se trata de decidir **dónde debe vivir cada proceso y qué sistema debe ser la referencia para el equipo**. #### ¿Es un problema de adopción o Salesforce necesita evolucionar? Muchas veces son las dos cosas. Puedes tener un problema de adopción porque el proceso no está claro. Pero también puedes tenerlo porque Salesforce lleva años sin adaptarse a los cambios del negocio. Antes de actuar conviene separar las causas. Si el proceso funciona y Salesforce lo soporta correctamente, pero el equipo no sabe utilizarlo, puede haber una necesidad de formación. Si los usuarios saben qué hacer pero el sistema genera demasiada fricción, habrá que revisar configuración y usabilidad. Si el negocio ha cambiado y Salesforce sigue representando el proceso antiguo, probablemente necesitarás evolución. Y si cada equipo trabaja de forma diferente y no existe un criterio común, el problema puede empezar antes de Salesforce. Si no sabes cuál de estas situaciones tienes, los [KPIs para medir la adopción de Salesforce](/blog/kpis-adopcion-salesforce) pueden ayudarte a localizar dónde se está rompiendo el proceso. #### ¿Por dónde empezar si el equipo sigue trabajando en Excel? No empezaría eliminando hojas. Tampoco empezaría añadiendo campos obligatorios. Empezaría seleccionando uno de los procesos donde Excel está sustituyendo claramente a Salesforce. Por ejemplo, el forecast. Después seguiría el proceso real: - ¿Cómo actualiza una oportunidad el comercial? - ¿Qué información necesita? - ¿Qué se registra en Salesforce y qué se mantiene fuera? - ¿Qué consulta el manager? - ¿Qué ocurre durante la reunión de pipeline? - ¿De qué dato se fía Dirección? La diferencia entre el proceso diseñado y el proceso real suele mostrar bastante rápido dónde está la fricción. A partir de ahí puedes decidir qué necesita cambiar. Quizá sea Salesforce. Quizá sea el proceso. Quizá sea la forma de gestionar. Quizá haga falta formación. O varias cosas a la vez. Eso es [mejorar la adopción de Salesforce](/salesforce/adopcion): conseguir que el sistema encaje en la forma real de trabajar y que el equipo tenga motivos para utilizarlo de forma consistente. #### Preguntas frecuentes **¿Es malo utilizar Excel si una empresa tiene Salesforce?** No. Excel puede seguir siendo útil para análisis y trabajos puntuales. El problema aparece cuando una hoja de cálculo sustituye a Salesforce en un proceso compartido que debería gestionarse en el CRM, como el pipeline o el forecast. **¿Por qué los comerciales prefieren Excel a Salesforce?** No existe una única causa. Puede deberse a que Salesforce requiere demasiado trabajo, no refleja el proceso real, aporta poco valor al usuario, contiene datos poco fiables o no se utiliza para gestionar el equipo. **¿Más formación hará que el equipo deje de utilizar Excel?** Solo si el problema es de conocimiento. Si los usuarios saben utilizar Salesforce pero siguen trabajando fuera porque el proceso o la configuración generan fricción, la formación por sí sola no resolverá el problema. **¿Cómo saber si tenemos un problema de adopción de Salesforce?** Una señal clara es que procesos que deberían ocurrir en Salesforce se realizan sistemáticamente fuera: oportunidades actualizadas a última hora, forecast en Excel, hojas personales o datos que Dirección no considera fiables. Conviene analizar conjuntamente uso, calidad de datos y comportamiento del proceso. **¿Hay que prohibir las hojas de Excel para mejorar la adopción?** No debería ser el primer paso. Antes conviene identificar qué necesidad está resolviendo esa hoja y por qué Salesforce no la cubre. Eliminar el fichero sin resolver la causa puede provocar que el mismo trabajo paralelo aparezca de otra forma. --- ### Cambiar de partner de Salesforce: qué revisar antes de tomar la decisión - URL: https://kaizenstep.com/blog/cambiar-partner-salesforce - Materia: Evolución de la plataforma - Publicado: 2026-09-08 Salesforce funciona, pero cada mejora cuesta demasiado. El backlog crece, los usuarios siguen resolviendo cosas fuera y cada petición abre una conversación nueva con el partner sin que nadie termine de mirar el conjunto. Es un momento bastante reconocible, y de ahí sale casi siempre la misma pregunta: ¿necesitamos cambiar de partner Salesforce? Cambiar de partner de Salesforce puede ser la decisión correcta cuando la relación actual está impidiendo resolver problemas o evolucionar la plataforma. Pero un nuevo proveedor no arregla por sí solo una org mal diseñada, datos poco fiables o un proceso que la propia empresa no tiene claro. **Antes de cambiar, conviene separar qué está fallando en Salesforce, qué depende del partner y qué depende de la propia organización.** #### ¿Cómo saber si el problema es realmente el partner? No basta con que una mejora haya tardado, ni con que haya habido una incidencia mal resuelta. Una relación con un partner debería valorarse mirando un patrón. Por ejemplo: - Salesforce lleva tiempo sin evolucionar aunque el negocio haya cambiado. - Los mismos problemas reaparecen. - El equipo plantea necesidades de negocio y la conversación acaba reducida a campos, objetos o tickets. - Hay un backlog largo, pero poca claridad sobre qué debería hacerse primero. - Cada cambio se ejecuta de forma aislada y luego aparecen efectos en otras partes de Salesforce. - La organización depende demasiado del partner para entender qué tiene montado. O simplemente tienes la sensación de que estás pagando por mantener Salesforce vivo, pero no por hacerlo más útil. Una de estas situaciones aislada no demuestra que necesites cambiar de partner. Varias mantenidas en el tiempo sí justifican revisar qué está ocurriendo. #### Señales de que la relación con tu partner necesita una revisión ##### 1. Salesforce ha dejado de seguir al negocio El proceso comercial ha cambiado. Hay nuevos canales, ha cambiado la forma de gestionar distribuidores, Marketing trabaja de otra manera y Customer Service necesita información nueva. Pero Salesforce continúa prácticamente igual que hace años. Una plataforma como Salesforce necesita evolucionar porque el negocio también lo hace. Si cada cambio resulta demasiado difícil, caro o lento de plantear, conviene entender por qué: puede ser un problema de prioridades internas, puede ser deuda acumulada en la configuración, o puede ser que la relación con el partner se haya vuelto demasiado reactiva. ##### 2. Todo se ha convertido en tickets - «Necesitamos añadir este campo.» - «Este informe no cuadra.» - «Hay que cambiar esta automatización.» - «Queremos una nueva vista.» Cada petición puede resolverse correctamente y aun así existir un problema, porque alguien tiene que hacerse otra pregunta: **¿por qué estamos pidiendo todos estos cambios?** Quizá el informe no cuadra porque los datos no se mantienen. Quizá el nuevo campo intenta compensar un proceso mal definido. Quizá hay cinco automatizaciones porque nunca se revisó el flujo completo. Si la relación consiste únicamente en pedir y ejecutar cambios, Salesforce puede acumular soluciones locales sin resolver problemas de fondo. ##### 3. El backlog crece, pero nadie sabe qué es realmente prioritario Hay cuarenta peticiones pendientes. Ventas necesita unas, Marketing otras, Customer Service tiene su propia lista e IT quiere resolver problemas técnicos. Todas parecen importantes, y cada reunión termina moviendo las prioridades. Un backlog no es una estrategia de evolución. El partner debería poder participar en una conversación donde la pregunta no sea solo qué hacemos primero, sino esta otra: > ¿Qué problema de negocio merece realmente que cambiemos Salesforce? Si esa conversación ha desaparecido, merece la pena revisar la relación. ##### 4. El partner entiende Salesforce, pero no termina de entender cómo trabaja la empresa Una solución puede ser técnicamente correcta y operativamente inútil. El pipeline funciona, los campos están creados y las automatizaciones se ejecutan. Pero los comerciales siguen usando Excel porque las oportunidades no representan cómo venden. O Customer Service tiene Salesforce abierto mientras consulta otro sistema para saber qué le ha pasado realmente al cliente. O Marketing trabaja con segmentos que no coinciden con los que utiliza Ventas. El conocimiento técnico es necesario, pero no basta: Salesforce tiene que reflejar una forma concreta de trabajar. ##### 5. Dependéis del partner para entender vuestra propia org Preguntas algo relativamente sencillo: «¿por qué funciona así este proceso?». Y nadie dentro de la organización lo sabe. «Eso lo hizo el partner.» - Automatizaciones cuyo origen no está claro. - Decisiones antiguas que nadie recuerda. - Dependencias que solo conoce una persona externa. - Documentación incompleta o difícil de localizar. Eso no significa necesariamente que el partner haya trabajado mal: muchas implementaciones acumulan años de decisiones, equipos y cambios. Pero sí genera un riesgo importante si estás pensando en un relevo. > **Qué estás entregando al siguiente.** No deberías cambiar de partner sin saber razonablemente qué tienes montado. Si la explicación de tu Salesforce vive solo en el proveedor que se va, el relevo empieza a ciegas. ##### 6. Los problemas se corrigen, pero vuelven Se arregla el informe y tres meses después vuelve a fallar. Se modifica un proceso y aparece otro Excel paralelo. Se simplifica una pantalla y los usuarios siguen sin actualizar la información. Cuando los síntomas vuelven, merece la pena preguntarse si estamos resolviendo causas o simplemente incidencias. Un cambio de partner puede ser útil, pero solo si el siguiente empieza por entender por qué ocurre el problema. #### No todo problema con Salesforce es un problema de partner Esta parte es importante. Cambiar de partner es una decisión relativamente visible; cambiar algunas dinámicas internas puede ser más incómodo. Imagina que Dirección no confía en el forecast y las oportunidades no se actualizan. Es fácil concluir que Salesforce no funciona bien y, después, que el partner no lo ha hecho bien. Puede ser. Pero también puede ocurrir que las fases comerciales nunca se hayan definido con suficiente claridad. O que cada manager las interprete de una forma. O que actualizar Salesforce no tenga ninguna utilidad para el comercial y solo sirva para preparar informes. O que Dirección continúe pidiendo el forecast en Excel aunque Salesforce esté configurado correctamente. Un nuevo partner puede ayudarte a cambiar esas cosas. **Pero no puede sustituir decisiones que corresponden a la propia organización.** #### ¿Qué situaciones pueden confundirse con un problema de partner? | Lo que ocurre | Puede ser un problema del partner | Qué conviene revisar | | --- | --- | --- | | Las mejoras tardan constantemente y no existe claridad sobre prioridades | Sí | Backlog, modelo de trabajo y capacidad de priorización | | Salesforce ya no refleja cómo trabaja el negocio | Sí, pero no necesariamente | Proceso real frente a proceso configurado | | Los usuarios trabajan en Excel | Depende | Adopción, utilidad, proceso y diseño | | Los informes no son fiables | Depende | Calidad del dato, definición de métricas y uso | | Existen muchas automatizaciones difíciles de mantener | Puede serlo | Cómo se ha acumulado la configuración | | Nadie dentro sabe por qué Salesforce funciona como funciona | Es una señal de riesgo | Documentación, gobierno y dependencia externa | | Las áreas no se ponen de acuerdo sobre el proceso | No principalmente | Decisiones y gobierno internos | | Cada departamento pide cambios contradictorios | No principalmente | Priorización y ownership interno | Esta distinción importa porque **cambiar de partner sin entender la causa puede cambiar el proveedor y conservar exactamente el mismo problema**. #### ¿Qué deberías tener claro antes de cambiar? No necesitas conocer hasta el último detalle técnico de Salesforce, pero tampoco conviene empezar el relevo con una caja negra. Antes de cambiar, intenta responder al menos estas preguntas. ##### ¿Qué problemas quieres resolver? No empieces por la lista de tickets, empieza por el negocio. «Necesitamos diecisiete cambios» dice poco. «Dirección no confía en el forecast porque las oportunidades no reflejan la situación real» permite empezar una conversación útil. «Customer Service consulta tres sistemas para responder una incidencia» también. «Cada distribuidor se gestiona de una forma y no tenemos un pipeline consolidado» también. El nuevo partner necesita entender primero esto. ##### ¿Qué funciona bien y no quieres perder? Cambiar de partner no significa empezar Salesforce de cero. Probablemente hay procesos que funcionan, automatizaciones útiles, informes que el equipo utiliza, integraciones necesarias y formas de trabajar que ya están adoptadas. Un relevo bien planteado también debe identificar qué hay que conservar. ##### ¿Qué lleva meses esperando? Revisa el backlog, pero no para entregárselo sin más al nuevo partner. Clasifícalo: ¿qué es una incidencia? ¿Qué es una mejora? ¿Qué petición ya no tiene sentido? ¿Qué está bloqueando realmente al negocio? ¿Qué existe simplemente porque alguien lo pidió hace un año? Cambiar de partner es una buena oportunidad para dejar de tratar el backlog como una lista cronológica. ##### ¿Dónde siguen apareciendo Excels y procesos paralelos? Los sistemas paralelos cuentan una historia. Puede que exista un Excel porque Salesforce no cubre una necesidad, porque la cubre mal, porque los usuarios no saben usarla, porque el proceso configurado no corresponde al real o simplemente porque nadie ha cuestionado ese Excel en cinco años. No des por hecho que todo debe migrarse a Salesforce. Pero entiende por qué existe. ##### ¿Qué sabemos de la org que tenemos? No necesitas convertir esta revisión en un proyecto de arqueología. Sí necesitas evitar que toda la explicación del sistema sea «pregúntale al partner anterior». Estas son las ocho cosas que conviene poder situar antes de un relevo: - **Prioridades pendientes:** qué está esperando y qué bloquea al negocio. - **Procesos que no funcionan:** dónde el proceso configurado no es el real. - **Configuración y automatizaciones relevantes:** lo que nadie quiere tocar y por qué. - **Integraciones:** con qué sistemas habla Salesforce y cuáles son críticos. - **Datos:** en qué información se confía y en qué no. - **Adopción:** quién usa Salesforce de verdad y para qué. - **Documentación disponible:** qué está escrito y qué vive en la cabeza de alguien. - **Decisiones pendientes:** lo que la organización todavía no ha decidido. #### ¿Qué deberías preguntar a un posible nuevo partner? Una primera reunión no debería consistir únicamente en enseñarle el backlog. Hay preguntas que permiten saber bastante más. ##### «¿Qué necesitaríais revisar antes de proponernos cambios?» Una respuesta útil debería empezar por entender la situación, no por vender inmediatamente una solución. ##### «¿Cómo distinguiríais qué debemos mantener y qué debemos cambiar?» Un Salesforce con años de uso contiene decisiones buenas y malas. Cambiar de partner no debería significar cuestionarlo todo. ##### «¿Cómo vais a entender nuestro proceso real?» Esto es especialmente importante cuando el problema no es puramente técnico. Si el pipeline, el canal, el servicio técnico o la relación entre Marketing y Ventas son importantes, el nuevo partner necesita entenderlos. ##### «¿Cómo priorizaríais nuestro backlog?» La respuesta no debería ser simplemente por orden de llegada. Conviene saber cómo conecta las peticiones con problemas y prioridades de negocio. ##### «¿Qué necesitáis del partner anterior?» La transición puede requerir información, documentación y contexto. Es mejor saberlo antes que descubrir dependencias cuando el relevo ya está en marcha. ##### «¿Qué problemas veis que quizá no se solucionen cambiando de partner?» Esta pregunta es especialmente útil. Un nuevo proveedor tiene incentivos evidentes para decir que puede mejorar la situación; también debería ser capaz de señalar qué decisiones dependen de tu propia organización. #### ¿Hay que tenerlo todo documentado antes de hacer el cambio? No. Si precisamente uno de los problemas es la dependencia del partner actual, es posible que no dispongas de toda la documentación que te gustaría. Eso no debería bloquear la decisión. Sí conviene saber qué tienes y qué no tienes: qué procesos están claros, qué integraciones son críticas, qué personas internas conocen mejor Salesforce, qué problemas están abiertos y qué información depende hoy de terceros. El objetivo no es llegar al nuevo partner con una org perfectamente documentada. **Es evitar llegar sin saber siquiera dónde están las incógnitas.** #### ¿Y si no sé si necesito cambiar de partner o arreglar Salesforce? Es una situación bastante habitual. Ves los síntomas, pero no está clara la causa. El forecast no es fiable, los usuarios trabajan fuera, hay automatizaciones que nadie quiere tocar, los informes generan discusiones, el backlog crece y la relación con el partner actual tampoco convence. Pero es difícil saber qué parte explica qué. Ahí tiene sentido separar el diagnóstico de la decisión de cambio. Una [auditoría de Salesforce](/salesforce/auditoria) puede ayudarte a entender primero cuál es el punto de partida. Porque quizá necesites otro partner. Quizá necesites [evolucionar un Salesforce que ya está en producción](/salesforce/evolucion). Quizá el problema principal sea de adopción o de gobierno interno. O una combinación de varias cosas. La decisión mejora mucho cuando sabes qué estás intentando resolver. #### Cambiar de partner no debería empezar por buscar otro partner Debería empezar por entender por qué estás pensando en cambiar. - ¿Qué está fallando? - ¿Qué debería estar ocurriendo y no ocurre? - ¿Qué parte de Salesforce ya no encaja? - ¿Qué funciona y quieres conservar? - ¿Dónde depende demasiado la empresa de terceros? - ¿Qué tendría que ser distinto dentro de un año para considerar que el cambio ha valido la pena? Con esas respuestas puedes evaluar mucho mejor [qué debería aportar un partner Salesforce](/salesforce/partner). Y también puedes llegar a una conclusión perfectamente válida: que todavía no necesitas cambiar. Puede que necesites poner orden. Priorizar. Rediseñar un proceso. Resolver deuda acumulada. O decidir internamente cómo queréis utilizar Salesforce. El objetivo no es cambiar de proveedor. **El objetivo es conseguir que Salesforce vuelva a acompañar al negocio.** --- ### Headless 360 de Salesforce: qué es y cómo saber si cambia algo para tu empresa - URL: https://kaizenstep.com/blog/headless-360-salesforce - Materia: Evolución de la plataforma - Publicado: 2026-09-08 Salesforce está usando cada vez más el término Headless 360, y si tu empresa ya trabaja con la plataforma es probable que haya empezado a aparecer en presentaciones, eventos y conversaciones sobre agentes. El nombre suena bastante más complicado de lo que es. Si utilizas Salesforce, es probable que hayas empezado a encontrarte Headless 360 en presentaciones, eventos o conversaciones sobre agentes de inteligencia artificial. El nombre puede hacer pensar que Salesforce ha lanzado otro producto que hay que evaluar o implantar. **Headless 360 no es un nuevo Salesforce ni un producto que tengas que implantar. Es la arquitectura con la que Salesforce quiere que sus datos, procesos y reglas puedan utilizarse también desde agentes y otras aplicaciones, sin obligar a una persona a trabajar siempre desde la interfaz de Salesforce.** Si ya utilizas Salesforce, la pregunta útil no es «¿necesitamos Headless 360?». Es otra: **¿qué tareas tendría sentido resolver de otra forma y está nuestro Salesforce preparado para ello?** #### ¿Qué significa Headless 360 en la práctica? Pensemos en una situación bastante habitual. Se acerca la reunión de forecast y hay oportunidades que llevan días sin actualizar. Alguien pide al equipo que revise fechas de cierre, importes y siguientes pasos. Los usuarios entran en Salesforce, buscan sus oportunidades y actualizan lo necesario. Ahora imagina otra forma de hacer una de esas tareas: un agente detecta que una oportunidad debería cerrar este mes pero lleva tres semanas sin actividad, y pregunta. > Esta oportunidad sigue prevista para septiembre. ¿Mantienes la fecha de cierre? El usuario responde y Salesforce se actualiza. La oportunidad sigue estando en Salesforce, el pipeline sigue estando en Salesforce y las reglas del proceso siguen estando en Salesforce. **Lo que ha cambiado es el lugar desde el que la persona ha realizado esa acción.** Esa es una forma sencilla de entender Headless 360: Salesforce puede seguir haciendo el trabajo por detrás aunque el usuario no tenga su pantalla abierta. #### ¿Headless 360 significa dejar de utilizar la interfaz de Salesforce? No. Hay trabajos para los que seguir entrando en Salesforce tiene todo el sentido, y es justo donde una interfaz completa aporta valor. - Revisar una cuenta con varias oportunidades, contactos, actividad e incidencias - Analizar el pipeline de un equipo - Gestionar un caso que necesita mucho contexto - Comparar resultados o preparar una decisión Pero piensa ahora en otro tipo de tareas: - Confirmar una fecha - Actualizar un siguiente paso - Consultar el estado de una oportunidad - Saber si un cliente tiene incidencias abiertas - Recibir un resumen antes de una reunión - Aprobar una acción sencilla ¿Hace falta entrar en Salesforce, localizar el registro y navegar por distintas pantallas para cada una de ellas? No necesariamente. Headless 360 abre la posibilidad de que determinadas interacciones ocurran desde otros entornos mientras Salesforce sigue gestionando lo que hay detrás. **No todo lo que utiliza Salesforce tiene que ocurrir dentro de la pantalla de Salesforce.** #### Salesforce ya se conectaba con otros sistemas: ¿qué hay de nuevo? Las empresas llevan años montando [integraciones de Salesforce con otros sistemas](/salesforce/integraciones): ERP, ecommerce, aplicaciones propias y muchas otras herramientas. Y las APIs tampoco aparecieron con Headless 360. Sería exagerado decir que hasta ahora Salesforce solo podía utilizarse desde su propia interfaz. Lo que cambia es la importancia que adquiere esa separación con la llegada de los agentes. Una persona abre Salesforce, busca una oportunidad, interpreta la pantalla y decide qué hacer. Un agente trabaja de otra forma: necesita consultar información, entender determinadas reglas y ejecutar una acción sin recorrer una pantalla como lo haría una persona. Salesforce está llevando su plataforma hacia un modelo en el que esas capacidades puedan utilizarse desde distintos agentes, aplicaciones y experiencias. Y lo plantea reutilizando los datos, la metadata, los permisos y la lógica que ya existen en tu instalación, no montando un sistema paralelo. La tecnología que lo hace posible importa a quien tenga que construirla. Para el negocio hay una pregunta anterior: **¿dónde está hoy la fricción entre Salesforce y la forma real de trabajar?** #### ¿Cómo saber si Headless 360 puede ser relevante para tu empresa? No todos los problemas con Salesforce se resuelven sacando tareas de su interfaz, y no todas las empresas necesitan cambiar la forma en la que sus usuarios trabajan. Esta tabla permite hacer una primera separación. | Situación hoy | Relevancia | Qué revisar primero | | --- | --- | --- | | Se entra solo para actualizaciones muy sencillas | Puede serlo | Qué acciones generan fricción y con qué frecuencia | | El equipo trabaja en otras herramientas y actualiza tarde | Puede serlo | Qué información llega tarde y por qué | | Una aplicación propia necesita procesos de Salesforce | Puede serlo | Qué datos, acciones y reglas necesita usar | | Queremos que agentes consulten o ejecuten procesos | Puede serlo | Datos, permisos, reglas y procesos implicados | | Salesforce no refleja el proceso real del negocio | No es lo primero | El proceso y la configuración actuales | | El forecast no es fiable | Depende | Si el origen es fricción, proceso, dato o adopción | | Los datos de Salesforce no son fiables | No es el punto de partida | Calidad y gobierno del dato | | Los usuarios necesitan mucho contexto para decidir | Puede que no | Si la interfaz actual ya presenta bien ese contexto | La diferencia entre unas filas y otras es lo importante. > **Reducir fricción no es arreglar el fondo.** Headless 360 puede reducir fricción en determinadas interacciones. No arregla automáticamente los problemas que ya existen detrás de ellas. #### ¿El problema está en la interfaz o en el Salesforce que hay detrás? Esta es probablemente la comprobación más útil. Volvamos al ejemplo del forecast: el equipo no mantiene las oportunidades actualizadas. Eso puede significar cosas muy diferentes. ##### Caso 1. Actualizar un dato sencillo exige demasiado trabajo El proceso está claro y los usuarios saben qué información tienen que mantener. Pero cambiar una fecha o confirmar un siguiente paso obliga a abrir Salesforce, localizar la oportunidad y recorrer varias pantallas. Aquí puede existir una oportunidad para simplificar la interacción. El proceso quizá no necesita cambiar; la forma de acceder a él, sí. ##### Caso 2. Nadie tiene claro qué debe actualizar Las fases comerciales no están bien definidas y cada persona interpreta una oportunidad de forma distinta. Las fechas de cierre significan cosas diferentes según quién las introduzca, y hay campos obligatorios que nadie sabe por qué lo son. Aquí Headless 360 no es la solución. **Hacer más fácil la actualización de un proceso confuso no hace que el proceso deje de ser confuso.** Primero hay que revisar el Salesforce existente. ##### Caso 3. Los datos no son fiables El problema tampoco está en la interfaz. Si hay duplicados, información incompleta o datos distintos según el sistema que se consulte, permitir que un agente acceda a Salesforce no mejora el resultado por sí solo. Un agente puede obtener una respuesta más rápido. Eso no garantiza que la respuesta sea buena. ##### Caso 4. La interfaz actual funciona bien También es una conclusión perfectamente válida. No hay que sacar tareas de Salesforce simplemente porque ahora existan más posibilidades de hacerlo. Si el equipo trabaja bien en Salesforce, encuentra el contexto que necesita y el proceso es eficiente, quizá no haya nada que cambiar. **Headless 360 abre una posibilidad; no crea por sí solo una necesidad.** #### ¿Qué deberías revisar antes de pensar en Headless 360? Antes de hablar de agentes o de arquitectura, conviene mirar cómo trabajan realmente los equipos. Son cinco comprobaciones. ##### 1. ¿Para qué tareas entran hoy en Salesforce? No pienses en procesos completos, piensa en acciones: consultar un dato, actualizar una fecha, registrar una actividad, aprobar algo, preparar una reunión, revisar una incidencia. Después pregunta: **¿cuáles de esas acciones necesitan realmente una pantalla completa?** ##### 2. ¿Qué trabajo importante sigue ocurriendo fuera de Salesforce? Excel, correo, Teams, Slack, aplicaciones internas. Trabajar fuera de Salesforce no es automáticamente un problema. La señal aparece cuando información necesaria para el proceso se queda fuera y después alguien tiene que copiarla, reconstruirla o perseguir a otras personas para introducirla. ##### 3. ¿Por qué aparece la fricción? Decir «los usuarios no utilizan Salesforce» explica muy poco. Hay que bajar un nivel. - ¿Hay demasiados pasos para hacer algo sencillo? - ¿Se pide información que después nadie utiliza? - ¿Falta el contexto necesario para decidir? - ¿El proceso configurado no coincide con el proceso real? - ¿La tarea debería hacerse desde la herramienta en la que esa persona ya trabaja? Según la respuesta, la solución será distinta. ##### 4. ¿Puedes confiar en lo que hay detrás? Imagina que un agente pregunta qué oportunidades están en riesgo. ¿Las fases están actualizadas? ¿Las fechas de cierre significan lo mismo para todo el equipo y hay un siguiente paso real? Imagina que prepara el contexto de un cliente. ¿Los datos están completos? ¿Las incidencias están bien relacionadas y la información importante está de verdad en Salesforce? Headless 360 hace que estas preguntas sean más importantes, no menos. ##### 5. ¿Qué debería seguir ocurriendo dentro de Salesforce? No todo tiene que convertirse en una conversación con un agente. Hay trabajos que requieren contexto, análisis y comparación, y ahí una interfaz completa puede seguir siendo la mejor solución. El ejercicio no consiste en conseguir que los usuarios vean menos Salesforce. Consiste en decidir **qué forma de interacción tiene sentido para cada trabajo**. #### ¿Puede Headless 360 solucionar un problema de adopción? Puede reducir determinadas fricciones, pero no sustituye el trabajo que exige un [problema de adopción de Salesforce](/salesforce/adopcion). Imagina que actualizar un siguiente paso requiere demasiados clics. Permitir hacerlo de una forma más sencilla puede ayudar. Ahora imagina otro escenario. Los usuarios no actualizan las oportunidades porque el pipeline no representa cómo venden, porque introducen información que después nadie utiliza o porque Salesforce se ha convertido en la herramienta para preparar el informe de Dirección y no en algo que les ayude a trabajar. El problema ya no es la pantalla. **Cambiar el lugar desde el que se introduce un dato no soluciona la causa.** #### Entonces, ¿hay que hacer algo ahora? No necesariamente. Que Salesforce esté dando visibilidad a Headless 360 no significa que todas las empresas que ya lo utilizan necesiten arrancar un proyecto. El primer paso puede ser mucho más sencillo: observar dónde existe hoy fricción, qué tareas obligan a cambiar constantemente de herramienta, qué información llega tarde y qué acciones son innecesariamente pesadas. Y cuáles de esos problemas se deben realmente a la interfaz. Puedes terminar con tres conclusiones distintas. 1. La forma actual de trabajar funciona y no existe una razón para cambiarla. 2. Algunas interacciones podrían simplificarse sin rediseñar todo el proceso. 3. El problema no es Headless 360: el Salesforce que ya está en producción necesita cambiar. En ese último caso tiene más sentido empezar por [evolucionar un Salesforce que ya está en producción](/salesforce/evolucion) que por añadir una nueva forma de interactuar con él. #### ¿Qué cambia realmente con Headless 360? Headless 360 cambia una suposición que durante años ha sido bastante natural: **utilizar Salesforce y utilizar la interfaz de Salesforce no tienen por qué ser exactamente lo mismo.** Salesforce puede seguir siendo el lugar donde viven los datos, los procesos, los permisos y las reglas aunque determinadas interacciones ocurran desde otra aplicación o mediante un agente. Para algunas empresas esto abrirá formas interesantes de reducir trabajo administrativo. Para otras será poco relevante a corto plazo. Y en muchas pondrá encima de la mesa un problema anterior: procesos que ya no reflejan el negocio, datos poco fiables o una adopción que sigue dependiendo de perseguir a los usuarios. Por eso la pregunta útil no es «¿necesitamos Headless 360?». Es esta: **¿qué trabajo necesita realmente una pantalla y qué trabajo solo necesita que Salesforce haga bien su parte por detrás?** Esa respuesta te dirá mucho mejor si hay algo que cambiar. --- ### Agentforce explicado: la inteligencia artificial dentro de Salesforce - URL: https://kaizenstep.com/blog/agentforce-explicado - Materia: Evolución de la plataforma - Publicado: 2025-02-27 Agentforce es la capa de agentes de inteligencia artificial de Salesforce. Esto es lo que hace de verdad, en qué se diferencia de las automatizaciones que ya tenías y qué cambia según si vendes, atiendes o administras la plataforma. En el ecosistema de Salesforce aparecen cada año tecnologías que se presentan como un cambio de era. La mayoría acaban siendo una función más. Agentforce es de las pocas que sí cambia la forma de trabajar con la plataforma, y conviene entender por qué antes de decidir si tiene sentido para tu organización. Este artículo lo explica sin tecnicismos: qué es, cómo funciona, qué no es y qué hace falta para ponerlo en marcha. #### ¿Qué es Agentforce? Agentforce es una capa de agentes basados en inteligencia artificial que trabaja dentro de Salesforce. Un agente entiende el contexto de tu trabajo, consulta los datos que ya tienes en la plataforma y ejecuta tareas, en lugar de limitarse a responder. La diferencia con las automatizaciones que probablemente ya tengas configuradas (flujos, reglas de asignación, alertas) es que aquellas siguen reglas escritas de antemano. Un agente decide sobre casos que nadie previó. Concretamente: - Interpreta peticiones escritas en lenguaje corriente, sin comandos ni pantallas específicas - Se apoya en los datos de tu organización: cuentas, oportunidades, casos, histórico de interacciones - Ejecuta acciones dentro de Salesforce, no solo devuelve texto - Opera dentro de los permisos del usuario en cuyo nombre actúa > **El límite importa tanto como la capacidad.** Un agente hereda el modelo de permisos de Salesforce. No ve más de lo que vería la persona que lo invoca, y eso es lo que hace que la conversación sobre seguridad sea distinta a la de una herramienta de IA genérica conectada por fuera. #### Qué cambia en el día a día según el rol El valor de Agentforce no se explica bien en abstracto. Cambia según quién lo use, así que vale la pena verlo por perfiles. ##### Equipo comercial - Resumen de cada cuenta antes de la visita, construido con el histórico real y no con lo que uno recuerde - Priorización de la cartera por probabilidad de cierre, con el criterio explícito y no como una caja negra - Borradores de correo de seguimiento a partir del contexto de la oportunidad, para revisar y enviar - Detección de oportunidades paradas: sin actividad registrada, sin próxima tarea, sin fecha de cierre creíble ##### Atención al cliente - Aviso temprano de casos con riesgo de escalado, según el patrón de casos anteriores - Respuesta a consultas frecuentes con el histórico de ese cliente delante - Propuesta de solución basada en casos similares ya resueltos, con el enlace al caso de origen - Resumen de la conversación al cerrar, que es lo que casi nunca se escribe bien ##### Administración y desarrollo - Localización de configuración duplicada o en desuso, que es el trabajo que siempre se aplaza - Generación de configuración y código a partir de un requisito descrito en lenguaje corriente - Documentación de los cambios, que en la mayoría de organizaciones no existe #### Cómo funciona Agentforce Por debajo hay tres piezas, y entenderlas ayuda a saber dónde se rompe la cosa cuando no funciona. 1. **Comprensión del lenguaje.** El agente interpreta una petición como «muéstrame los clientes que no han renovado este mes» sin que nadie tenga que traducirla a un informe. 2. **Acceso al dato y al contexto.** Consulta la información de tu organización: qué es cada cuenta, qué ha pasado antes, qué rol tiene quien pregunta. Aquí es donde la calidad del dato deja de ser un asunto teórico. 3. **Capacidad de acción.** Actualiza registros, crea tareas, envía correos o lanza un proceso. Es lo que separa a un agente de un asistente que solo conversa. El ciclo de trabajo es siempre el mismo: observa lo que ocurre, interpreta qué significa, decide qué acción procede, la ejecuta o la propone, y aprende del resultado. Donde tú decides es en el tercer y cuarto paso: cuánto puede hacer solo y qué tiene que pasar por una persona. #### Un ejemplo concreto Abres Salesforce por la mañana. El agente ha revisado tu agenda, tu correo y tus oportunidades abiertas, y te dice que tienes tres reuniones, que ha preparado las notas de cada una y que la oportunidad con una cuenta concreta lleva tres semanas sin comunicación registrada. Te pregunta si quieres un correo de seguimiento. Le dices que sí y que mencione el nuevo servicio. El agente revisa el histórico completo de esa cuenta, identifica qué parte de la oferta encaja con lo que ya compró, redacta el correo, te lo enseña antes de enviarlo y, una vez enviado, programa el recordatorio de seguimiento. Nada de esto es tecnología nueva por separado. Lo nuevo es que ocurra dentro del CRM, con los datos del CRM y respetando sus permisos. #### Lo que Agentforce no es Conviene ser explícito, porque buena parte de las expectativas mal puestas vienen de aquí. - No es un sistema nuevo que tu equipo tenga que aprender aparte: vive dentro de Salesforce - No toma decisiones críticas sin supervisión, salvo que se configure explícitamente así - No arregla un modelo de datos malo. Si el CRM no refleja la realidad, el agente tampoco - No sustituye a la definición del proceso: automatiza el proceso que le describas, bueno o malo > **El requisito previo del que poco se habla.** Un agente es tan bueno como los datos que lee. Si las oportunidades no están al día, si las cuentas están duplicadas o si media plantilla no registra actividad, Agentforce amplifica ese problema en lugar de resolverlo. Antes de un proyecto de IA suele tocar un trabajo de [adopción](/salesforce/adopcion) y de higiene de datos. #### Cómo se pone en marcha Un proyecto de Agentforce se parece bastante a cualquier otro proyecto sobre la plataforma, con una diferencia: hay que empezar acotando muy poco. 1. **Elegir uno o dos casos de uso** que resuelvan un problema medible y acotado. No una lista de veinte. 2. **Revisar el dato** que ese caso de uso necesita: dónde está, quién lo mantiene y en qué estado. 3. **Configurar el agente**: qué puede consultar, qué puede hacer solo y qué requiere aprobación. 4. **Formar a quien lo va a usar**, que casi nunca es quien lo configura. 5. **Medir y ajustar** con el uso real, que es donde aparecen los casos que nadie había previsto. El coste tiene dos partes que conviene separar en la conversación: el consumo de la propia plataforma y el trabajo de configurarla. La primera depende del volumen de uso; la segunda, del estado en que esté tu Salesforce hoy. #### Merece la pena si el CRM ya funciona Agentforce cambia la relación con Salesforce: de una herramienta que hay que dirigir a una que propone. Pero solo rinde sobre una instalación que ya refleja el negocio. En una que no, lo primero no es un agente, es una [auditoría](/salesforce/auditoria). --- ### Comprar un CRM: todo lo que debes tener en cuenta - URL: https://kaizenstep.com/blog/comprar-un-crm - Materia: Elegir CRM - Publicado: 2025-02-20 No existe un mejor CRM universal. Existe el que encaja con tus procesos, tu presupuesto y la capacidad de tu organización para adoptarlo. Este es el orden en que conviene mirar las cosas para llegar a esa decisión con criterio. Si estás valorando implantar un CRM, la dificultad no está en encontrar opciones: está en decidir entre demasiadas. Todas las demos son buenas y todas las herramientas hacen, sobre el papel, lo mismo. Lo que separa una buena decisión de una cara es el trabajo previo. Estos son los seis pasos, en el orden que importa. #### Por qué el orden importa Un CRM centraliza la información que hoy tienes repartida entre hojas de cálculo, correos y la cabeza de varias personas. Ese es el valor y también el riesgo: si eliges la herramienta antes de saber qué procesos vas a meter dentro, acabas adaptando la empresa al software en lugar de al revés. Por eso la selección empieza por dentro, no por el mercado. #### 1. Definir requisitos por departamento Antes de mirar ninguna herramienta, identifica qué áreas van a usarla y qué necesita cada una. No es lo mismo un CRM para un equipo comercial de cinco personas que uno que además tiene que dar servicio a marketing, a atención al cliente y a administración. - Ventas: gestión de cuentas y contactos, embudo, previsión, actividad - Marketing: captación, segmentación, campañas y su atribución al negocio cerrado - Atención al cliente: casos, canales de entrada, acuerdos de nivel de servicio - Operaciones y administración: pedidos, facturación, conexión con el ERP El objetivo de este paso no es hacer una lista de funcionalidades, es entender qué proceso real tiene que soportar cada área. Un requisito bien escrito describe una situación de trabajo, no una casilla. #### 2. Fijar un presupuesto preliminar Un presupuesto aproximado sirve sobre todo para descartar rápido. Y para descartar bien hay que contar las cuatro partidas, no solo la primera: - Licencias, según el modelo (suscripción por usuario, compra, código abierto) - Implantación: análisis, configuración, migración de datos e integraciones - Formación y acompañamiento durante la puesta en marcha - Mantenimiento y evolución posterior, que es el coste que casi nadie presupuesta > **El coste que se olvida.** La cuarta partida es la que decide si el proyecto envejece bien. Un CRM sin nadie que lo mantenga se degrada en dos años: campos que sobran, automatizaciones que ya no aplican y un equipo que vuelve a la hoja de cálculo. Conviene decidir desde el principio si eso lo lleva alguien interno o [se externaliza](/salesforce/gestion). #### 3. Evaluar herramientas contra tus requisitos Ahora sí, el mercado. Salesforce, Microsoft Dynamics, HubSpot, Zoho, Odoo y unas cuantas más. Pide una presentación inicial a cada proveedor, pero con una condición: que la demo la hagan sobre tus requisitos, no sobre el guion de demo que tienen preparado. Preguntas que separan una demo útil de una bonita: - Enséñame cómo se resuelve este caso concreto de mi proceso, no uno parecido - Qué parte de esto es configuración y qué parte es desarrollo a medida - Qué pasa cuando cambie este proceso dentro de dos años: quién lo toca y con qué coste - Cómo se conecta con nuestro ERP y quién mantiene esa conexión #### 4. Priorizar los requisitos Después de las presentaciones tendrás una lista larga y la sensación de que ninguna herramienta lo cubre todo. Es lo normal. Toca ordenar: qué es imprescindible, qué es deseable y qué es una preferencia personal de alguien. Un requisito imprescindible es aquel sin el cual el proceso no se puede ejecutar. Suelen ser muchos menos de los que parecen al empezar. #### 5. Solicitud de información (RFI) Con los requisitos priorizados, una solicitud de información escrita obliga a los proveedores a responder por escrito y comparable. Es también la forma de que las respuestas dejen de ser conversaciones y pasen a ser compromisos. En la solicitud conviene incluir el escenario completo, no la función suelta: «cómo se gestiona la relación con un cliente desde la primera visita hasta la renovación» dice mucho más que «tiene gestión de contactos». #### 6. Negociación y decisión En la última fase, asegúrate de tener el coste completo a tres años, no el precio de las licencias del primer año. Y de saber qué incluye exactamente el alcance de la implantación: qué procesos, cuántas integraciones y qué pasa con lo que aparezca por el camino. > No hay un mejor CRM. Hay uno que encaja con cómo trabajáis y con lo que estáis dispuestos a cambiar de cómo trabajáis. #### Dónde falla habitualmente esta decisión - Elegir por funcionalidades comparadas en una tabla, sin haber definido el proceso que van a soportar - Presupuestar solo las licencias y descubrir la implantación después - No decidir quién será el responsable interno del sistema una vez arranque - Dejar la adopción del equipo para el final, cuando es lo que determina si el proyecto sirve de algo El último punto es el más caro de todos. Un CRM que el equipo no usa no es un CRM: es una base de datos incompleta que sirve para tomar decisiones equivocadas con la confianza de tenerlas fundamentadas. --- ### ¿Dónde va Salesforce? La estrategia de Salesforce en sus adquisiciones - URL: https://kaizenstep.com/blog/estrategia-adquisiciones-salesforce - Materia: Evolución de la plataforma - Publicado: 2022-12-06 Salesforce ha comprado 71 empresas entre 1999 y 2022. No todas por el mismo motivo: hay cuatro tipos de compra distintos, y el tipo que predomina en cada momento dice bastante sobre en qué fase estaba la compañía y hacia dónde iba la plataforma. Hace unos años se filtró un documento con la lista de posibles objetivos de adquisición del departamento de fusiones y adquisiciones de Salesforce. En ella aparecían nombres como Adobe, LinkedIn, HubSpot o Zendesk. De aquella lista de 2016, algunas se compraron efectivamente (Demandware, por ejemplo); la mayoría no. Lo interesante no es la lista, sino lo que revela del criterio. Salesforce no compra empresas por un solo motivo, y clasificarlas por su motivo explica bastante mejor la evolución de la plataforma que ordenarlas por importe. #### De sistema de fuerza de ventas a plataforma En 1999 Salesforce era un sistema de gestión de la fuerza de ventas y poco más. Hoy es una plataforma que cubre marketing, servicio, comercio, integración, analítica, colaboración y verticales de industria. Ese recorrido se ha hecho en parte con desarrollo propio y en gran parte comprando. Las dos adquisiciones más sonadas dan la escala: Slack, anunciada en 2020 y cerrada en 2021, por 27.700 millones de dólares, y Tableau en 2019 por 15.700 millones. #### Los cuatro motivos por los que Salesforce compra Repasando las 71 operaciones, se pueden clasificar en cuatro tipos según el objetivo. ##### 1. Para captar talento Sobre todo en los primeros años. El activo que se compraba eran las personas, no el producto: en la mayoría de estos casos el producto se cerró a las pocas semanas de firmar. - **Clipboard**, una herramienta de marcadores comprada en 2013 por 20 millones de dólares y cerrada un mes después - **Thinkfuse**, de informes de progreso, comprada en junio de 2012 y cerrada en julio del mismo año - **Tempo AI**, una aplicación de calendario comprada en 2015 y cerrada también al mes Este tipo de operación va normalmente ligada a cláusulas de permanencia del equipo que se compra. ##### 2. Para completar tecnología Cuando la funcionalidad de un área no era competitiva, Salesforce ha comprado la tecnología y la ha incorporado a sus propias soluciones. Aquí el producto sí sobrevive, pero absorbido: normalmente se reescribe sobre la plataforma nativa cuando llega el momento. - **InStranet** (2008, 31,5 M$), gestión del conocimiento para Service Cloud - **MetaMind** (2016, 32,8 M$), **PredictionIO** (2016) y **Bonobo AI** (2019), la base de lo que sería Einstein - **BeyondCore** (2016, 110 M$), analítica ##### 3. Para mejorar clouds existentes Compras que amplían la funcionalidad de una solución que ya existe y que en su mayoría acaban convertidas en complementos de pago, a veces manteniendo su marca durante un tiempo. - **ClickSoftware** (2019, 1,35 mil M$), que aporta Field Service a Service Cloud - **SteelBrick** (2015, 360 M$), que añade el cotizador CPQ a Sales Cloud - **Datorama** (2018, 800 M$), inteligencia de negocio para Marketing Cloud ##### 4. Para abrir clouds nuevos Las compras grandes. Cada una abre un mercado nuevo con una solución ya líder y con una cartera de clientes de referencia que sirve de palanca para el resto del catálogo. - **MuleSoft** (2018, 6,5 mil M$), integración - **ExactTarget** (2013, 2,5 mil M$), marketing - **Tableau** (2019, 15,7 mil M$), analítica - **Vlocity** (2020, 1,33 mil M$), verticales de industria - **Demandware** (2016, 2,8 mil M$), comercio B2C - **CloudCraze** (2018), comercio B2B #### El tipo de compra sigue a la fase de la empresa Puestas en orden cronológico, las cuatro categorías no se mezclan al azar: hay una correspondencia bastante clara con el momento de crecimiento en el que estaba Salesforce. 1. **Primeros años:** adquisiciones para captar talento, cuando lo escaso era gente que supiera construir software en la nube. 2. **Crecimiento sostenido:** compras de tecnología y de mejora de clouds existentes, para tapar huecos de funcionalidad frente a la competencia. 3. **Madurez:** compras que abren líneas de negocio nuevas, que es lo que permite seguir creciendo cuando el mercado original empieza a saturarse. #### Qué significa esto para quien usa Salesforce Somos partner de Salesforce desde 2011, así que esta lectura está sesgada. Pero hay dos consecuencias prácticas que se notan en el trabajo del día a día. La primera es la especialización. Cuando empezamos, un consultor podía conocer Salesforce entero. Hoy es materialmente imposible: la amplitud de la plataforma obliga a perfiles distintos (funcional de CRM, marketing automation, desarrollo, arquitectura) y eso cambia cómo se monta un equipo de proyecto. La segunda es la paquetización, que es la estrategia que Microsoft lleva décadas ejecutando con Office. A una empresa industrial a la que antes solo se le podía ofrecer Sales Cloud, hoy se le puede ofrecer comercio B2B, colaboración, servicio con despliegue de técnicos, cotizador e inteligencia de negocio. De una licencia a ocho o diez. > Salesforce ha pasado de vender un CRM a vender un catálogo. Eso da mucha capacidad de negociación al proveedor y hace más importante decidir bien qué se compra de verdad. Para el cliente esto tiene una cara buena (un ecosistema que se integra entre sí sin proyecto de integración) y una que conviene vigilar: la revisión periódica de qué licencias se están pagando y cuáles se usan de verdad, que es uno de los ámbitos que revisamos en una [auditoría](/salesforce/auditoria). #### Las 71 adquisiciones de Salesforce (1999-2022) La lista completa, con el importe cuando se hizo público. Los datos son los recogidos en el momento de publicar el artículo, en diciembre de 2022. | Año | Empresa | País | Importe | | --- | --- | --- | --- | | 2006 | Sendia | EE. UU. | No revelado | | 2006 | Kieden | EE. UU. | No revelado | | 2007 | Koral Technologies | EE. UU. | No revelado | | 2008 | InStranet | EE. UU. | 31,5 M$ | | 2009 | GroupSwim | EE. UU. | 7 M$ | | 2009 | Informavores | Reino Unido | No revelado | | 2010 | Jigsaw | EE. UU. | No revelado | | 2010 | Sitemasher | Canadá | No revelado | | 2010 | Activa Live | EE. UU. | No revelado | | 2010 | Heroku | EE. UU. | No revelado | | 2010 | Etacts | EE. UU. | No revelado | | 2011 | Dimdim | EE. UU. | No revelado | | 2011 | Manymoon | EE. UU. | No revelado | | 2011 | Radian6 | Canadá | No revelado | | 2011 | Zorap | EE. UU. | No revelado | | 2011 | Navajo Systems | Israel | No revelado | | 2011 | Desk.com | EE. UU. | No revelado | | 2011 | Model Metrics | EE. UU. | No revelado | | 2011 | Work.com | Canadá | No revelado | | 2012 | Stypi | EE. UU. | No revelado | | 2012 | Buddy Media | EE. UU. | 649 M$ | | 2012 | ChoicePass | EE. UU. | No revelado | | 2012 | Thinkfuse | EE. UU. | No revelado | | 2012 | GoInstant | Canadá | 70 M$ | | 2012 | Prior Knowledge | EE. UU. | No revelado | | 2013 | EntropySoft | Francia | No revelado | | 2013 | Clipboard | EE. UU. | 20 M$ | | 2013 | ExactTarget | EE. UU. | 2,5 mil M$ | | 2013 | EdgeSpring | EE. UU. | No revelado | | 2013 | Cloud Connect | EE. UU. | No revelado | | 2014 | RelateIQ | EE. UU. | No revelado | | 2015 | Toopher | EE. UU. | No revelado | | 2015 | Tempo AI | EE. UU. | No revelado | | 2015 | Kerensen Consulting | Francia | 24,2 M$ | | 2015 | AKTA | EE. UU. | No revelado | | 2015 | MinHash | EE. UU. | No revelado | | 2015 | SteelBrick | EE. UU. | 360 M$ | | 2016 | YOUR SL | Alemania | No revelado | | 2016 | PredictionIO | EE. UU. | No revelado | | 2016 | MetaMind | EE. UU. | 32,8 M$ | | 2016 | Implisit | EE. UU. | No revelado | | 2016 | Demandware | EE. UU. | 2,8 mil M$ | | 2016 | Coolan | EE. UU. | No revelado | | 2016 | Quip | EE. UU. | 750 M$ | | 2016 | BeyondCore | EE. UU. | 110 M$ | | 2016 | HeyWire | EE. UU. | No revelado | | 2016 | gravitytank | EE. UU. | No revelado | | 2016 | Krux | EE. UU. | 800 M$ | | 2016 | Twin Prime | EE. UU. | No revelado | | 2017 | Sequence | EE. UU. | No revelado | | 2018 | Attic Labs | EE. UU. | No revelado | | 2018 | CloudCraze | EE. UU. | No revelado | | 2018 | MuleSoft | EE. UU. | 6,5 mil M$ | | 2018 | Datorama | EE. UU. | 800 M$ | | 2018 | Rebel | EE. UU. | No revelado | | 2019 | Griddable | EE. UU. | No revelado | | 2019 | Salesforce Foundation | EE. UU. | 300 M$ | | 2019 | MapAnything | EE. UU. | 213 M$ | | 2019 | Bonobo AI | Israel | No revelado | | 2019 | Tableau | EE. UU. | 15,7 mil M$ | | 2019 | ClickSoftware Technologies | EE. UU. | 1,35 mil M$ | | 2020 | Evergage | EE. UU. | No revelado | | 2020 | Vlocity | EE. UU. | 1,33 mil M$ | | 2020 | The CMO Club | EE. UU. | No revelado | | 2020 | Mobify | Canadá | 60 M$ | | 2020 | Acumen Solutions | EE. UU. | No revelado | | 2020 | Slack | EE. UU. | 27,7 mil M$ | | 2021 | LevelJump | Canadá | No revelado | | 2022 | Atonit | Brasil | No revelado | | 2022 | Troops | EE. UU. | No revelado | | 2022 | Phennecs | EE. UU. | No revelado | --- ### Salesforce: 7 puntos clave que todo CxO necesita saber - URL: https://kaizenstep.com/blog/siete-puntos-clave-cxo - Materia: Elegir CRM - Publicado: 2022-11-23 El éxito de una implantación de Salesforce no se decide en la configuración. Se decide en si los datos que entran son veraces y en si la dirección se atreve a decidir con ellos. Siete cosas que conviene tener claras desde la dirección. Salesforce es una plataforma flexible y con mucha capacidad de automatización. Pero desde la dirección conviene entender que ninguna de esas dos cosas determina si el proyecto sale bien. Lo que lo determina es si el sistema acaba reflejando la realidad del negocio. Y eso depende de las personas, no del software. #### 1. La adopción del usuario lo es todo Cada usuario aporta los datos que hacen falta para tener una visión fiable del cliente. Cuantos más usuarios registran, más completa es la visión. Cuantos menos, más se parece el sistema a una muestra sesgada de la realidad. Este es el punto del que dependen los seis siguientes. Un CRM con la mitad de la actividad sin registrar no es un CRM a medias: es un CRM que induce a decisiones equivocadas con apariencia de estar fundamentadas. #### 2. Como directivo tienes dos palancas: lo que dices y lo que haces Cuando la dirección consulta el sistema antes de pedir un informe, la organización entiende que el sistema es la fuente. Cuando lo que se pide por correo es un Excel, la organización entiende exactamente lo contrario. - Usa los datos del sistema en las reuniones, y hazlo de forma visible - No aceptes previsiones que llegan por otro canal: si no está en el sistema, no existe - Reconoce a los primeros que lo usan bien, que son quienes marcan la norma para el resto #### 3. La calidad del dato es un problema de dirección Datos duplicados, registros incompletos y entradas perdidas destruyen la credibilidad del sistema mucho más rápido de lo que cualquier formación la construye. Y con la del sistema, la de quien lo ha impulsado. Los proyectos de migración, integración y automatización de datos no son la parte prescindible del presupuesto: son lo que impide que entre dato malo en origen. Recortarlos ahí es lo que más caro sale después. > **La prueba del algodón.** Si para preparar el comité alguien tiene que exportar, cruzar y limpiar a mano, el sistema no es la fuente de verdad todavía, independientemente de lo bien configurado que esté. #### 4. El beneficio principal es la visibilidad Una visión completa del cliente no solo te dice qué está pasando: te da señales tempranas de lo que va a pasar. Desviaciones en la previsión, cartera que se estanca, cuentas que dejan de comprar sin que nadie lo haya notado. Es la diferencia entre enterarte de un problema en el cierre de trimestre y enterarte cuando todavía se puede hacer algo. #### 5. El objetivo es gestionar por excepción Gestionar por excepción significa que solo intervienes cuando hay una desviación significativa respecto a lo planificado. Es la única forma de que la dirección escale sin multiplicar reuniones de seguimiento. Para llegar ahí hacen falta tres cosas: objetivos realistas, indicadores que midan lo que de verdad importa y alertas configuradas sobre esos indicadores. Las tres se apoyan en el punto 3. #### 6. El CRM es la base del análisis estratégico Quiénes son tus clientes más rentables y por qué. Dónde conviene invertir más y dónde menos. Por qué te eligen. Sin un histórico de compra y de comportamiento en un solo sitio, las respuestas a esas preguntas son intuiciones. Con él, dejan de serlo. Ese es el retorno que justifica el proyecto a nivel de dirección, más que el ahorro de tiempo administrativo. #### 7. El mensaje con el que se presenta condiciona el resultado Los sistemas de CRM llegan con carga política. Si el equipo entiende que el objetivo es controlarlo, el proyecto se resiente antes de arrancar: nadie pide ser monitorizado. La misma capacidad se puede contar de dos maneras, y no dan el mismo resultado: | En vez de decir | Di | | --- | --- | | Más control del rendimiento | Menos tiempo perdido en tareas que no venden | | Gestión más rigurosa | Clientes mejor atendidos | | Automatización | Menos trabajo repetido | | Eliminación de trabajo | Procesos que dejan de estorbar | | Un sistema completo | Todo en un sitio, sin buscar en cinco | El mensaje tiene que ser que el sistema sirve para que la empresa vaya coordinada. Si el equipo percibe que va a servir para repartir culpas, el sistema acaba saboteado, y el sabotaje de un CRM es silencioso: simplemente no se registra nada. #### Y una recomendación de cierre: cuenta lo que funciona Compartir los casos concretos en los que el sistema ha servido para algo (una cuenta recuperada, una previsión que se cumplió, un cliente atendido mejor) hace más por la adopción que cualquier plan de formación. --- ### KPIs clave para medir la adopción de Salesforce - URL: https://kaizenstep.com/blog/kpis-adopcion-salesforce - Materia: Adopción y uso - Publicado: 2022-09-03 Que los usuarios entren en Salesforce no significa que Salesforce esté adoptado. Puedes tener muchos logins y seguir preparando el forecast en Excel, encontrar oportunidades sin actualizar o descubrir que cada comercial utiliza el CRM de una forma distinta. Para saber si Salesforce forma parte realmente del trabajo diario, necesitas medir algo más que el acceso al sistema. Los KPIs de adopción deberían ayudarte a responder tres preguntas: **¿se utiliza Salesforce?, ¿se utiliza con información fiable? y ¿se utiliza para ejecutar el proceso que la empresa necesita?** #### Antes de medir la adopción de Salesforce, define qué significa «adoptar» Un porcentaje de adopción aislado dice bastante poco. Imagina dos equipos comerciales. En el primero, casi todo el mundo entra en Salesforce cada día. Sin embargo, las oportunidades se actualizan justo antes de la reunión semanal y el forecast se termina corrigiendo en una hoja de cálculo. En el segundo, quizá los usuarios no pasan todo el día dentro del CRM, pero mantienen al día las oportunidades relevantes, registran el siguiente paso y los responsables utilizan esos datos para gestionar el pipeline. ¿Cuál tiene una mejor adopción? Probablemente el segundo. **La adopción de Salesforce no consiste en utilizar mucho Salesforce. Consiste en utilizarlo de forma consistente para hacer el trabajo que debería hacerse en Salesforce.** Por eso, antes de montar un dashboard de adopción, debes definir qué comportamientos son importantes para cada equipo. #### ¿Por qué no basta con medir logins? El login es un indicador sencillo y puede detectar situaciones extremas. Si una persona que debería trabajar habitualmente con Salesforce lleva semanas sin entrar, hay una señal evidente. Pero entrar no significa utilizar bien el sistema. Un usuario puede acceder cada mañana y seguir gestionando sus oportunidades en Excel. Puede registrar actividades sin mantener actualizado el pipeline. O puede completar campos simplemente porque son obligatorios, aunque la información no resulte útil para nadie. El problema aparece cuando confundimos **actividad dentro del sistema** con **adopción del proceso**. Por eso conviene combinar diferentes tipos de indicadores. #### Los tres tipos de KPIs que conviene combinar | Qué quieres medir | Ejemplos de señales | Qué puede estar indicando | | --- | --- | --- | | Uso | Usuarios activos, frecuencia, funciones propias del rol | Si Salesforce está presente en el trabajo habitual | | Calidad de los datos | Sin próximo paso, fechas vencidas, registros sin actualizar | Si la información puede utilizarse para gestionar | | Adopción del proceso | Oportunidades al día, fases coherentes, hitos registrados | Si Salesforce refleja cómo trabaja la organización | Ninguno de estos grupos funciona bien por separado. Mucho uso con datos malos no es buena adopción. Datos aparentemente completos que nadie utiliza para tomar decisiones tampoco. Y exigir que se complete todo puede conseguir exactamente lo contrario: más trabajo administrativo y menos confianza en Salesforce. #### 1. KPIs de uso: ¿el equipo utiliza Salesforce de forma habitual? Los indicadores de uso son el punto de partida, no el resultado final. Pueden ayudarte a detectar equipos que prácticamente han abandonado Salesforce o diferencias importantes entre usuarios que, en teoría, deberían trabajar de una manera similar. Pero la pregunta útil no es «¿cuántas veces ha entrado este comercial?». Es **«¿está utilizando Salesforce cuando el proceso comercial lo necesita?»**. Por ejemplo, si una oportunidad importante avanza después de una reunión con el cliente, lo relevante no es que el vendedor haya abierto Salesforce ese día. Lo relevante es que el pipeline refleje qué ha ocurrido y cuál es el siguiente paso. La frecuencia de uso debe interpretarse siempre en función del rol y del proceso. #### 2. KPIs de calidad de datos: ¿puedes confiar en lo que ves? Aquí aparece uno de los síntomas más visibles de una adopción débil. Dirección abre el pipeline y encuentra oportunidades con fechas de cierre pasadas. Faltan siguientes pasos. Hay operaciones que llevan semanas en la misma fase. Algunos comerciales actualizan Salesforce continuamente y otros únicamente antes de la reunión de forecast. El problema ya no es si las personas entran. El problema es si **Salesforce representa lo que realmente está ocurriendo**. Algunas señales útiles son las oportunidades sin próximo paso, las fechas de cierre vencidas, los registros relevantes sin actualizar o los datos necesarios para gestionar que sistemáticamente aparecen incompletos. No se trata de perseguir el 100 % de campos cumplimentados. Un campo que nadie necesita no mejora por estar completo. La calidad debe medirse sobre la información que realmente permite vender, atender al cliente o dirigir el negocio. #### 3. KPIs de proceso: ¿Salesforce refleja cómo trabaja el equipo? Este es normalmente el nivel más interesante. Salesforce puede contener información correcta y, aun así, no estar integrado en el proceso real. Un comercial puede gestionar una operación importante en llamadas, correos y Excel y actualizarla en Salesforce cuando alguien se lo pide. Técnicamente existe el registro. Operativamente, Salesforce ha llegado tarde. Los KPIs de proceso deben analizar los comportamientos que hacen que el CRM sea útil: - Cuándo se actualiza una oportunidad, no solo si acaba actualizada. - Si las fases representan decisiones reales o solo el paso del tiempo. - Si existe un siguiente paso y tiene sentido. - Si el proceso se sigue de forma consistente entre equipos. - Si los responsables pueden gestionar con la información disponible. Aquí es donde la medición empieza a explicar de verdad la adopción. #### ¿Qué características tiene un buen KPI de adopción? Un buen KPI debe estar ligado a un comportamiento que importe para el negocio y sobre el que puedas actuar. «95 % de usuarios activos» puede sonar bien y no decir prácticamente nada. En cambio, descubrir que una parte importante del pipeline llega a la reunión comercial sin siguiente paso obliga a hacer preguntas mucho más interesantes. - ¿El equipo no entiende qué debe actualizar? - ¿Actualizar Salesforce requiere demasiado trabajo? - ¿El concepto de «siguiente paso» no está claro? - ¿El manager no utiliza esa información? - ¿El proceso configurado ya no coincide con la forma actual de vender? > La métrica útil no es la que produce el número más bonito. Es la que ayuda a encontrar el problema que hay detrás. #### Cuidado con convertir la adopción en un sistema de vigilancia Hay una forma bastante rápida de conseguir que un equipo desconfíe de Salesforce: utilizar cada métrica para controlar al usuario. Si los KPIs solo sirven para preguntar quién no ha rellenado un campo o quién no ha entrado suficientes veces, probablemente conseguirás más actividad. Eso no significa necesariamente que consigas mejores datos. Las métricas deberían permitir detectar fricción. Si diez comerciales diferentes dejan sistemáticamente vacío el mismo dato, puede que no tengas diez usuarios indisciplinados. Puede que tengas un campo mal planteado. Si las oportunidades solo se actualizan los viernes antes de la reunión de pipeline, quizá el problema no sea que los usuarios se olviden. Quizá Salesforce no les aporta suficiente valor durante el resto de la semana. Medir adopción sirve también para cuestionar el propio sistema. #### ¿Cuándo deberías medir la adopción? No debería ser una comprobación que se realiza únicamente meses después de una implantación. Hay tres momentos especialmente útiles. ##### Durante un proyecto o cambio importante Para detectar pronto si el proceso diseñado se entiende y se puede ejecutar de forma razonable. ##### Después de la puesta en marcha Para comprobar qué comportamientos se han consolidado y dónde aparecen atajos, Excel paralelos o diferencias entre equipos. ##### De forma periódica Porque el negocio cambia. Un Salesforce que encajaba hace tres años puede haberse quedado atrás respecto al proceso comercial actual. Por eso la adopción tampoco es un proyecto con una fecha definitiva de finalización. #### ¿Qué pasa si los KPIs muestran una adopción baja? El siguiente error sería asumir automáticamente que hace falta más formación. A veces es así. Pero una adopción baja también puede tener su origen en un proceso mal definido, demasiada carga manual, una configuración que ya no encaja, datos poco fiables, responsabilidades ambiguas, falta de utilidad para el usuario o una forma de gestionar que sigue ocurriendo fuera del CRM. > **Formación y adopción no son lo mismo.** La formación responde a si el equipo sabe utilizar Salesforce. La adopción responde a si Salesforce forma parte realmente de su manera habitual de trabajar. Si las personas saben utilizar el sistema pero continúan trabajando fuera, la [formación Salesforce](/salesforce/formacion) no es la palanca: el problema está en otro sitio. #### Entonces, ¿qué deberías mirar primero? No empezaría creando veinte KPIs. Empezaría identificando dos o tres comportamientos sin los cuales Salesforce no puede cumplir su función. En un equipo comercial podría ser que las oportunidades activas tengan una fase realista, una fecha razonable y un siguiente paso. Después comprobaría si esos comportamientos ocurren. Y, sobre todo, investigaría por qué no ocurren cuando fallan. Ese es el cambio importante: **utilizar los KPIs de adopción como herramienta de diagnóstico, no como marcador de cumplimiento.** Cuando entiendes dónde está la fricción, ya puedes decidir si necesitas trabajar sobre configuración, proceso, datos, formación, gestión del cambio o una [evolución más profunda de Salesforce](/salesforce/evolucion). Y si lo que sale del diagnóstico es que el sistema no forma parte de la forma de trabajar, ese es el punto por el que se empieza a [mejorar la adopción de Salesforce](/salesforce/adopcion). #### Preguntas frecuentes **¿Cuál es el KPI más importante para medir la adopción de Salesforce?** No existe un único KPI válido para todas las empresas. El indicador útil es el que mide un comportamiento necesario para que Salesforce cumpla su función en un proceso concreto. Por eso conviene combinar uso, calidad de datos y adopción del proceso. **¿El número de logins sirve para medir la adopción?** Sirve como señal básica, pero no demuestra adopción. Un usuario puede entrar frecuentemente en Salesforce y continuar gestionando partes importantes de su trabajo fuera del sistema, en hojas de cálculo, correo o llamadas que nunca se registran. **¿Una mala calidad de datos significa que existe un problema de adopción?** Puede ser una señal, pero hace falta investigar la causa. La información incompleta en Salesforce puede deberse a falta de uso, pero también a campos innecesarios, procesos mal definidos, exceso de trabajo manual o una configuración que ya no refleja el negocio. **¿Más formación mejora la adopción de Salesforce?** Puede ayudar cuando el problema es de conocimiento. Si el equipo ya sabe utilizar Salesforce pero continúa recurriendo a Excel o evitando determinadas partes del proceso, será necesario analizar otras causas: proceso, configuración, calidad del dato o utilidad real para el usuario. --- ### 12 buenas prácticas para la gestión de equipos comerciales - URL: https://kaizenstep.com/blog/gestion-equipos-comerciales - Materia: Adopción y uso - Publicado: 2022-09-01 La vía más rápida para mejorar los resultados de un equipo de ventas no suele ser cambiar el equipo: es cambiar cómo se gestiona. Doce prácticas que comparten las direcciones comerciales que obtienen resultados por encima de la media. Una dirección comercial está en una posición única para influir en el rendimiento de su equipo. Pero es también una posición que se llena sola de urgencias, y acaba dedicada a resolver lo que va surgiendo en lugar de a desarrollar al equipo. El impacto de esa función se concentra en tres áreas: **alineamiento**, **motivación** y **rendimiento**. Estas doce prácticas son las que hemos visto repetirse en las organizaciones de ventas que funcionan mejor. #### 1. Gestionar, no solo monitorizar Muchos equipos comerciales están muy monitorizados y poco gestionados: la dirección se apoya en indicadores y plazos para empujar el rendimiento, y ahí se acaba la intervención. Gestionar es llegar a cada persona y encontrar qué la mueve, que no es lo mismo para todos. #### 2. Compartir la información Los objetivos, su seguimiento y su consecución funcionan mucho mejor cuando son visibles para todo el equipo que cuando cada uno conoce solo los suyos. Un cuadro de mando compartido y actualizado en tiempo real hace ese trabajo sin que nadie tenga que preparar nada. #### 3. Contratar bien antes que formar mucho Contratar por encima ahorra tiempo y dinero en formación, y evita las salidas de los primeros meses. Busca gente que encaje con el equipo y con la organización, y no fiches esperando que alguien que a priori no encaja acabe adaptándose. El coste de un comercial es relativo: la pregunta no es cuánto cuesta, es cuánto cuesta uno que no vende. #### 4. Marcar un ritmo y sostenerlo Un equipo comercial rinde cuando hay un ritmo definido y se respeta. Reuniones periódicas, en su día y a su hora, y la dirección la primera en cumplirlas. La condición para que ese ritmo no consuma tiempo de venta es que la información esté siempre disponible y actualizada sin trabajo administrativo extra. Si preparar la reunión semanal cuesta media mañana a cada comercial, el ritmo está saliendo del tiempo con cliente. #### 5. Objetivos claros y medibles No hay nada más importante para un comercial que saber exactamente qué se espera de él y cómo lo está haciendo. Objetivos bien definidos y medibles eliminan la mitad de las conversaciones difíciles antes de que ocurran. #### 6. Distinguir el plan de la previsión Son dos cosas distintas y se confunden con frecuencia: - **La previsión** se centra en el negocio que ya está en fase avanzada. Sirve para comprometer el trimestre - **El plan** se centra en el desarrollo futuro de negocio. Es lo que determina las previsiones de dentro de dos trimestres Cuando le señalas a un comercial si lo que está haciendo incide en el plan o en la previsión, entiende mucho mejor qué se le está pidiendo. #### 7. Proceso: ni de más ni de menos Todo equipo trabaja dentro de un proceso que define cómo se aborda, se cualifica y se cierra. Eso es bueno. Pero un proceso demasiado reglamentado ata las manos y confunde: el detalle tiene un punto a partir del cual resta. La alternativa a más proceso es mejor seguimiento: si ves el desarrollo en tiempo real, puedes ajustar en plazos cortos y dar más margen al equipo. #### 8. Hacer coaching de forma continua Es la responsabilidad que más se descuida, porque exige sacar tiempo de una agenda que ya está llena. Y es la que construye antes la confianza del equipo. Las direcciones que lo hacen bien aprovechan cada ocasión, programada o no, en lugar de reservarlo a una sesión trimestral. #### 9. Gestionar a los mejores Los perfiles más competitivos son también los más difíciles de dirigir. Saber cómo motivarlos y reconocerlos maximiza su rendimiento y reduce los conflictos con el resto. Y hay una segunda oportunidad ahí: usar el éxito de quien va primero para tirar del resto, de forma que el resultado individual se convierta en resultado de equipo. #### 10. Detectar los patrones antes de que sean problemas Las mejores direcciones comerciales reconocen las señales pequeñas antes de que se conviertan en desviaciones grandes: un cambio leve en el rendimiento de alguien que, mirado suelto, todavía parece un resultado aceptable. Intervenir ahí evita que se consoliden malos hábitos que después cuestan un año de resultados. #### 11. Proteger su tiempo y el del equipo No se vende sin pasar tiempo con clientes. Todo lo que no contribuye directamente a eso debería estar en revisión permanente: eliminarlo, automatizarlo o hacerlo en menos pasos. Con objetivos claros, evaluar si una actividad merece el tiempo que ocupa se vuelve una decisión rápida. #### 12. Celebrar lo que se gana Debería explicarse solo, y sin embargo es lo que más se aplaza. Reconocer las victorias (también las pequeñas) con frecuencia es la forma más barata de bajar la presión y mantener el impulso. > Las tres áreas donde una dirección comercial concentra su impacto son alineamiento, motivación y rendimiento. Las doce prácticas se reparten entre ellas; ninguna funciona sola. #### Dónde entra aquí el CRM Buena parte de estas prácticas dependen de tener el dato disponible sin trabajo adicional: el ritmo del punto 4, los objetivos visibles del 2, el seguimiento en tiempo real del 7 y la detección temprana del 10. Un CRM bien montado no dirige el equipo, pero es lo que hace que dirigirlo no consuma el tiempo de venta. Cómo se consigue eso lo desarrollamos en [adopción](/salesforce/adopcion) y en [evolución](/salesforce/evolucion). --- ## Resto del sitio ### Servicios sobre un Salesforce en marcha - [Auditoría de Salesforce](https://kaizenstep.com/salesforce/auditoria): Los ocho ámbitos que se revisan en una auditoría (procesos, modelo y calidad de datos, automatizaciones, integraciones, permisos, licencias, adopción e informes), las seis situaciones en que tiene sentido y qué incluye el entregable. - [Evolución y optimización](https://kaizenstep.com/salesforce/evolucion): Los seis tipos de trabajo evolutivo sobre una organización ya en producción y el criterio para distinguirlos: modelado de procesos nuevos, automatización, simplificación, capacidades nuevas del producto, datos e informes, y deuda de configuración. - [Integraciones](https://kaizenstep.com/salesforce/integraciones): Sistemas que se conectan habitualmente con Salesforce (ERP, ecommerce, PMS, facturación, catálogo) y las cuatro decisiones previas a construir: quién es el dueño de cada dato, dirección y latencia, comportamiento ante error y coste de mantenimiento. - [Adopción](https://kaizenstep.com/salesforce/adopcion): Seis causas concretas por las que un equipo no usa el CRM, el método de diagnóstico y seis indicadores de adopción medibles dentro de Salesforce. - [Formación](https://kaizenstep.com/salesforce/formacion): Formación por rol sobre la propia configuración del cliente, y el programa de seis jornadas para direcciones de ventas (campos y objetos, lógica de negocio, informes, automatización, migración e integración, certificación). - [Administración y gestión](https://kaizenstep.com/salesforce/gestion): Administración externalizada: peticiones del día a día, mantenimiento preventivo, gestión de las tres versiones anuales de plataforma, higiene de datos y documentación. Modelo de suscripción, no bolsa de horas. ### Proyectos nuevos - [Implementación de Salesforce](https://kaizenstep.com/salesforce/implementacion): Primera implementación y proyecto nuevo sobre una organización existente, con las seis fases del proyecto, los productos de plataforma que suelen entrar y cuatro errores de gestión frecuentes. ### Kaizen como partner - [Consultoría Salesforce](https://kaizenstep.com/salesforce/consultoria): Página índice del catálogo por sus dos ejes. Por tipo de servicio: las dos vías de entrada según si Salesforce está o no en marcha y los seis servicios. Por producto: enlaza las ocho páginas de producto, que cuelgan de esta misma URL en /salesforce/consultoria/. Además, los diferenciadores de Kaizen y doce proyectos de referencia. - [Partner Salesforce](https://kaizenstep.com/salesforce/partner): Qué debería aportar una buena relación con un partner de Salesforce, cuatro preguntas que conviene hacer antes de elegirlo y cómo replantear la relación cuando cambian las necesidades del negocio. Partner desde 2011. - [Consultoría Salesforce en Barcelona](https://kaizenstep.com/salesforce/barcelona): La presencia local: oficina en Barcelona, qué aporta la proximidad en descubrimiento, adopción y formación, los cinco casos con sede en la provincia y las piezas de plataforma que aparecen en ellos (Data Cloud, Marketing Cloud, Sales Cloud, MuleSoft, Service Cloud y Agentforce). Responde también dónde está la oficina, la mezcla de presencial y remoto, y la diferencia entre Marketing Cloud y Account Engagement. ### Sectores - [Salesforce para fabricantes industriales](https://kaizenstep.com/salesforce/manufacturing): Canal de distribución y prescripción, ciclo largo de obra y proyecto, cotizador por configuración, integración con el ERP y servicio técnico. Seis fabricantes de referencia: Simon, Verdés, Dagartech, Recasens, Abus Grúas y Rigual. - [Salesforce para Hospitality](https://kaizenstep.com/salesforce/hoteles): Cadenas hoteleras: ficha única de huésped conectada al PMS, marketing, ventas B2B de corporate y agencias, grupos y MICE, contact center y recepción. Cinco casos con indicadores: Vincci, Catalonia, Derby, HTOP y una cadena urbana de más de 110 hoteles. - [Salesforce para servicios profesionales](https://kaizenstep.com/salesforce/servicios): Despachos, asesorías, gestorías y consultoras: relación de cliente compartida, venta consultiva, proyectos, conocimiento reutilizable, recurrencia y origen del negocio. Incluye el caso de Alifarma. ### Casos y contenidos - [Casos de éxito](https://kaizenstep.com/casos-exito): Índice de los seis casos con ficha propia, más doce proyectos citados por nombre de cliente. Cada ficha está en /casos-exito/ y lleva el punto de partida cuantificado, la cita del cliente, los productos, las fases y una tabla de antes y después. - [Recursos](https://kaizenstep.com/blog): Índice de diez artículos, clasificados en tres materias: Adopción y uso, Evolución de la plataforma, Elegir CRM. Cada uno está en /blog/. Al pie, las páginas de servicio que desarrollan cada tema aplicado. ### Contacto - [Contacto](https://kaizenstep.com/contacto): Formulario de contacto y datos directos: +34 902 002 373, info@kaizenstep.com, Barcelona. Explica qué pasa después de escribir. ### Información legal - [Aviso legal](https://kaizenstep.com/aviso-legal): Titular del sitio, condiciones de uso, propiedad intelectual y jurisdicción. - [Política de privacidad](https://kaizenstep.com/politica-de-privacidad): Tratamiento de los datos recogidos por el formulario de contacto, finalidades, bases jurídicas y derechos.