Elegí el ticket destino: los mensajes de los demás se moverán a ese hilo y en la bandeja quedará un solo ticket. Es reversible.
| Alias/Mail | Asunto | Ticket | Último evento | Estado/Agente |
|---|
Cargando tickets…
No se encontraron tickets con esos filtros
Whitelist de remitentes
Empresas
27 empresas registradas
Actualizaciones
Capturado del SAC: —.
| Producto | Versión | Código | Fecha |
|---|---|---|---|
| Cargando… | |||
—
Agregar documentación
Se va a indexar con PageIndex y quedará disponible para el asistente.
Cómo funciona el sistema
Es una máquina virtual con Ubuntu 24.04 alquilada a Don Web, alojada en Argentina. Acá corre todo lo demás: la base de datos, el orquestador de workflows, el buscador de manuales y el CRM que estás viendo.
- IP
- 149.50.149.199
- Hardware
- 4 CPU · 8 GB RAM · 35 GB SSD
- Dominio
- crm.accesspower.com.ar
Es la base de datos donde vive todo lo persistente: empresas, tickets, emails, notas internas, diagnósticos del asistente, feedback de casos cerrados. Si algo tiene que sobrevivir a un reinicio, está acá.
Incluye búsqueda por texto completo (FTS) sobre los ~35K correos históricos y capacidad de almacenar embeddings para búsqueda semántica futura.
- Tipo
- nativo (no Docker)
- Base
- accesspower_db
- Tablas principales
- companies, threads, messages, crm_emails, crm_diagnostics, knowledge_cases
N8N es una plataforma de automatización que permite conectar servicios (email, base de datos, APIs, Claude, webhooks) armando flujos visuales llamados workflows. N8N permite diseñar flujos de trabajo que, por ejemplo, ejecuten la siguiente secuencia: "cuando llega un email → guardalo en la Base de Datos" o "si el agente consulta a Claude → revisá la documentación, el historial, las notas internas y generá una respuesta acorde al System Prompt". En ACCESS POWER hay 8 workflows en producción que cubren todo el ciclo de un ticket:
Cada 5 minutos revisa la casilla soporte@accesspower.com.ar y guarda los mensajes nuevos en la base. Usa POP3 (no IMAP) a propósito: así los emails siguen apareciendo como "no leídos" en Outlook del equipo.
Cuando entra un email nuevo, le pregunta a Claude Haiku 4.5 de qué tipo es (consulta, reclamo, factura, etc.) y a qué empresa corresponde. El ticket queda en la bandeja ya etiquetado.
Cuando el agente abre un ticket y pide ayuda, este workflow arma el prompt con 5 fuentes de contexto: email actual + historial de la empresa, notas internas previas, casos resueltos similares (knowledge_cases), feedback negativo histórico, y extracto de manuales (PageIndex). Claude Sonnet 4.6 devuelve un borrador; el agente lo revisa y lo envía por Outlook.
Cada respuesta de Claude tiene botones 👍/🤚/👎 inline. Si el agente incluye la respuesta correcta o una aclaración, se proyecta automáticamente a knowledge_cases vía trigger DB — Claude la tiene en cuenta en casos similares. El feedback negativo también alimenta el prompt: Claude evita repetir interpretaciones ya marcadas como incorrectas.
Tarea de mantenimiento: mantiene viva la conexión a PostgreSQL para que los demás workflows no tengan latencia de reconexión cuando hay poco tráfico.
Cada vez que creás, editás o eliminás una empresa en la sección Clientes, o asignás una empresa existente a un ticket, este workflow se encarga de persistir el cambio en la base.
Cuando el agente adjunta un screenshot al chat con el asistente (por ejemplo, la captura de un error), este flujo manda la imagen a Claude Sonnet 4.6 con capacidad vision. Claude interpreta lo que se ve y lo considera en su respuesta, sin que el agente tenga que describir la captura con palabras.
Cuando alguien sube un PDF desde el botón "Agregar PDF" en la sección SAC, este flujo valida el archivo, lo guarda en la carpeta del producto que corresponde, lo indexa con PageIndex y lo deja disponible para Claude. Todo desde el CRM, sin tocar el servidor.
Los manuales PDF no están guardados como archivos planos — se indexan para que el asistente pueda saltar directo al capítulo relevante de cada consulta. El método que usamos se llama PageIndex.
PageIndex extrae la tabla de contenidos de cada PDF (si la trae embebida) o la infiere automáticamente por encabezados. Con eso arma un árbol jerárquico de secciones. Cuando llega una consulta, el asistente recorre ese árbol como lo haría un humano buscando en un libro — no corta el texto en chunks ciegos como los sistemas clásicos basados en vectores.
Todo el proceso corre local con PyMuPDF. No llamamos a ninguna API paga para indexar: costo $0.
- PDFs indexados
- 248 únicos
- Distribución
- BAS CS 151 · QP 73 · QPR 24
- Actualización
- incremental — nuevos PDFs se suman al catálogo sin re-indexar todo
Todo lo que el asistente sabe para ayudar al equipo viene de estas 5 fuentes — se inyectan todas al prompt cada vez que Claude responde:
knowledge_cases): feedback 👍/🤚/👎 con texto del agente — saber sobre cómo responder.La clave del diseño es el loop de feedback: cada anotación del equipo (NI + feedback por respuesta) se guarda en la base y se proyecta al siguiente caso. El sistema no es estático — aprende con cada ticket.
Cada agente tiene su propio usuario, contraseña y avatar. El login es con cookie firmada (7 días) — sin popup nativo del browser. Desde Información del sistema → Mi perfil cada uno puede cambiar su nombre, email, usuario y contraseña.
Así el equipo trabaja coordinado en los cambios importantes del ticket sin pisarse la vista de qué leyó cada uno.
Las empresas se pueden organizar en 3 niveles. Cada nivel tiene un rol distinto en cuanto a si recibe tickets y cómo se calculan sus métricas:
Las métricas agregadas (% errores, evolutivo consultas/mes, % resolución de Claude) se calculan con la fórmula correcta: Σ(absolutos) / Σ(totales) × 100 — nunca promedio de promedios. Endpoint /api/companies/{id}/metrics con CTE recursivo sobre el sub-árbol.
Configuración
Infraestructura y conexiones del sistema
| Nombre | Usuario | Rol | Último login | Ingreso | Bandeja | Acciones | |
|---|---|---|---|---|---|---|---|
| Cargando usuarios… | |||||||
Crear usuario
Los roles controlan qué puede hacer cada agente en el CRM.
Altas (independientes)
Fusionar empresas duplicadas
Une dos fichas en una sola — quedan como una única empresa.
- Todos los tickets, hilos históricos, dominios y sucursales de la origen pasan a la destino. Nada se borra: sólo cambia de empresa.
- La ficha de la empresa origen deja de existir — ya no aparece como entidad separada en el sistema.
Es un nombre para organización interna del equipo — lo ven todos los agentes en la bandeja y el detalle. No cambia el asunto del mail que ve el cliente.
Mi Perfil
Tus datos, notificaciones y firma. La contraseña se cambia desde Información del sistema.
Contexto para asistente
Las tres piezas que modelan cómo responde Claude: el system prompt (instrucciones generales), las notas internas del equipo y el feedback acumulado sobre sus respuestas.
| Fecha | Usuario | Cliente | Ticket / Nota | Acciones | |
|---|---|---|---|---|---|
| Cargando notas… | |||||
| Fecha | Usuario | Empresa | Valoración | Solución / Mensaje | Acciones | |
|---|---|---|---|---|---|---|
| Cargando feedback… | ||||||
Borradores
Mails que empezaste a escribir y todavía no enviaste. Tocá uno para abrir el ticket y terminar de enviarlo.
No tenés borradores
Cuando empieces a escribir una respuesta y salgas del ticket, va a aparecer acá.
Bandeja
—
No hay mensajes en los últimos 30 días
Papelera
Los tickets se eliminan definitivamente a los 30 días
La papelera está vacía
