Hay un tipo de proceso que casi toda empresa gestiona por email. No porque alguien decidió que el email era la mejor herramienta. Sino porque el proceso empezó pequeño, con una solicitud aquí, una aprobación allá, y cuando el equipo se dio cuenta, ya tenía una cadena de 47 emails con asunto "Re: Re: Re: Aprobación pedido #312".
El email es excelente para comunicación. Pésimo para gestión de procesos. No tiene etapas, no tiene responsables definidos, no tiene plazos automáticos, no tiene visibilidad de estado y, principalmente, no tiene memoria confiable. Cuando alguien pregunta "¿quién aprobó esto?", la respuesta involucra 15 minutos de búsqueda y la frase "creo que fue Marcos, pero no estoy seguro".
Veamos los 5 procesos que más sufren con esto — y cómo debería funcionar cada uno.
1. Aprobación de gastos y compras
Cómo funciona por email
Alguien necesita comprar algo. Manda un email al gestor: "Necesito aprobar la compra de 10 licencias del software X, valor R$ 4.500." El gestor responde "ok" — a veces desde el celular, sin siquiera leer el adjunto con el presupuesto. Si el valor requiere aprobación del financiero, el solicitante reenvía el hilo. El financiero responde tres días después con "aprobado, pero necesita tres presupuestos." El solicitante manda los presupuestos. Uno de ellos cae en spam. El proceso se traba.
Qué sale mal
- Aprobaciones verbales o por "ok" en email, sin registro formal
- Nadie sabe en qué etapa está la solicitud
- Valores por encima del límite pasan sin la segunda aprobación porque la regla está en una planilla que nadie consulta
- Cuando la auditoría pide evidencia de aprobación, alguien necesita buscar emails de hace 6 meses
Cómo debería funcionar
Un formulario estructurado con campos obligatorios: descripción, valor, centro de costo, presupuestos adjuntos. Reglas claras de autoridad: hasta R$ 5.000, aprueba el gestor directo; por encima, va al financiero. Cada aprobación registrada con fecha, hora y justificación. SLA de 48h con alerta automática para aprobaciones pendientes. Timeline completa accesible por cualquier auditor.
2. Onboarding de clientes
Cómo funciona por email
El comercial cierra el contrato y manda un email al equipo de operaciones: "Nuevo cliente: Empresa ABC. Contrato adjunto. Iniciar onboarding." Operaciones responde preguntando qué servicios fueron contratados. El comercial reenvía otro hilo donde eso se discutió. Alguien del soporte técnico es copiado para configurar el ambiente. Tres días después, el soporte pregunta: "¿Cuál es el email de acceso del cliente?" Nadie sabe. El cliente llama preguntando cuándo va a recibir el acceso. Vergüenza general.
Qué sale mal
- Información dispersa entre 4 hilos diferentes
- Nadie sabe si el ambiente ya fue configurado
- El cliente no tiene visibilidad de nada — llama para preguntar
- Cuando algo se atrasa, empieza el juego de "yo mandé el email, tú no respondiste"
- Clientes diferentes reciben experiencias de onboarding completamente diferentes, dependiendo de quién operó
Cómo debería funcionar
Un case creado automáticamente cuando el contrato se cierra. Etapas claras: recolección de datos, configuración de ambiente, capacitación, go-live. Formulario externo para que el cliente llene datos sin mandar email. Tareas asignadas a cada equipo con plazo. Portal para que el cliente acompañe el progreso. SLA por etapa. Todos los onboardings siguiendo la misma estructura, independientemente de quién esté operando.
3. Solicitud de vacaciones y licencias
Cómo funciona por email
El empleado manda email al gestor: "Me gustaría tomar vacaciones del 15 al 30 de julio." El gestor responde: "Voy a verificar con RRHH." Reenvía a RRHH. RRHH responde que el período está disponible, pero pide que el empleado llene el formulario del sistema de asistencia. El empleado lo llena. El gestor olvida aprobar en el sistema. RRHH no procesa. El 14 de julio, el empleado pregunta si está todo listo. Nadie sabe.
Qué sale mal
- Aprobación informal por email, sin registro en el sistema oficial
- RRHH depende del gestor para aprobar en el sistema, y el gestor olvida
- Conflictos de vacaciones porque nadie cruzó las fechas del equipo
- El empleado descubre que las vacaciones no fueron procesadas la víspera
- Cuando el volumen aumenta (fin de año), RRHH se convierte en cuello de botella respondiendo emails uno a uno
Cómo debería funcionar
Formulario de solicitud con campos de período, tipo de licencia y justificación. Verificación automática de conflictos con otros miembros del equipo. Flujo de aprobación: gestor aprueba, RRHH valida saldo de días y procesa. Notificación automática al empleado en cada etapa. Calendario integrado mostrando quién está de vacaciones cuándo. Cero emails. Cero olvidos.
4. Apertura de tickets internos (TI, facilities, administrativo)
Cómo funciona por email
"Mi monitor no funciona." Email a ti@empresa.com. El equipo de TI tiene 47 emails no leídos en esa bandeja. Alguien responde "Voy a verificar" el martes. El miércoles, el solicitante manda otro email: "¿Alguna novedad?" Nadie responde porque quien dijo "voy a verificar" salió de vacaciones. El jueves, el solicitante manda con copia al gestor de TI. Ahora el gestor necesita reconstruir lo que pasó leyendo un hilo de 8 emails.
Lo mismo pasa con facilities ("El aire acondicionado de la sala 3 está con defecto"), administrativo ("Necesito una credencial nueva") y cualquier área que recibe solicitudes internas por email.
Qué sale mal
- Bandeja de email compartida sin dueño: emails caen en el limbo
- Sin priorización: un monitor roto compite con un servidor caído
- Sin rastreo: nadie sabe cuántos tickets están abiertos, cuál es el tiempo promedio de resolución, cuáles quedan olvidados
- Sin accountability: cuando el ticket desaparece, nadie es responsable
- Cuando alguien sale de vacaciones, los tickets que estaban con esa persona simplemente se detienen
Cómo debería funcionar
Formulario de apertura de ticket con tipo, prioridad, ubicación y descripción. Asignación automática por tipo (hardware va para Fulano, red para Ciclano). SLA por prioridad: crítico en 4h, normal en 48h. Dashboard para que el gestor vea todos los tickets abiertos, por estado y por responsable. Notificación automática al solicitante cuando el ticket avanza. Reporte mensual de volumen, tiempo de resolución e ítems recurrentes.
5. Revisión y aprobación de documentos
Cómo funciona por email
Alguien manda un contrato por email: "Adjunto para revisión." El revisor lo descarga, hace cambios en Word con control de cambios y lo devuelve. El autor acepta algunos cambios, rechaza otros y manda la "versión 2." El revisor recibe, pero tenía la versión del email anterior abierta. Hace cambios en la versión equivocada. Ahora existen dos versiones 2. Alguien manda una "versión final." Después aparece la "versión final v2" y, inevitablemente, la "versión final definitiva ESTA."
Qué sale mal
- Control de versiones inexistente: nadie sabe cuál es la versión más reciente
- Comentarios y cambios dispersos en múltiples emails
- Aprobación por email ("ok, puede seguir") sin registro formal
- Documentos confidenciales circulando como adjuntos de email — sin control de quién accedió
- Cuando alguien pregunta "¿quién revisó este contrato y cuándo?", la respuesta tarda 30 minutos
Cómo debería funcionar
Documento enviado para revisión dentro de un case, con versionamiento automático. Cada versión registrada con fecha y autor. Comentarios vinculados al documento, no a un hilo de email. Flujo de aprobación formal: revisor aprueba o solicita cambios, con comentario obligatorio. Historial completo de quién vio, comentó y aprobó. Control de acceso por permiso, no por "quién estaba en la copia del email."
El patrón que conecta los 5
Si notó, los mismos problemas aparecen en los cinco procesos:
- Falta de visibilidad: nadie sabe en qué etapa está
- Falta de rastreabilidad: no existe historial confiable
- Falta de accountability: cuando algo se atrasa, nadie es formalmente responsable
- Falta de estandarización: cada persona lo hace de forma diferente
- Falta de automatización: todo depende de que alguien se acuerde de hacerlo
El email no resuelve ninguno de estos problemas porque no fue hecho para eso. El email es una herramienta de comunicación, no de gestión.
Qué usar en su lugar
Los cinco procesos anteriores tienen algo en común: son repetitivos, involucran múltiples etapas, múltiples participantes y necesitan rastreabilidad. Ese es exactamente el tipo de problema que una plataforma de orquestación de cases resuelve.
En CaseFy, cada uno de estos procesos puede configurarse como un template: con etapas definidas, campos obligatorios, reglas de automatización, SLAs, permisos y timeline auditable. Cada solicitud se convierte en un case. Cada case tiene su historia completa, de inicio a fin.
No es necesario implementar los cinco a la vez. Empiece por el proceso que más duele — el que genera más emails, más cobros y más "¿quién aprobó esto?". Configure el template, ejecútelo por dos semanas y vea la diferencia.