Un artículo basado en un ticket técnico resuelto debe documentar un síntoma, entorno verificado, solución probada y comprobación del resultado. Elimina datos del cliente y limita las instrucciones a las condiciones demostradas.
Elegir un caso reproducible
Confirma causa, solución y resultado. Cerrar un ticket no demuestra éxito. Sin confirmación del cliente o prueba, no presentes los pasos como verificados.
Elige un síntoma. No combines problemas distintos solo porque los atendió el mismo equipo.
Anonimizar el material
Elimina nombres, direcciones, documentos privados, números de cuenta, identificadores de sesión y secretos técnicos. Revisa capturas aparte.
Conserva producto, versión, entorno, síntoma y condición desencadenante. Describe de forma segura la configuración que identifique a un cliente, manteniendo la causa relevante. No publiques la correspondencia.
Usar síntoma–entorno–solución
- Síntoma: qué observa el usuario y cuándo.
- Entorno: producto, versión, sistema y configuración pertinente.
- Condición de coincidencia: cómo reconocer el caso aplicable.
- Solución: pasos comprobados para este caso.
- Verificación: resultado esperado de éxito.
- Alcance y escalado: cuándo detenerse o contactar con soporte.
Diagnosticar no equivale a reparar. Recopilar datos no es la solución. Para proteger información, remite al procedimiento verificado del producto.
Ejemplo ficticio
No describe un fallo de Semly. En una aplicación documental 2.4.0, una lista abierta omite un documento nuevo tras un cambio de permisos confirmado. Recargar actualiza la lista, no modifica permisos.
La sesión comenzó antes del cambio. La condición de coincidencia es que el mismo documento aparezca en una vista recién abierta para la misma cuenta.
Guarda el trabajo pendiente y recarga según las instrucciones reales de la aplicación. Comprueba que el documento aparezca y se abra con el permiso correcto. Si falta también en una vista nueva, el caso no está confirmado y requiere otro diagnóstico.
Explicar límites
Incluye solo versiones y configuraciones probadas. Una interfaz parecida no demuestra soporte en otra plataforma.
No prometas que recargar arregla permisos o datos ausentes. Otras causas tienen otros procedimientos. La condición evita repetir pasos irrelevantes.
Probar como un lector
Un revisor técnico reproduce el caso de forma segura y sigue el artículo sin conocer el ticket. Las condiciones y el éxito deben ser explícitos.
Si faltan datos, completa entorno y coincidencia. La instrucción no debe depender de conocimiento exclusivo del autor.
Registrar revisión y traducciones
Guarda fecha y responsable. Después de cambios de producto, verifica condiciones y pasos.
Las traducciones mantienen versión, síntoma, orden y criterio de éxito. Los mensajes deben coincidir con la interfaz real. Una causa diferente no es un apéndice sin relación: constituye otro caso.
