Una plataforma pensada alrededor del caso, no del mensaje
CASUM recibe solicitudes de distintos canales, les aporta contexto y las convierte en unidades de trabajo que un equipo puede asignar, seguir y resolver. Esto es cómo está diseñado para funcionar.
Qué es un caso
El caso es la unidad de trabajo. No es el mensaje que llegó ni la conversación que lo rodea: es la cosa que alguien tiene que resolver, con todo lo necesario para saber si ya está resuelta.
Un mensaje es transporte. Una conversación es contexto. El caso es trabajo. Distinguirlos no es un detalle técnico: es lo que permite que nada se pierda entre canales y que “responder” no se confunda con “terminar”.
- Tiene estado, responsable, prioridad y motivo de resolución.
- Puede existir sin conversación, sin mensaje y sin canal.
- Una conversación puede contener varios casos; un caso puede no tener ninguna.
- Solo el caso responde la pregunta “¿esto está resuelto?”.
De una interacción a un caso resuelto
Cinco etapas describen el camino que sigue una solicitud. Es el enfoque de diseño del producto; no todas las capacidades están implementadas todavía.
- 01
Recibe
Una entrada, muchos orígenes.
Webchat, WhatsApp, formularios, email o API: cada canal es una entrada. La solicitud se persiste tal como llega, se verifica su autenticidad y se descarta lo duplicado.
- 02
Reconoce
Contexto antes que respuesta.
Se identifica al contacto de forma determinística, se conserva el historial y se vinculan conversaciones e interacciones previas. El significado se interpreta en el núcleo, no en el canal.
- 03
Convierte
De interacción a caso.
Una interacción se transforma en un caso con estado, prioridad y estructura. Y cuando no corresponde crear uno, el mensaje queda visible en la bandeja de sin clasificar — nunca se pierde.
- 04
Deriva
Al responsable correcto.
El caso se asigna a un equipo o persona según reglas explícitas, se escala cuando hace falta y conserva su trazabilidad en cada paso. La asignación es una dimensión propia, no un estado escondido.
- 05
Resuelve
Cerrar, no solo responder.
Estados con invariantes, colaboración, seguimiento y auditoría hasta el cierre. Un caso resuelto exige su motivo de resolución: la diferencia entre contestar y terminar el trabajo.
Un solo idioma para todos los canales
Cada canal habla distinto. Los adaptadores traducen lo que llega a un modelo de mensaje único, y a partir de ahí el núcleo deja de preguntar “¿es WhatsApp?”.
El tipo de un mensaje se deriva en el núcleo, no en el adaptador del canal. Así, agregar un canal nuevo no obliga a reescribir la lógica de negocio: solo hace falta enseñarle al sistema a traducir ese origen.
Por qué importa
Un modelo canónico evita que las reglas del negocio queden atadas a las particularidades de cada plataforma. El proceso continúa más allá del mensaje que lo inició.
Saber con quién estás hablando
La identidad se modela en tres capas. El objetivo es reunir el historial sin destruir información: siempre se puede reconstruir de dónde vino cada dato.
Identidad de canal
Cómo aparece un contacto en cada canal: un número, un correo, un identificador. Es el punto de entrada, no la persona.
Contacto
La persona u organización detrás de una o varias identidades de canal. Reúne el historial disperso en un solo lugar.
Agrupación reversible
Cuando dos contactos resultan ser el mismo, se fusionan sin reescribir la historia. Y si fue un error, se puede deshacer.
Ayudar sin decidir por vos
CASUM separa deliberadamente las automatizaciones reactivas de los procesos con estado. Una cosa reacciona a un evento; la otra sostiene el trabajo en el tiempo.
Automatización reactiva
Reglas acotadas que responden a un evento puntual: etiquetar, notificar, derivar. Se disparan y terminan. Nada se ejecuta por decisión implícita.
Procesos con estado
El caso avanza por una máquina de estados con invariantes. El control operativo queda siempre en las personas, no en un motor que decide solo.
No es un constructor de bots ni un motor de reglas que opera por su cuenta. El humano queda en el centro de las decisiones.
Decisiones de arquitectura, no promesas
Estos son enfoques de diseño del producto. Se presentan como cómo está pensado para funcionar, no como capacidades ya entregadas.
El caso es el centro
La unidad de trabajo no es el mensaje ni la conversación: es el caso. Puede existir sin conversación y una conversación puede contener varios casos. Solo el caso responde “¿esto está resuelto?”.
Omnicanalidad real
Los canales son entradas que se normalizan a un modelo canónico único. El núcleo no pregunta “¿es WhatsApp?”, pregunta qué puede hacer ese canal. El proceso continúa más allá del mensaje.
Contexto unificado
Identidad en tres capas —canal, contacto y agrupación— con fusión reversible. Contactos, conversaciones, casos y archivos relacionados, sin reescribir la historia.
El humano en el centro
Automatización reactiva y acotada, separada de los procesos con estado. Nada se ejecuta por decisión implícita: el control operativo siempre queda en las personas.
Trazabilidad de origen
Cada vínculo, asignación, cambio de estado y decisión puede quedar registrado en un historial append-only, pensado para ser auditado, no solo consultado.
SaaS y multi-tenant
Aislamiento estructural por organización desde el modelo de datos: contexto obligatorio, filtrado en aplicación, RLS y claves compuestas por tenant. Diseñado para operar múltiples organizaciones sin que se crucen.
¿Querés ver cómo se aplica a tu operación?
Contanos qué necesitás resolver y coordinamos una demostración del enfoque.