Operar en varios países: divisas, zonas horarias y un único registro de clientes

TL;DR

Operar en varios países exige decidir primero qué significa “mercado” y después traducirlo a cuentas, oportunidades, permisos, divisas y reglas de escalado. El CRM debe conservar un registro de cliente coherente sin borrar las diferencias comerciales y legales de cada país.

• Definir el modelo operativo multinacional → Reglas antes de configurar
• Diseñar un registro único de cliente → Niveles y coincidencias confiables
• Configurar divisas y pipelines → Comparabilidad con control local
• Separar visibilidad por mercado → Acceso local, reportes globales
• Hacer explícitos los traspasos → Propiedad decidida con evidencia
• Poner controles recurrentes → Detectar errores antes del cierre
• Preparar excepciones entre países → Casos especiales bajo aprobación

Takeaway: La configuración correcta no parte del organigrama, sino de las decisiones que deben repetirse cuando una cuenta, una oportunidad o un ingreso involucra más de un país.

Definir el modelo operativo multinacional antes de tocar la configuración del CRM

El error más costoso suele ocurrir antes de crear el primer campo: cada país interpreta “su mercado” de una manera distinta. Para ventas puede ser el país del vendedor; para finanzas, la entidad que factura; para marketing, el idioma; y para dirección, la región comercial.

Si esas dimensiones gobiernan objetos diferentes sin una regla clara, aparecen cuentas duplicadas, propietarios discutidos y reportes que no cuadran.

La decisión inicial debe responder: ¿qué dimensión gobernará cada decisión operativa? No siempre será la misma. El país propietario puede definir quién gestiona una cuenta; la entidad vendedora, la facturación; y el país de entrega, otro informe. No conviene ocultar esas diferencias bajo un único campo llamado “país”.

Antes de configurar permisos o automatizaciones, documenta una matriz sencilla:

Después, define las reglas maestras. Una cuenta global debe existir como registro único cuando representa al mismo cliente corporativo. Las filiales o localizaciones se crean cuando tienen operación, facturación, equipo comprador o relación comercial propia.

Una oportunidad puede pertenecer a otro país cuando el proceso de compra lo dirige esa operación, aunque la sede esté en una jurisdicción distinta.

Como mínimo, cada oportunidad multinacional debería exigir país propietario, país de facturación, moneda, entidad vendedora, cuenta matriz y estado de conflicto entre mercados. Estos campos sostienen permisos, automatizaciones y reportes. Un campo vacío en esta capa deja una decisión sin dueño.

Kit de plantillas para estandarizar datos de clientes multinacionales

Ingresa tu correo electrónico para descargar una guía que te ayudará a comenzar con cualquier software de gestión de proyectos.

Reconozco que he leído y entendido la Política de Privacidad de Bitrix24

Diseñar un registro único de cliente que soporte filiales, sedes y relaciones entre países

Un registro único no significa que toda la información viva en una cuenta plana, sino que los niveles queden relacionados. El CRM de Bitrix24 guarda las compañías y las vincula entre sí, con sus contactos y sus oportunidades; sobre esa base modelas los niveles con registros relacionados y campos, no con un árbol matriz-filial predefinido. La idea es distinguir cuatro planos:

• Cuenta global: nombre corporativo normalizado, grupo económico, dominio principal, relación estratégica y propietario global, si existe.
• Subsidiaria nacional: razón social legal, país, identificador fiscal, moneda de operación, entidad compradora y propietario local.
• Ubicación: dirección operativa, sede, planta, zona horaria y necesidades de servicio.
• Contacto: función, país, autoridad en la compra, relación con la subsidiaria y preferencias de comunicación.

La política de compras puede estar en la matriz, mientras que el presupuesto, la dirección de entrega y el equipo usuario pertenecen a una subsidiaria. El modelo debe indicar qué datos se mantienen a nivel de grupo y cuáles se capturan localmente; de lo contrario, el equipo local pierde contexto o cada vendedor termina creando una cuenta separada.

Un ejemplo ilustrativo aterriza la idea. Supongamos ACME Group, con matriz en Estados Unidos y una subsidiaria en México: la matriz negocia el acuerdo marco y define la política de compras, pero la subsidiaria mexicana es la que opera, recibe la entrega y factura.

