---
title: "¿Cómo mantiene cientos de automatizaciones del CRM de forma sostenible?"
blueprint: 011
slug: keeping-hundreds-of-automations-maintainable
category: Gobernanza
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/
language: es
translation_of: https://blueprints.coevera.com/blueprints/keeping-hundreds-of-automations-maintainable/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---

# ¿Cómo mantiene cientos de automatizaciones del CRM de forma sostenible?

**Respuesta corta.** **El número de procesos no lo elige usted.** Un proceso es un disparador,
luego un único nodo de filtro y luego acciones, y un filtro nunca puede ser hijo de una acción.
Así que no se puede añadir una segunda condición independiente a un proceso que ya tiene una. Hay
que traspasarla a otro proceso, que lleva su propio filtro.

El proceso invocado se ejecuta ante un cambio de registro o de forma manual, y el **disparador
manual** es la opción que evita que se dispare por sí solo. Manual no significa que lo dispare un
usuario; significa que **no se dispara por sí solo**, de modo que otro proceso puede invocar un
proceso manual *y* una persona puede ejecutarlo. El mismo proceso es una subrutina en una cadena y
una herramienta de reparación que alguien dispara a mano.

Así que lo que usted controla no es cuántos procesos tiene, sino si siguen siendo legibles:
**etiquete cada proceso y ponga a su nombre un prefijo de dominio**, porque la plataforma muestra
cuándo se ejecutó un proceso, pero no tiene ninguna vista documentada de qué lo invoca.

## 01 · El problema de negocio

Un evento de negocio suele requerir comprobar varias cosas sin relación entre sí. Tome una cuenta
que pasa de cliente potencial a cliente:

- Si faltan los datos del contacto principal, avise al propietario; de lo contrario, todos los
  correos automatizados posteriores no llegan a nadie.
- Si la región se escribió como abreviatura de dos letras, expándala, porque de lo contrario los
  informes por país se dividen en duplicados sin que nadie lo note.
- Rellene las fechas de renovación a partir del plazo del contrato, que es de doce o de
  veinticuatro meses.

No son alternativas. Una misma cuenta puede necesitar las tres, y no tienen nada que ver entre sí.
El instinto es escribir un solo proceso para "la cuenta se convierte en cliente" que lo resuelva
todo, y de ese instinto trata el §2.

El conjunto de automatizaciones del que se extrae este caso tiene **265 procesos repartidos en
siete entidades**, con **113 solo en una entidad**. Esa cifra no es desorden ni una señal de
alarma. Es lo que produce la forma del motor cuando un negocio tiene tantas reglas, y la pregunta
interesante no es cómo tener menos, sino cómo mantener legibles cientos de ellos.

## 02 · Por qué falla el enfoque obvio

### Poner las tres comprobaciones en un solo proceso

> **Un proceso tiene un solo filtro, y el filtro es una única compuerta.** Sus ramas son *if /
> then / else*: gana la primera rama que coincide y las demás nunca se evalúan.
>
> Así que las tres comprobaciones anteriores, escritas como tres ramas de un mismo proceso, hacen
> que una cuenta que necesita las tres reciba **solo la primera**. Ni error, ni advertencia, ni
> informe de éxito parcial. Dos correcciones sencillamente no se producen, y el proceso parece
> haberse ejecutado.

Es el malentendido más caro que ofrece el motor de procesos, porque el diseño parece más ordenado
y el fallo es invisible. Además empeora con el éxito: cuantos más casos cubre el proceso, más
probable es que un registro coincida con varios y reciba uno.

Tampoco puede volver a filtrar a mitad de la cadena para sortearlo. **Un filtro nunca puede ser
hijo de una acción**: la forma canónica es disparador, luego filtro y luego acciones, y el motor
no acepta una segunda compuerta colgada al final del trabajo de la primera. Por tanto, las
condiciones independientes no pueden expresarse en absoluto dentro de un único proceso. Es un
hecho estructural, no una preferencia de estilo.

### Nombres descriptivos

Nombrar un proceso según lo que hace (*Enviar el correo de bienvenida*, *Actualizar la fecha de
renovación*) resulta claro el primer día e inútil en una lista de doscientos, porque la lista
queda ordenada por verbo. Todo lo que empieza por *Actualizar…* acaba junto sin importar lo que
toque, y los seis procesos de un mismo dominio se dispersan por el alfabeto. La lista se lee mucho
más a menudo que cualquier nombre individual.

