Condiciones de Uso
Estas Condiciones regulan el acceso y uso del sitio web fundrasingycrm.fernandaestavillo.com. Al acceder, el usuario acepta estas Condiciones. Si no está de acuerdo, debe abandonar
31 de octubre de 2025 No hay comentarios
aprende a registrar correctamente los datos en google o excel
Como preparar una base de datos correctamente para después migrar a un CRM
He visto empresas de todos los tamaños con ficheros que no son compatibles para una migración a un sistema de gestión. Limpiar estos datos y adecuar el fichero no tiene que ser una pesadilla para tu organización si desde el principio lo haces adecuadamente.
En este contenido formativo te explico la relación entre un fichero y un sistema para que entiendas por qué se debe preparar de forma correcta si quieres ahorrarte dolores de cabeza. Si no eres de leer, tienes la versión de video.
Vamos a hablar hoy de cómo preparar una base de datos. ¿Para quién está pensada esta formación? Para principiantes, para personas que todavía no han conocido cómo funciona una tabla de Excel en relación a un sistema. ¿Qué es la progresión más común? Que tenemos datos en cuadernillos y hojas de papel. Que esos datos los empezamos a organizar de una manera mejor, utilizando herramientas digitales como Excel o Google. El siguiente paso es que queremos migrar a un sistema. Un sistema tradicionalmente funciona mediante la carga de estos ficheros.
Esta información, que hoy tienes en un Excel, la vas a importar a un sistema, sea Salesforce, sea HubSpot, sea SoCo, sea DonorBox, a cualquier sistema, sea para gestionar estos contactos, o sea para hacer actividades de comunicación como podría ser importar tu fichero a MailChimp para enviar correos. Lo que queremos hacer aquí es que entiendas la importancia que tiene este fichero en saberlo configurar correctamente para que el día que lo vuelques a un sistema puedas hacerlo con facilidad. Bueno, cuando hablemos de base de datos, vamos a hablar de una tabla.
Una tabla en la que volcamos la información. Esto se ve probablemente muy parecido a alguna tabla que tengas. Una tabla en la que tienes, en el mejor de los casos, columnas, columnas por cada tipo de dato. Esto no quiere decir que esta sea la forma correcta de hacer una tabla, pero debe de verse muy parecido lo que tú tienes. Es muy común que además en una misma tabla puedas tener varias hojas. En donde vas separando la información que al uso consultas continuamente y lo vas agrupando en un mismo documento. En este ejemplo, estamos viendo dos datos que son independientes pero que están relacionados.
Tengo por un lado a la persona y en este caso tengo a Fernanda y tiene un nombre, un apellido, un teléfono, una dirección y una empresa. Tiene algo que ver con ella que por eso la estoy poniendo en el mismo renglón. En este caso vamos a suponer que es porque es la empresa para la que yo trabajo. Y luego tengo datos que tienen que ver con la empresa como son correo, notas, dirección, etc. Esto es una relación.
Para un sistema esto es muy importante. Porque un sistema como funciona es que tú eres capaz de cargar en una sección del sistema todas las personas o bueno, todos los datos que tienen en común algo como en este caso podría ser personas. Y en otra sección del sistema cargaríamos todos los datos que tienen en común algo como en este caso sería la empresa.
Cada uno de estos bloques de datos tienen a su vez información relacionada. Como es a la persona, los datos de teléfono, dirección, etc. Y la empresa, los datos como dirección, teléfono, etc.
Y luego el sistema necesita saber cómo relacionarlas, cómo saber que esta persona está relacionada a esta empresa. Y luego indicar qué tipo de relaciones. Es un empleado, es un cliente, es un embajador. Para estas relaciones el sistema tiene que saber cuando una relación es única o es múltiple. ¿Qué quiero decir con esto? Que una persona, ponemos al caso Fernanda, es posible que esté relacionada con más de una empresa. Puede ser que tenga la relación con una empresa porque es empleada de.
Puede ser que tenga la relación con otra empresa porque es proveedora de. Y lo mismo pasa al revés. Una organización o un ente jurídico, vamos a seguir con el caso de empresa, puede tener una relación con n número de personas porque puede ser que tenga 5 empleados, 10 proveedores, 7 socios estratégicos, etc.
Y todo esto siendo otras empresas, empresa, empresa. Y dentro de esto puede ser que podamos ver las personas dentro de todas estas empresas con las que está relacionada. Bueno, a esto es a lo que el sistema le llama relaciones.
Y es donde dice si la relación es 1 a 1, donde solamente tienes una relación única, donde dices yo soy empleada solo de esta empresa o uno a muchos en donde yo soy empleada de varias empresas. Hay datos que son 1 a 1, es decir, yo tengo un DNA, no hay más. Y hay datos que son múltiples.
En un sistema cada grupo de datos se llama entidad o objeto. Esto es el típico lenguaje súper técnico, que lo importante aquí es simplemente entender que un objeto o una entidad es algo lo suficientemente grande, como si fuera el árbol completo, para agrupar dentro varios ítems individuales. Este es un ejemplo muy básico, pero que ayuda a entenderlo y es entender el objeto como la persona completa y lo que tiene dentro los datos o los campos o los elementos, como los ojos, la nariz, la boca, las partes que le componen, las partes que le pertenecen.
Y esto en la tabla, como se vería, bueno, esto para la tabla es que tenemos que cada columna en un mundo perfecto es un ítem, un elemento, y cada hoja dentro de la tabla es un objeto. ¿Cuál sería la mejor gestión? Tener tablas separadas, si no las tenemos separadas, tener por lo menos hojas dentro de la tabla separadas, en donde yo tengo en una hoja los datos de la persona, el objeto persona y todos sus ítems, en otra hoja los datos de empresa y todos sus ítems y podría ser que no trabaja los productos y servicios que intercambiamos y todos sus ítems. ¿Cuáles eran los ítems de un producto? Por ejemplo, el precio, si está activo, la fecha en que se empezó a vender, la fecha en que se dejó de vender, si fuera un programa, la fecha inicio, la fecha fin, la capacidad máxima de usuarios, la persona responsable de ese programa, etcétera.
Y bueno, en un CRM, estas hojas de Excel, estas que hemos hablado del fichero, como el que contiene los diferentes objetos, cada hoja del fichero como un objeto y dentro de cada hoja las columnas, siendo los elementos o los ítems, en un CRM, esto se traduce a módulos. Cuando entras a un CRM tienes como una página web, secciones. Tú te metes a una página web, de lo que sea y tienes la sección de inicio, de acerca de la sección de programas, pues un CRM hoy en día funciona exactamente igual.
Es más fácil entenderlo como una web que organiza la información y que la interrelaciona. Yo cuando estoy en una web, si estoy por ejemplo en el blog del país y estoy viendo las noticias de economía, empiezo a pinchar y tengo todo relacionado. Voy pinchando una a otra, si luego me voy más grande y estoy en toda la web, puedo saber acerca de el país o nos acerca de nosotros y me relaciona a las personas dentro del país, etcétera.
Bueno, pues esto es lo mismo. Lo que tiene que saber el sistema aquí es precisamente que en el módulo persona tengo los campos de la persona y ahí cuando cargue el Excel lo voy a cargar para esa sección y luego voy a tener la sección módulo empresa y voy a cargar los datos de esa sección. Ahora falta un pequeño punto muy, muy importante que es cuál es el puente.
¿Cómo sabe el sistema que esta persona es esta persona y que esta empresa es esta empresa y que tienen una relación en común? Pues esto lo vamos a saber con una cosa que se llama identificación única o token. Hay tokens artificiales y tokens naturales. Hay tokens como nuestro DNI o nuestro teléfono móvil que son únicos, no hay dos móviles duplicados, es decir el número que tengo yo asignado nadie más lo tiene, lo mismo el DNI, lo mismo el correo electrónico.
Estos datos únicos que pueden ir asociados o a una persona o a una empresa suelen ser datos que nos sirven como tokens como también son información privada y personal es útil para nosotros identificar empresas únicas, personas únicas pero siempre es útil y recomendable asignar nuestro propio token único. Para esto tener un número secuencial o una mezcla de letras y números que le digamos al sistema que no se repitan y que se lo estampen a cada idea única cuando entra nuestro sistema es otra forma de tener un identificador que lo relocione internamente. Que sepas que todos los sistemas hacen esto automáticamente detrás de cámaras por eso cuando exportamos una base de datos lo que va a suceder es que nos va a decir Salesforce y de Salesforce sojo y de sojo Dynamics y de Dynamics porque el propio sistema precisamente necesita mapear registros únicos para después interrelacionarlos.
Que es lo importante aquí que cuando yo tengo la ficha única persona vamos a pensar que en mi caso es 000001 y la ficha empresa E000001 para el sistema subo una vez la ficha de Fernanda una vez la ficha de empresa y a partir de ahí cada que quiera mapear una relación vamos a pensar que Fernanda compró un programa y yo estoy en una empresa el sistema no tiene que volver a mapear toda la información no la duplica simplemente conecta que el 00001 que trabaja en la empresa 00001 compró el producto 00001 tres veces
¿Qué quiere decir? que no queremos duplicar datos que queremos tener datos únicos bien identificados y que queremos tener forma adecuada del dato es decir, reglas que aseguren que es correcta el registro del dato que un correo tenga roba y punto algo que un teléfono tenga 10 dígitos que un país sea parte de un listado de países por ejemplo, para que no haya un problema con que el país sea que nada más hayan inventado y luego tenemos el concepto atomicidad del dato que yo creo que este es el error más común que se ve en las tablas caseras ¿Qué pasa? que metemos el nombre completo en una columna que metemos el teléfono completo en otra columna, incluso con tel.cel. a veces con espacios, a veces sin espacios a veces con prefijos, a veces sin prefijos ¿Qué es la atomicidad del dato? que queremos romper el dato en las partículas en la forma más pequeña posible a lo que refiere el dato entonces, si tengo 3 nombres y un apeído María de la luz Fernanda Joaquina pues voy a tener María en una columna de la luz en otra columna y Joaquina en otra columna nombre 1, nombre 2, nombre 3 apellido 1, apellido 2 teléfono 1, teléfono 2
Queremos ser consistentes en los tipos de datos ¿Qué quiere decir esto? que cuando tu alimentas tu tabla a un sistema no puedes mezclar peras con manzanas si tu nombre es un texto y tu fecha es una fecha cuando cargues en el sistema tendrá que recibirlo una caja o un campo que tenga el mismo formato tu no vas a poder subir un dato que esté formateado diferente porque vas a tener problemas en la importación ojo aquí me estoy olvidando ojo aquí con las fechas muy importante mantener una consistencia en que el formato fecha sea día a mis año año, mes, día para que tampoco haya problemas de integridad en la información
Para un sistema cada registro es una fila en tu tabla si tu tienes 1000 personas vas a tener 1000 líneas en tu excel si cada una de esas personas hace una transacción en la hoja de transacciones vas a tener 1000 filas si tu vendes 10 productos vas a tener 10 filas y vas a relacionar que esas 1000 transacciones que es el excel con 1000 filas voy a tener una columna que simplemente diga el ID del producto o productos que compró cada una de esas filas para un sistema por eso es que es tan importante poder relacionar el dato de acuerdo así es como se ve en la mente de un sistema la relación entre todos los datos
Bueno, ya terminamos de hablar de de esta estructura de relación de datos ahora vamos a hablar de la forma de los datos, normalización se refiere que no tengamos un confeti, un popurri de formas de decir lo mismo mientras más listados de selección tengas o reglas de campos más calidad va a tener tu base de datos hay servicios que pueden limpiar tus datos y normalizarlos hay diferentes estrategias para mantenerlos pero bueno, para que lo tengas en cuenta esto como afecta en las analíticas o porque es la importancia de tener el dato bien normalizado porque tú quieres poder hacer reportes si tú tuvieras 10 formas diferentes de llamar a tu programa cuando quieras hacer una gráfica de las personas que están en tu programa el sistema no va a poder saber que se trata todo del mismo programa o todo del mismo motivo de pérdida entonces imagínate que tú quieres saber el estado por el que x número de personas cumplieron con éxito un hito del programa pero simplemente tienes el cumplieron bien y cumplieron mal a nivel reporting, a nivel tabla normalizada pero el motivo es una caja de texto con notas bueno, esto cuando quieras hacer el reporte va a ser muy difícil o imposible para ti realizarlo, en cambio si tengo además de la caja de notas un sub motivo y sub motivo yo voy a poder segmentar y voy a poder mostrar una tabla que diga el 30% no cumplieron con éxito por este motivo que a su vez se refiere a este otro sub motivo y a este porcentaje
Entonces bueno, yo que te recomiendo que ya a partir de ahora y antes de migrar a un sistema empieces a revisar tu dato que sea una columna por dato, que tengas el mismo formato aunque estés hoy mismo trabajando en un fichero que tengas un identificador único desde ahora mismo en cada una de tus personas tus empresas, tus programas para que cuando hagas el importe de datos el sistema pueda relacionar fácilmente tu histórico de datos, que tengas integridad, es decir que sepas que el dato está donde tiene que estar y pertenece a quien pertenece es muy común revolver que el domicilio por ejemplo pertenece a la persona y no a la empresa o al revés o el teléfono no es lo mismo el teléfono de la empresa que sería la centralita que el teléfono directo de la persona a la que le estoy llamando, entonces hay que poner el teléfono de la centralita en la empresa pero el teléfono directo en la ficha del contacto y por último normalización y para cerrar algunas recomendaciones de herramientas que sirven para limpiar tablas y la función o la calidad que tienen con relación a GDPR en primer lugar tenemos Open Refine que es de código abierto y ayuda a hacer la gestión de duplicados, estandalización está bien con temas de GDPR, hace un procesamiento local, local con lo cual tú no subes ningún dato a la nube entonces ésta sería mi recomendación luego tienes una versión otra que se llama Talent, que tiene una versión Premium en la que también cumple con la GDPR y que tiene una versión local y luego tienes Google, que aquí está alojado en la nube, con lo cual aunque cumple con la infraestructura de seguridad de Google siempre hay que revisar muy bien la seguridad del dato especialmente con bases de datos que contengan un alto volumen de números de información privada
Bueno, espero que te haya quedado claro aquí cómo funcionan los datos y sea útil para que tomes en cuenta que cuando estés entrando un sistema, lo primero que revise sea cómo es la exportación del dato que registres dentro Hay muchos sistemas que son muy fáciles de usar, que puedes empezar gratis y que en el momento en que quieras exportar tu histórico no te dejen exportar tu histórico o te exporten solamente algunas partes de la información con lo cual tu nunca podrás llevarte en realidad todas tus datos importarlos en otro sistema y mantener tus reportes, tu histórico, tus comparativas este es un truco muy usado por los sistemas que se llama vendor lock-in y este vendor lock-in lo que hace es precisamente tomar como rehenes a tus datos que si tu no quieres perder tu histórico y quieres migrar a otro sitio te dejen irte con todas tus cosas por eso es que yo confío mucho en los sistemas grandes, dynamics Salesforce, EV, Soho que al final del día son sistemas que son transparentes en cuanto a la importación exportación del dato, no hay misterios y todo es tuyo, algunos que son más complejos de exportar y de migrar pero según cómo estén tejidas este modelo de datos que de complejo será más complicado o no exportar pero al final del día son tuyos y puedes hay un montón de sistemas gratuitos pequeñitos desconocidos que una de las cosas más graves para mí es que estás pagando por usarlo gratis con darles tus rehenes a tus datos ojo ahí, muchas gracias
OTROS CONTENIDOS RELACIONADOS
Leer más »
Política de Privacidad
Política de privacidad 1. Identificación del responsable del tratamiento. Fernanda Estavillo. es la responsable del tratamiento de tus datos de carácter personal a los efectos
31 de octubre de 2025 No hay comentarios
Servicios de CRM
Politica de Cookies
Fundrasing y CRM, por sí mismos o a través de terceros, pueden usar cookies y otros mecanismos similares de almacenamiento y recuperación de datos (en
31 de octubre de 2025 No hay comentarios
NOTAS DE CRM ESTRATÉGICO