La oportunidad se acuerda en dólares a nivel de grupo, pero la entidad local factura en pesos mexicanos. En el registro, la cuenta global conserva el grupo económico y la relación estratégica; la subsidiaria guarda su identificador fiscal (RFC), su moneda de facturación (MXN) y su propietario local.

Sin esa separación, alguien crearía una segunda cuenta “ACME México” y se perdería el vínculo con la matriz.

La prevención de duplicados comienza con una búsqueda obligatoria antes del alta. El CRM debe comparar, con una ponderación definida, el dominio corporativo, la razón social normalizada, el identificador fiscal cuando exista y el teléfono principal.

El problema no es menor: se estima que más del 30% de los registros de una base de datos de clientes pueden estar duplicados o ser inexactos, lo que distorsiona cualquier consolidación. La coincidencia no puede depender solo del nombre escrito por el vendedor: “ACME México”, “ACME de México, S.A. de C.V.” y “ACME Latam” pueden ser la misma relación o tres entidades distintas.

Los grupos con marcas diferentes requieren revisión. Una marca local puede no compartir dominio, teléfono ni razón social con la matriz. El administrador debe verificar la relación mediante documentación comercial, identificadores fiscales, referencias del comprador o vinculación declarada por el equipo global.

No conviene fusionar por intuición. Reunir todo en un registro central evita que cada país mantenga su propia versión del mismo cliente.

El vendedor puede iniciar el alta, pero una coincidencia clara debe bloquearse o redirigirse al registro existente; las ambiguas pasan a una cola central. La fusión debe conservar actividades, oportunidades, contactos, notas y trazabilidad del propietario anterior. Borrar un registro destruye evidencia comercial.

Configurar divisas y pipelines sin romper comparabilidad ni control local

La elección entre un pipeline global, pipelines por país o un modelo híbrido debe reflejar diferencias reales del proceso. Un pipeline único funciona cuando las etapas, criterios de avance y responsables son equivalentes. Los separados tienen sentido cuando cambian contratos, canales, aprobaciones o ciclos de venta.

El modelo híbrido mantiene etapas comunes y añade vistas, campos o pasos locales.

No armes pipelines independientes solo para que cada equipo vea “su propio tablero”. Esa necesidad normalmente se resuelve con filtros, territorios y permisos. Separar procesos sin una diferencia operativa introduce etapas incompatibles y complica la consolidación.

En la oportunidad, la moneda local debe ser obligatoria. El importe original debe conservarse tal como lo presentó el cliente o lo acordó el vendedor. El CRM puede calcular sobre ese valor un importe convertido para los reportes mediante un tipo de cambio de referencia.

En Bitrix24, por ejemplo, el CRM admite varias monedas: se fija una moneda base y se cargan las demás con su tipo de cambio, que se actualiza de forma manual, así que conviene asignar un responsable de mantenerlo al día.

El tipo de cambio necesita una política explícita, no un valor que cada quien copia de donde puede. Conviene fijar una única fuente oficial y una cadencia. Por ejemplo, para la conversión contable puede usarse el promedio mensual de los tipos de cambio de referencia del euro que publica el BCE cada día hábil hacia las 16:00 CET, y para el pronóstico diario, el valor del día.

Esa referencia común y verificable evita que cada equipo use su propia cifra.

Falta definir el punto de fijación: algunas empresas fijan el tipo al crear la oportunidad; otras, al cierre previsto, la firma o la facturación. La elección depende de qué quiere medir el pronóstico, y no es menor.

Si el valor convertido cambia a diario sin registrar la variación, dirección puede confundir un efecto cambiario con un cambio real en el desempeño comercial, que es el error más común al consolidar en una sola moneda. Por eso conviene congelar el tipo en un punto definido y guardar la fecha y la fuente de cada conversión.

Define también quién publica la tabla de conversión, con qué frecuencia, cómo se redondea el importe convertido y cuál es la moneda de reportes consolidada. Puede haber, a la vez, moneda de negociación, contractual y de facturación, siempre que el CRM muestre cuál se usa en cada cálculo.

Las correcciones del importe consolidado deben quedar auditadas y restringidas a finanzas u operaciones autorizadas.

Separar visibilidad por mercado sin perder reportes consolidados del grupo

Los permisos deben diseñarse a partir de la combinación de rol y territorio, no de una división simple por país. Un vendedor puede ver y editar sus oportunidades; un responsable nacional, reasignar trabajo dentro de su mercado; un propietario global, consultar relaciones de varias subsidiarias; y operaciones centrales, acceder al conjunto para mantener datos y reportes.

