La misma persona registrada cinco veces, cada sistema con un pedazo. El cliente que es una familia y no una empresa. El agente que responde sin saber si habla con el titular. bFocus separa quién contrata de quién usa — y mantiene una ficha por persona, aunque ella aparezca en varios clientes y en varios de sus sistemas.
Unir la ficha equivocada es peor que tener dos. Por eso un solo dato une personas sin preguntar: el CPF, el documento fiscal brasileño de la persona física.
El mismo CPF es la misma persona, en cualquier cliente y en cualquier sistema suyo. ¿Llegó un identificador que nadie conoce con un CPF que ya existe? Cae en la ficha de esa persona, y el identificador nuevo pasa a llevar hasta ella.
Quien escribe un correo en el navegador no hereda la cuenta de otra persona. El dato que llega de afuera sin firma nunca une fichas: se convierte en una pista en la pantalla de organizar el registro, para que el equipo decida.
Si la ficha ya tiene un CPF y llega otro, la grabación se detiene y devuelve el conflicto. Cambiar el CPF de alguien es decisión de una persona, no de una integración.
Una persona se encuentra por varios identificadores. El ERP usa el suyo, la tienda usa el suyo, y el código antiguo sigue funcionando después de una unificación.
Uno principal y los adicionales que lleguen. La búsqueda reconoce todos: la dirección del trabajo y la personal llevan a la misma persona.
Si el correo que llegó ya es de alguien de su equipo, la sincronización no adopta ni cambia esa cuenta. La persona se crea sin ese contacto, y queda la pista para que alguien la revise con calma.
La regla de la casa es simple: nada se une por corazonada. Sin CPF, dos fichas parecidas entran en la cola de posibles duplicados y alguien decide.
Hay clientes que son una empresa con treinta empleados y clientes que son una familia. El registro acepta a los dos sin gimnasia — y sin convertir a la persona en empresa de sí misma.
kind, legal_name, state_registration, municipal_registration e id_document entran por la API pública y por la planilla con el mismo significado que tienen en pantalla.
Ver la API públicaEl contador atiende cuatro empresas. El consultor aparece en tres. Cuando dos sistemas suyos envían a esa persona, ella no puede quedar rebotando de empresa en empresa.
Con cuatro productos escribiendo en la misma empresa, la transferencia automática movía a la persona de cliente en cada carga — y el sistema de origen ni se enteraba, porque para él nada había cambiado.
No toda persona llega con la empresa identificada. La lista muestra las que están en algún cliente y las que todavía no están en ninguno.
Nombre, correo, teléfono o identificador — el principal y los extras. Usted pega el código de su ERP y la persona aparece.
Con acceso, Sin acceso, En más de un cliente, Sin cliente. Y puede fijar la lista a un cliente.
Los clientes de la persona, su acceso en cada uno, los identificadores, los tickets y el historial, sin salir de la lista.
Vincular a un cliente más, quitar el acceso en uno solo, desvincularla de un cliente. Antes de confirmar, la pantalla dice qué va a pasar y qué se mantiene.
Vinculada a un cliente más, desvinculada, transferida, ficha fusionada, identificador agregado, quitado o cambiado de principal.
La persona abierta queda en la dirección de la página: usted puede enviarle el enlace a un colega, y el botón atrás del navegador cierra el panel.
Cuando la corazonada no alcanza, el par espera a una persona. Son cuatro pasos, sin planilla de apoyo.
Arriba de la lista de clientes: cuántos tienen documento, correo y personas con acceso, cuántos posibles duplicados hay y cuántas personas llegaron sin empresa identificada. Cada número filtra la lista.
Cada par viene con el porqué — mismo documento fiscal, mismo correo, mismo teléfono, nombre muy parecido, misma raíz de CNPJ para casa matriz y sucursal — y con la marca de Muy probable o Probable.
En clientes la unificación va campo por campo: usted elige de qué lado viene cada uno, lo que esté vacío en la que se queda lo completa la que sale, los correos y teléfonos de ambas se mantienen, y para confirmar usted escribe el nombre de la ficha que sale. En personas, usted elige quién se queda y el resto va junto.
Un clic saca el par de la cola para siempre. Quedarse con dos fichas cuesta mucho menos que unir las de dos personas distintas.
Fuera de la cola: quien llegó sin empresa identificada recibe una sugerencia de cliente — por la agenda del cliente, por sus tickets o por el dominio del correo corporativo, nunca por gmail y similares — y la verificación de la base lista lo que está fuera de lugar, con arreglo de un clic cuando el arreglo es seguro.
Nadie empieza de cero. El registro que usted ya tiene entra por planilla, y sus sistemas siguen enviando por la API.
Siete SDKs oficiales, identificadores extras que vuelven legibles y borrar un contacto es explícito: nulo y ausente siguen significando “no tocar”.
Ver la API y las SDKsUn buen registro es también aquel del que usted puede rendir cuentas. Lo que existe hoy, sin adornos.
Aislamiento por empresa, acceso sin contraseña, identidad verificada por firma y claves con alcance están en la página de seguridad.
Ver seguridad y privacidadNo. Acá es registro y atención: quién contrata, quiénes son sus personas y el historial de tickets, conversaciones y proyectos. La prospección y los leads están en el módulo Comercial, que es otra página.
No. Lo que está en la ficha de una persona lo envió usted, su planilla o un sistema suyo. bFocus sí tiene enriquecimiento, pero es del módulo Comercial, trabaja sobre la empresa del lead (documento fiscal y dominio, desde fuentes públicas) y no sobre la persona.
Cada uno envía su código. Uno queda como identificador principal y el otro como identificador extra: los dos llevan a la misma ficha, y la lista muestra cuál es cuál y de dónde vino.
La grabación se detiene y devuelve conflicto. Nada se cambia en silencio: alguien de su equipo lo mira y decide en pantalla.
No. Sin CPF el registro funciona igual — simplemente no une a nadie por corazonada. Dos parecidos quedan esperando en la cola de duplicados.
Puede. El acceso es del vínculo: quitarlo en una empresa no toca la otra. Ella queda sin acceso del todo solo cuando ningún cliente se lo concede.
Todo lo de la que sale pasa a la que se queda: tickets, conversaciones, proyectos, tareas, anotaciones y archivos. El identificador de la que sale sigue valiendo como identificador extra, así que el widget y la API que todavía usan ese código no se rompen. No se puede deshacer, y por eso la unificación de clientes pide que usted escriba el nombre de la que sale.
Importe la planilla, mire la vista previa y abra la cola de duplicados. Sin tarjeta y sin implantación.