OnClockOnClock

Flujo por correo

El correo es el canal que más usan los equipos. OnClock lo convierte en un canal operativo real: pedir backlog, aprobar, preguntar el estado del proyecto o cerrar etapas — todo desde la bandeja de entrada, sin abrir la app.

¿Por qué email?

La mayoría de integrantes no viven en el PMO. Viven en Gmail, Outlook o el correo de la empresa. Si la gestión les obliga a cambiar de contexto, la adopción cae. Con el flujo de correo de OnClock:

  • Un integrante pide 3 horas más en su etapa escribiendo un correo normal.
  • El PMO aprueba respondiendo «aprobado» desde su móvil en 5 segundos.
  • El agente hace todo el trabajo de fondo: crear el BacklogRequest, extender el timer, crear la tarea, actualizar el estado.

Configurar el buzón

Sigue las instrucciones de Primeros pasos → Conectar email. Necesitas un buzón IMAP dedicado (ej. pmo@tuempresa.com) con credenciales IMAP y SMTP.

Una vez configurado, el poller de correo corre cada 2 minutos buscando nuevos mensajes. Los mensajes se asocian al proyecto del integrante que los envía.

Un buzón por empresa, no por proyecto
Usa un único buzón para toda la empresa. El agente detecta automáticamente a qué proyecto pertenece el correo según el sender y los proyectos en los que está invitado.

Pedir backlog por correo

Cualquier integrante del proyecto puede pedir una extensión de tiempo escribiendo al buzón. Ejemplos de correos que el agente entiende:

Hola, necesito 4 horas más en la etapa de diseño. El cliente cambió el logo y tengo que refrescar tres pantallas. Gracias.

Qué pasa cuando envías este correo:

  1. El poller lo detecta y lo clasifica como backlog_request.
  2. Valida que el sender sea miembro de un proyecto activo.
  3. Extrae el motivo, las horas y la etapa (si se mencionan).
  4. Crea un BacklogRequest en estado pending.
  5. Notifica a los PMO del proyecto por correo con un resumen claro.
  6. Responde al solicitante confirmando que la petición está registrada.

Aprobar / rechazar por correo

Cuando el PMO recibe el correo de notificación, puede responder directamente:

Re: [OnClock] Backlog pendiente: Proyecto Alpha — Extensión etapa diseño

aprobado

O rechazar con motivo:

Re: [OnClock] Backlog pendiente: Proyecto Alpha — Extensión etapa diseño

rechazado, la etapa ya está cerrada y el cambio se verá en la siguiente iteración

El poller detecta el intent backlog_review, valida que el sender tenga rol PMO/Admin, y aplica la decisión:

  • Si aprobó: extiende el timer de la etapa, crea la tarea asociada con la duración solicitada, reactiva el proyecto si estaba cerrado.
  • Si rechazó: marca el request como rechazado y guarda el motivo como review_note.
  • En ambos casos: envía confirmación al solicitante.
Palabras clave reconocidas
Para aprobar: «aprobado», «apruebo», «sí», «si apruebalo», «ok aprobado». Para rechazar: «rechazado», «rechazo», «no autorizo», «denegado». El clasificador es tolerante — entiende variaciones y frases compuestas.

Preguntar al agente

Cualquier miembro del proyecto puede escribirle preguntas al buzón. Ejemplos:

¿cómo va el proyecto Alpha esta semana?

¿quién está asignado a la tarea del logo?

pásame el listado de tareas pendientes de mi etapa

¿cuántas horas me quedan en mi timer?

El agente responde en el mismo hilo en segundos. Respeta los permisos del sender: solo muestra información de proyectos en los que está invitado.

Cierre de etapas por correo

El agente monitorea automáticamente el progreso de cada etapa. Cuando detecta que todas las tareas están completadas, envía al PMO un correo con el reporte de cierre:

  • Tiempo real vs. planificado.
  • Tareas completadas e incidencias.
  • Carga por integrante.
  • Bloqueos que hubo.

El PMO responde «sí, cierra» y la etapa queda cerrada. Si quiere matizar, puede escribir algo como «ciérrala pero con incidencia de retraso en testing» y el agente crea la incidencia antes de cerrar.

Cómo funciona el clasificador

El poller usa un clasificador LLM ligero (Gemini Flash Lite por defecto) que categoriza cada correo en uno de 5 intents:

  1. task_completed — el integrante dice que terminó una tarea.
  2. stage_closed — un PMO cierra una etapa.
  3. backlog_request — petición de extensión.
  4. backlog_review — aprobación/rechazo de un backlog existente.
  5. info_request — pregunta sobre el proyecto.
  6. other — no encaja, se ignora.

Cada intent tiene un umbral de confianza mínimo (0.55–0.7). Si no se alcanza, se clasifica como other y el correo se archiva sin acción.

Seguridad del correo

  • Sender verification: el agente solo actúa si el email del sender coincide con un usuario registrado en el tenant y miembro del proyecto.
  • No acciones destructivas: el flujo de correo nunca elimina datos, solo crea o modifica.
  • Rol requerido: operaciones privilegiadas (aprobar backlog, cerrar etapas) exigen rol PMO/Admin confirmado en el tenant.
  • Fallos silenciosos: si algo va mal durante el procesamiento, el email ingestion nunca se rompe — el correo se registra como no procesado y puede revisarse en los logs.