Antes de crear reglas de compartición, define cinco acciones por tipo de usuario: ver, editar, reasignar, exportar y administrar. Conviene aterrizarlo con reglas concretas.

Por ejemplo: “el equipo de un territorio ve las oportunidades de su país en modo lectura y edición, y las de un país vecino solo en lectura para preparar propuestas conjuntas”; o “un tablero local filtra por país propietario igual al del usuario, mientras el tablero global muestra todos los países sin permitir editar ni exportar la cartera local”.

Así, un equipo puede consultar una oportunidad de otro país sin cambiar su propietario ni exportar datos ajenos.

La pertenencia al mercado puede apoyarse en país propietario, territorio comercial y entidad vendedora. Estos campos deben validarse entre sí. Una oportunidad con país propietario Chile y entidad vendedora Colombia debería activar una excepción, no pasar silenciosamente al reporte de cualquiera de los dos equipos.

Las zonas horarias merecen tratamiento propio, porque afectan asignación, SLA y reportes. En Bitrix24, cada usuario define su propia zona horaria, de modo que las fechas y horas se muestran en la hora local de quien las mira.

La regla operativa es no depender de una sola zona global: define las horas hábiles por país para calcular los SLA y repartir el trabajo entrante, y normaliza los registros a UTC para que los reportes que cruzan países sean comparables.

Ese detalle cambia cuándo llegan las notificaciones y en qué momento cierra la cadencia del pronóstico, y evita que un vencimiento “de hoy” signifique cosas distintas en Madrid y en Ciudad de México.

Para la colaboración cruzada, usa acceso limitado y temporal cuando sea posible: una oportunidad compartida con permisos de lectura o una cola conjunta con fecha de revisión. El acceso global permanente facilita exportaciones masivas y cambios de propietario sin control.

Los reportes deben separar sus perspectivas:

1. Vista local: oportunidades propias, moneda de operación y tareas del mercado.
2. Vista regional: cuentas relacionadas, cobertura conjunta y riesgos de concentración.
3. Vista global: ingresos convertidos, pipeline por grupo y conflictos abiertos.

Un informe consolidado debe mostrar la cuenta matriz sin sumar dos veces las oportunidades de sus subsidiarias. Si los números difieren entre vistas, revisa qué campo define pertenencia, qué importe se suma y si la matriz está funcionando como cliente o solo como contenedor.

Hacer explícitos los traspasos cuando un cliente o una oportunidad cruza fronteras

Una cuenta cruza fronteras cuando dos países participan materialmente en la relación, no solo porque el cliente tenga una dirección internacional.

El escalado debe dispararse por señales observables: la misma organización opera en dos mercados, dos vendedores reclaman la oportunidad, el país de facturación no coincide con el mercado que la creó o el comprador solicita cobertura conjunta.

Configura un estado de conflicto y una cola visible para que nadie cierre, reasigne o duplique la oportunidad mientras se decide. El caso debe incluir la cuenta matriz, subsidiarias relacionadas, importe, país del comprador, entidad firmante, ubicación de entrega y actividad comercial registrada.

Para que los reportes sean consistentes, conviene estandarizar los valores de lista en lugar de dejarlos a criterio de cada equipo.

Un “estado de conflicto entre mercados” puede tener los valores Detectado, En revisión, Resuelto con copropiedad y Resuelto con cambio de propietario; y un “resultado de escalado”, valores como Cambio de propietario, Copropiedad temporal, Cuenta matriz compartida, División de ingresos u Oportunidades relacionadas.

Con listas cerradas, la dirección puede medir cuántos conflictos aparecen y cómo se resuelven.

• El vendedor local marca el conflicto y adjunta la evidencia.
• El responsable de país valida la pertenencia o la necesidad de colaboración.
• El propietario global interviene cuando existe una relación corporativa coordinada.
• El área de operaciones de ingresos decide si hay impacto en los reportes, la propiedad o las reglas de excepción.

Mientras la decisión está pendiente, el propietario actual conserva la responsabilidad de avanzar el proceso, salvo indicación contraria del responsable de país. El resultado debe registrarse con una acción concreta: cambio de propietario, copropiedad temporal, cuenta matriz compartida, división de ingresos u oportunidades relacionadas.

