> ## Documentation Index
> Fetch the complete documentation index at: https://docs.headlesslabs.xyz/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Ciclo de vida de tickets

> Cómo Headless abre, reclama, transcribe y cierra un ticket y qué conserva cuando elimina el canal.

El flujo implementado tiene cuatro etapas: apertura desde el panel, asignación del caso, transcripción bajo demanda o al cerrar y cierre con borrado diferido del canal. El estado del ticket queda asociado al servidor incluso después del borrado programado.

**1. Abrir**

El miembro pulsa el botón del panel. Si `require_reason` está activo, envía el motivo obligatorio y, si quiere, evidencia de texto. Headless crea un canal privado y persiste el registro.

**2. Reclamar**

Un rol de soporte configurado o alguien con `Manage Channels` usa el control de claim. El reclamo se registra en el ticket activo.

**3. Generar transcript**

`.ticket transcript` o el cierre intenta enviar el transcript de los últimos mensajes seleccionados al canal de logs explícito. La transcripción requiere que esté habilitada.

**4. Cerrar**

`.ticket close [motivo]` cierra el registro, intenta el transcript y el DM de cierre, publica el control de ticket cerrado y programa la eliminación del canal según `close_delete_seconds`.

## Entrega de transcripts

El canal de logs debe configurarse expresamente con `.ticket log #canal`; el canal del panel no es un fallback. `.ticket transcript` crea un archivo con hasta `transcript_limit` mensajes recientes. Si los transcripts están desactivados o no existe un canal de logs utilizable, Headless no tiene dónde enviarlo.

### Configura el canal de logs

```headless-command Syntax theme={null}
.ticket log <channel>
```

```headless-command Example theme={null}
.ticket log #ticket-logs
```

### Genera un transcript

```headless-command Syntax theme={null}
.ticket transcript
```

```headless-command Example theme={null}
.ticket transcript
```

## Cerrar un ticket

`.ticket close` cierra el registro, intenta generar el transcript y enviar el DM de cierre, publica el control de ticket cerrado y programa el borrado del canal. Si falla la generación o el envío del transcript o del DM, Headless no revierte el estado cerrado; esas notificaciones son best-effort.

```headless-command Syntax theme={null}
.ticket close [reason]
```

```headless-command Example theme={null}
.ticket close Resuelto
```

> [!WARNING]
>
> `.ticket close` y `.ticket transcript` no hacen una validación staff separada. Cualquier miembro con acceso al canal privado puede invocarlos; limita el acceso con overwrites de Discord y protege el canal de logs.

## Retraso del borrado

El retraso inicial es de 10 segundos; el rango es de 0 a 86.400 segundos. `0` solicita eliminar el canal inmediatamente. El registro cerrado se conserva en el almacenamiento del servidor.

```headless-command Syntax theme={null}
.ticket close-delay [seconds=10]
```

```headless-command Example theme={null}
.ticket close-delay 3600
```

> [!WARNING]
>
> Un retraso de cero solicita el borrado inmediato. El registro almacenado no conserva el canal eliminado ni sus mensajes de Discord.

## Funciones que no existen

No hay inactividad configurable, avisos de inactividad, auto-cierre, reapertura, traslado, borrado automático independiente ni historial de reaperturas. El borrado diferido solo ocurre después de cerrar.

## Relacionado

* [Comandos y permisos](/docs/server/tickets/commands.md)
* [Opciones](/docs/server/tickets/options.md)
* [Acceso y privacidad](/docs/server/tickets/access.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.