### Documentarlo en una hoja de cálculo

Exacta el día en que se escribe, errónea al cabo de un mes, porque el conjunto cambia en la
interfaz de administración y el documento no. Todo lo que se mantiene en paralelo a lo que
describe acaba desviándose. Lo que perdura es lo que vive *dentro* del conjunto, y por eso el
nombre tiene tanto peso.

## 03 · La forma de un proceso y lo que se deriva de ella

Todo lo que contiene este blueprint se deriva de un único hecho estructural:

```
trigger  →  filter  →  actions
              ↑
              exactly one, at the root.
              A filter may never be a child of an action.
```

Lo que significa que un proceso puede aplicar **una** condición independiente. Una segunda
condición necesita un segundo proceso, y la forma de llegar a él es un **nodo de disparo de
proceso**, que traspasa el control a otro proceso y *lleva su propio filtro*. La siguiente
condición vive en el traspaso.

**Fuente.** Centro de ayuda de Coevera, [Automatizer — triggering a process from another
process](https://help.coevera.com/en/articles/6480542-automatizer-triggering-a-process-from-another-process),
que presenta el mismo mecanismo como la forma prevista de construir: "more scaled-down processes …
chained together into a unified workflow". El Process Manager que los enumera se documenta [por
separado](https://help.coevera.com/en/articles/3841438-automatizer-the-process-manager-and-process-notifications).

Así que el ejemplo de cliente potencial a cliente no es un proceso. Es un detector más tres
subprocesos:

| Proceso | Disparador | Su propio filtro |
|---|---|---|
| Detectar la transición | Actualización del registro en el campo de clasificación | Se ha convertido en cliente |
| Comprobación de datos de contacto | **Manual** (invocado) | Campos del contacto principal vacíos |
| Corrección de la región | **Manual** (invocado) | La región es un código de dos letras |
| Relleno de fechas de renovación | **Manual** (invocado) | El plazo es de 12 o 24 meses |

Cada subproceso evalúa su propia condición de forma independiente, así que una cuenta que necesita
las tres correcciones recibe las tres. Esa es toda la razón por la que el conjunto tiene esta
forma.

> **Dé a cada subproceso un filtro permisivo en la raíz, aunque el llamador ya haya decidido.** No
> cuesta nada y aporta algo concreto: como los procesos manuales también puede ejecutarlos una
> persona, el subproceso puede invocarse en un contexto que nadie ha comprobado. Su propio filtro
> raíz es lo que lo hace seguro en ambos sentidos.

## 04 · El tipo de disparador es un dato de primer orden

Hay cuatro tipos de disparador, y el tipo determina tanto cómo se llega a un proceso como la forma
en que falla. Esto forma parte de cómo se piensa el conjunto de automatizaciones, no de algo que
se descubre al abrir un proceso.

| Tipo | Se llega mediante | Cómo falla |
|---|---|---|
| **Record** | El cambio de un campo | **En silencio.** Si el campo deja de cambiar (una integración se detiene, una importación reescribe el mismo valor), nada se dispara y nada lo notifica. Imposible de distinguir de una semana tranquila. |
| **Schedule** | Una hora del día | **Sin titubear.** Se ejecuta puntualmente estén o no actualizados sus datos de entrada, así que actúa sobre datos obsoletos en lugar de no actuar. |
| **Manual** | Otro proceso que lo invoca, *o* una persona que lo ejecuta | **Huérfano.** Si el llamador se reescribe para dejar de invocarlo, ya no se llega al subproceso y nada lo indica. Su condición sigue siendo correcta; nada la consulta. |
| **Online form** | El envío de un formulario | Junto con el formulario. Fuera del alcance de este blueprint. |

> **La cifra que merece la pena medir en su propio conjunto de automatizaciones.** En la entidad
> más cargada de este caso, con 113 procesos, el reparto es de **41 disparados por registro, 16
> programados y 56 manuales**.
>
> Que la mitad de esa entidad sea manual no es un cajón de utilidades olvidadas. Es la *capa de
> composición*: los subprocesos que existen porque las condiciones independientes no pueden
> compartir un filtro. Un número alto de procesos manuales en un conjunto maduro es señal de que
> la descomposición se hizo correctamente.
>
> Sí crea el único modo de fallo propio de este tipo. Un proceso disparado por registro que deja
> de dispararse al menos sigue figurando como vigilante de un campo; un subproceso huérfano parece
> idéntico a uno que funciona. Por eso el §7 sigue las cadenas de llamadas en lugar de limitarse a
> leer la lista.

## 05 · Patrones que mantienen legible un conjunto de automatizaciones grande

### Etiquete por dominio y ponga también el prefijo en el nombre

Los procesos admiten **Tags**, y el Process Manager filtra por etiqueta además de por propietario
y estado ([Automatizer — creating and running
processes](https://help.coevera.com/en/articles/3834789-automatizer-creating-and-running-processes)).
Utilícelas. Pero la búsqueda de la lista compara nombres, una etiqueta solo aparece en una columna
que usted decida añadir, y no hay carpetas ni una vista de dependencias documentada. Así que ponga
también el dominio en el nombre, entre corchetes al principio:

```
[Contracts]  Create the renewal record
[Contracts]  Watch the renewal date for changes
[Hygiene]    Normalise country and region codes
[Hygiene]    Flag records whose status contradicts their dates
[Outreach]   Send the scheduled check-in
```

Así, una lista plana **se agrupa sola** al ordenarla, una búsqueda de un dominio **devuelve todo**
lo que lo toca, y añadir un proceso obliga a plantearse *¿a qué dominio pertenece?*, que es lo que
detecta un duplicado antes de que exista.

El conjunto examinado usa alrededor de una docena de prefijos; el mayor agrupa veinticinco
procesos y el menor, dos. Esa distribución es en sí misma una herramienta de revisión: veinticinco
miembros son un dominio que merece leerse en conjunto, y dos son o un caso límite real o un
accidente de nomenclatura.

> **Una convención que no se hace cumplir se desvía.** Dos de los prefijos de este conjunto son el
> *singular y el plural de la misma palabra*: doce procesos con una grafía, trece con la otra,
> todos relativos a la misma entidad. Ninguno es incorrecto; juntos hacen que la agrupación falle
> sin que se note, porque al ordenar quedan contiguos, pero al buscar uno se pierde el otro.
>
> Anote la lista de prefijos como un conjunto cerrado y compruebe los procesos nuevos con ella. Es
> la gobernanza más barata posible, y lo primero que se deteriora.

### Nombre la cadena, no solo el proceso

Como a los subprocesos se llega porque alguien los invoca y no porque vigilen algo, la única pista
sobre quién invoca a quién es el nombre. Un prefijo compartido más un verbo coherente para el
detector (el proceso que es dueño del evento) hacen que una cadena se pueda leer solo con la
lista. Sin ello, seguir un evento de negocio significa abrir procesos hasta dar con el llamador.

### Un subproceso sirve a la vez de subrutina y de herramienta de reparación

Como manual significa invocable *y* ejecutable, el subproceso que construyó para la cadena es
también lo que ejecuta a mano cuando una fecha cambia, un registro se crea fuera de orden o una
automatización estuvo desactivada durante una tarde. Es el mismo mecanismo que el gemelo manual
del [Blueprint 010](https://blueprints.coevera.com/es/blueprints/handover-from-sales-to-delivery/)
y la derivación reejecutable del [Blueprint
009](https://blueprints.coevera.com/es/blueprints/automating-on-integration-owned-fields/): no es
un patrón distinto, sino el mismo visto desde otro ángulo. Constrúyalo una vez y cumple ambas
funciones, siempre que conserve su propio filtro raíz.

### Una última rama sin coincidencia que diga algo

Todo filtro que asigna un valor a un resultado debe terminar con una rama que coincida con todo lo
que las anteriores no recogieron y cuya acción sea avisar a alguien. Con la semántica de gana la
primera coincidencia, un valor no reconocido toma, si no, la rama de paso que exista y no produce
ningún error. Es el seguro más barato disponible en un conjunto de este tamaño.

## 06 · Límites y compromisos

La descomposición del §3 es obligatoria. Las *consecuencias* que siguen no lo son; se derivan de
una segunda carencia: **la plataforma informa de cuándo se ejecuta un proceso, no de cómo encaja
el conjunto.** El Process Manager tiene una columna **Activity (24 hours)** y estadísticas de
ejecución de hasta 14 días, y cada proceso guarda un **Activity Log** de sus ejecuciones ([Process
Manager](https://help.coevera.com/en/articles/3841438-automatizer-the-process-manager-and-process-notifications)).
Con las notificaciones activadas, el propietario recibe un aviso cuando se elimina o desactiva un
proceso que sigue conectado a otro ([triggering a process from another
process](https://help.coevera.com/en/articles/6480542-automatizer-triggering-a-process-from-another-process)).
Lo que ninguna vista documentada muestra es qué invoca a un proceso concreto ni qué dejaría de
alcanzarse sin él. Cuando a la mitad de los procesos de una entidad solo se llega porque alguien
los invoca, ese grafo de llamadas ausente es lo que sale caro.

### No se elimina nada, así que se renombra

> **Observado en este conjunto:** cinco procesos llevan las palabras *not used* u *obsolete* **en
> su propio nombre**. Uno de ellos tiene una **programación diaria y sigue ejecutándose**.
>
> No es descuido: es la respuesta racional a no poder demostrar que una eliminación es segura.
> Renombrar es reversible y no cuesta nada; eliminar podría romper algo que nadie sabe nombrar.
> Así, el conjunto acumula una capa de procesos documentados como muertos que no están
> desactivados.

La mitigación es una convención, no una herramienta: retirar significa **primero desactivar,
después renombrar y, por último, eliminar en una fecha que se escribe en el nombre.** Un proceso
marcado como no utilizado que sigue disparándose es peor que cualquiera de los dos estados por
separado, porque el nombre le dice a la siguiente persona que ignore algo que está haciendo
trabajo activamente.

### Los duplicados se acumulan por año

Todo lo que lleva un año en su lógica tiende a copiarse cada enero en lugar de ampliarse, y la
copia anterior nunca se retira. Este conjunto tiene varias familias así, en las que dos procesos
hacen en gran medida el mismo trabajo sobre rangos de años distintos. Cada uno fue el cambio
mínimo correcto en su momento; juntos son dos lugares que actualizar y una lotería sobre cuál se
ejecutó realmente.

### Los procesos programados coinciden, y nada le avisa

Las horas de programación se eligen de una en una, sin ver lo que ya está programado. En este
conjunto, **tres procesos diarios sin relación entre sí se ejecutan a la misma hora**, y otros
están separados por cinco y veinticinco minutos.

Programar a la misma hora no es un fallo en sí. Se convierte en uno cuando dos de ellos tocan los
mismos registros, porque no hay garantía de orden entre ellos ni transacción que envuelva a
ninguno, así que cuál gana no es algo que pueda deducirse de la configuración. Mantenga una única
lista de horas programadas y sus responsables, y separe todo lo que comparta un conjunto de
registros.

### Un subproceso huérfano no se distingue de uno que funciona

Este es el modo de fallo que introduce el modelo de composición. A un subproceso solo se llega
cuando alguien lo invoca. Desactive su llamador y el propietario puede recibir un aviso, si las
notificaciones están activadas; reescriba el llamador para que deje de invocarlo y no se genera
nada. En ambos casos el subproceso sigue pareciendo igual que cualquier otro proceso activado de
la lista, con una actividad tan tranquila como la de una semana floja. Su filtro sigue siendo
correcto. Nada lo consulta.

También es la única forma de proceso muerto cuya muerte se puede *demostrar* de verdad, porque la
llamada está en la propia definición del llamador. Eso convierte el seguimiento de las cadenas de
llamadas en la auditoría más valiosa del §7, y en la única manera de limpiar un conjunto de
automatizaciones con certeza y no a base de valor.

### Los procesos personales son una categoría real

Los conjuntos de este tamaño contienen procesos con las iniciales de alguien como prefijo:
herramientas personales creadas para la rutina de una persona. Funcionan, se usan y son invisibles
para todos los demás. Deles un prefijo compartido y ponga en el nombre lo que hacen, porque la
alternativa es que se queden sin dueño el día en que esa persona cambie de puesto.

### Lo que no hemos verificado

Las afirmaciones estructurales (un filtro en la raíz, un filtro nunca hijo de una acción, los
cuatro tipos de disparador, el nodo de traspaso con su propio filtro) se han **leído del esquema
de la API y de definiciones de procesos extraídas de la interfaz de administración**. El
comportamiento de gana la primera coincidencia de las ramas de un filtro, así como las cifras del
conjunto citadas a lo largo del texto, proceden de operar este despliegue.

**No hemos probado** la activación y desactivación masivas por patrón de nombre, ni si la
plataforma ofrece una vista del grafo de llamadas; la documentación del Process Manager no
describe ninguna de las dos. Las prácticas anteriores suponen que no existen, porque así se
gestiona este conjunto en la práctica, pero que no se use no demuestra que no exista. Si está
fijando convenciones para un espacio nuevo, revise la interfaz de administración actual antes de
comprometerse a compensarlo a mano.

## 07 · Verificación

Esta es la auditoría para un conjunto de automatizaciones que usted no construyó, y funciona desde
fuera. Toda ella lee la lista de procesos en lugar de abrirlos uno por uno.

- **Agrupe por prefijo de nombre y fíjese en lo que no tiene ninguno.** Los procesos sin prefijo
  suelen ser los accidentes: añadidos con prisas y nunca revisados. Cuente también los prefijos
  distintos: más de unos quince significa que el esquema ha dejado de serlo.
- **Busque el singular y el plural de un mismo prefijo**, y el mismo dominio escrito de dos
  maneras. Es el fallo silencioso más común de una convención de nombres y se encuentra en treinta
  segundos.
- **Agrupe los procesos programados por hora del día.** Todo lo que comparte hora merece una
  revisión; todo lo que comparte hora *y* conjunto de registros merece corregirse.
- **Busque en los nombres** *not used*, *obsolete*, *old*, *temp*, *copy* e iniciales personales.
  Después compruebe si cada uno está realmente desactivado. La distancia entre "nombrado como
  muerto" y "desactivado" es donde esta auditoría demuestra su valor.
- **Siga las cadenas de llamadas.** Para cada proceso con disparador manual, averigüe qué lo
  invoca. Aquellos a los que nada invoca están realmente muertos, y es el único tipo de proceso
  muerto que se puede demostrar, porque la llamada vive en la definición del llamador y no en una
  inferencia. Hágalo antes que nada si ha heredado el conjunto.
- **Compare el número de manuales con el de disparados por registro.** Una proporción alta de
  manuales en un conjunto maduro es esperable y sana: es la capa de composición. Lo que importa es
  si cada uno tiene un llamador. Un número alto de manuales *más* huérfanos es la señal de que se
  reescribió una cadena y se dejaron atrás sus piezas.
- **Compruebe la independencia de cada filtro con varias ramas.** Cuando las ramas representan
  alternativas (un estado es uno de cuatro valores), un solo proceso es correcto. Cuando
  representan condiciones que podrían ser ciertas a la vez, la regla de gana la primera
  coincidencia hace que solo una llegue a aplicarse, y las demás deben extraerse a subprocesos.
  Esta es la auditoría que encuentra el error del §2 en un conjunto que construyó otra persona.
- **Intente enunciar el propósito de cada proceso en una frase.** Aquellos en los que no lo
  consigue son los que abarcan más de un asunto, y son los candidatos a dividirse, no porque estén
  rotos, sino porque son los que nadie se atreverá a cambiar más adelante.

**Qué indicaría una regresión:** un proceso nuevo sin prefijo, o con un prefijo que no está en la
lista acordada; un proceso con disparador manual sin llamador; un filtro con varias ramas cuyas
ramas son condiciones independientes y no alternativas; un proceso nombrado como retirado que
sigue activado; dos procesos cuyos nombres solo difieren en un año; un proceso programado añadido
a una hora en la que ya hay otro que toca los mismos registros.

## Blueprints relacionados

- [Blueprint 010](https://blueprints.coevera.com/es/blueprints/handover-from-sales-to-delivery/) —
  el patrón de despliegue en abanico en la práctica: un cambio de fecha escrito como cuatro
  procesos en lugar de uno, y por qué cada uno necesita un gemelo manual.
- [Blueprint
  009](https://blueprints.coevera.com/es/blueprints/automating-on-integration-owned-fields/) — por
  qué los procesos al cambiar fallan en silencio, qué hace un proceso programado con datos de
  entrada obsoletos y la derivación reejecutable que repara ambas cosas.
- [Blueprint 003](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/) — la
  pregunta que evita desde el principio que el conjunto de automatizaciones crezca: si hace falta
  construir algo o no.

## Preguntas frecuentes

### ¿Cómo se mantiene sostenible un gran conjunto de automatizaciones del CRM?

Empiece por aceptar que el número no lo elige usted. Un proceso de Coevera es un disparador, luego un único nodo de filtro y luego acciones, y un filtro nunca puede ser hijo de una acción, así que no se puede añadir una segunda condición independiente a un proceso que ya tiene una. Hay que traspasarla a otro proceso que lleve su propio filtro. Por tanto, un evento de negocio que necesita tres correcciones sin relación entre sí son tres o cuatro procesos, por construcción. Lo que usted controla de verdad es la legibilidad: etiquete cada proceso por dominio y dele además un prefijo de dominio entre corchetes, porque el nombre es lo que busca la búsqueda de la lista de procesos; haga explícito el tipo de disparador, ya que cada tipo falla de una manera distinta; y dé a cada subproceso un filtro raíz permisivo para que se proteja a sí mismo si alguna vez se ejecuta por separado.

### ¿Por qué un evento de negocio necesita varios procesos del CRM en lugar de uno?

Porque un proceso tiene un solo filtro, y el filtro es una única compuerta IF-THEN-ELSE en la que gana la primera rama que coincide. Piense en una cuenta que pasa de cliente potencial a cliente y que necesita tres correcciones independientes: avisar al propietario si faltan los datos del contacto principal, expandir una abreviatura de región de dos letras al nombre completo para que los informes por país no se dividan, y rellenar las fechas de renovación a partir de un plazo de doce o veinticuatro meses. No son alternativas, son tres cosas que pueden ser ciertas a la vez. Si las pone en un solo proceso, solo se ejecuta la primera rama que coincide, así que un registro que necesita las tres recibe una. La solución es un proceso por cada condición independiente, invocado desde el proceso que detectó el evento.

### ¿Qué significa un disparador 'manual' en los procesos de Coevera?

Ambas cosas a la vez, y esa es la clave. Manual es uno de los cuatro tipos de disparador, junto con registro, programación y formulario en línea, y lo que realmente significa es que el proceso no se dispara por sí solo: por eso una persona puede ejecutarlo desde un registro y otro proceso puede invocarlo mediante un nodo de disparo de proceso. El mismo proceso sirve como subrutina en una cadena automatizada y como herramienta de reparación que alguien ejecuta a mano, sin construirlo dos veces. Por eso cerca de la mitad de los procesos de la entidad más cargada del conjunto examinado (56 de 113) tienen disparador manual, y por eso esa cifra indica una descomposición deliberada y no utilidades en desuso. También por eso cada subproceso debe conservar un filtro permisivo propio en la raíz: el llamador automatizado ya ha establecido el contexto, pero una persona que lo ejecuta de forma independiente no, y el filtro raíz es lo que hace que el mismo proceso sea seguro en ambos sentidos.

### ¿Cómo se auditan automatizaciones del CRM que no ha construido usted?

Trabaje a partir de la forma y no del contenido. Agrupe todos los procesos por prefijo de nombre y fíjese en los que no tienen ninguno, ya que los procesos sin prefijo suelen ser los que se añadieron con prisas. Compruebe si el mismo dominio aparece con dos grafías, que es el fallo silencioso más común de una convención de nombres. Agrupe los programados por hora del día y busque varios en la misma hora, sobre todo los que tocan los mismos registros, porque no hay ninguna garantía de orden entre ellos. Busque en los nombres not used, obsolete, old, temp e iniciales personales, y compruebe después si cada uno está realmente desactivado y no solo etiquetado. Y siga las cadenas de llamadas: un subproceso al que nada invoca está realmente muerto, que es la única forma de proceso muerto que se puede demostrar.

---

Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos
de clientes, sin datos personales.