La división de ingresos no debe resolverse editando importes a mano en dos oportunidades. Define si habrá una oportunidad única con campos de participación, oportunidades relacionadas con una regla de consolidación o un registro financiero posterior. El reporte debe distinguir el importe contractual de la cuota atribuida a cada país.

Poner controles recurrentes para detectar duplicados, errores de divisa y conflictos de propiedad

La calidad del modelo se comprueba después de la puesta en marcha, cuando aparecen cuentas nuevas, cambios de personal y operaciones urgentes. Establece una revisión por país y otra central para detectar patrones que un equipo local no puede ver.

La revisión debe buscar:

• cuentas nuevas sin cuenta matriz o relación corporativa definida;
• posibles duplicados entre mercados;
• oportunidades con moneda incompatible con la entidad vendedora;
• registros sin país propietario, país de facturación o entidad vendedora;
• cambios recientes de propietario, país o importe convertido;
• cuentas con varias oportunidades que podrían representar el mismo contrato.

Los controles deben aparecer dentro del flujo, no en una auditoría posterior. Un ejemplo de validación al guardar: hacer obligatorio el campo “moneda” para que una oportunidad pueda pasar a la etapa de cierre. En Bitrix24 esto se configura como campo requerido en la etapa, disponible en algunos planes, y evita cerrar una oportunidad sin moneda.

Una comprobación más fina, como avisar cuando el país de facturación no coincide con la entidad vendedora, no es un campo obligatorio: se arma con una regla de automatización que compara ambos campos.

Esa misma automatización puede crear, cuando el “estado de conflicto” pasa a “Detectado”, una tarea en la cola “Revisión entre mercados” con el responsable de país y un plazo de 48 horas.

La automatización puede detectar, puntuar y enrutar coincidencias, pero la fusión, el cambio de propietario y la atribución de ingresos requieren revisión con contexto. Cada modificación sensible debe conservar usuario, fecha, valor anterior y valor nuevo.

Sigue la tasa de duplicados detectados, el tiempo de resolución de conflictos, las oportunidades reabiertas por error de divisa y el porcentaje de cuentas correctamente relacionadas. Si suben los conflictos después de abrir un mercado, puede haber una regla mal diseñada, no solo un problema de disciplina.

Preparar excepciones que siempre aparecen en operaciones entre países

Las excepciones se vuelven un problema cuando cada vendedor las interpreta de forma distinta. Un distribuidor puede comprar en México y revender en Guatemala; una marca local puede no compartir identificadores con su matriz; y un cliente global puede negociar con un área de compras centralizada, firmar localmente y exigir soporte regional.

Para cada caso, separa la regla estándar de la excepción. El distribuidor puede tener una cuenta como comprador y relaciones de entrega o reventa en otros mercados. El grupo con varias marcas puede vincularse a una matriz mediante una relación verificada.

El cliente con compras centralizadas puede mantener propietario global para la negociación y propietarios locales para implementación o renovación.

Cuando una marca o un distribuidor no comparten dominio, teléfono ni razón social con la matriz, conviene fijar un criterio documental mínimo antes de vincular o fusionar cuentas: por ejemplo, un contrato de distribución vigente, un identificador fiscal cruzado que pruebe la relación, o una carta del cliente que confirme la pertenencia al grupo.

Sin al menos una de esas evidencias, las cuentas quedan relacionadas de forma provisional, no fusionadas.

Una excepción debe requerir aprobación cuando cambia propiedad, reconocimiento de ingresos, permisos o estructura de cuentas. La solicitud debe explicar qué regla no aplica, por cuánto tiempo, qué registros afecta y quién revisará el caso.

El área de operaciones de ingresos, o una mesa conjunta de operaciones y finanzas, puede aprobarla; el vendedor involucrado no debería ser la única autoridad.

El campo “excepción” debe incluir motivo, aprobador, fecha de inicio y fecha de revisión. Si el mismo caso se repite, actualiza la regla general. Si responde a una fusión o contrato particular, mantén la excepción documentada y limitada.

La implementación debe empezar con dos países que tengan diferencias reales de moneda, permisos o proceso comercial. Configura las cuentas relacionadas, simula una oportunidad multimoneda y provoca una disputa de propiedad antes de escalar al resto de la organización. Registra cada decisión de configuración junto con su motivo, responsable y fecha de revisión.