De la petición del cliente al código entregado, en una sola herramienta
Un cliente informa de un problema. Se convierte en una tarea, un desarrollador lo corrige desde el IDE, el commit queda ligado a la tarea, el trabajo pasa por revisión y pruebas, y cuando llega al paso final se avisa al cliente de que está hecho. Vi conecta cada eslabón de esa cadena: nada se copia a mano y nadie tiene que acordarse de enviar una actualización.
¿Dónde se suele perder una petición del cliente?
Una petición del cliente suele perderse en los traspasos entre herramientas: soporte la registra en un helpdesk, alguien la copia a mano en el gestor de tareas, un desarrollador la corrige en Git y el cliente solo recibe noticias si alguien se acuerda de volver a la primera herramienta. Cada traspaso pierde contexto (qué cliente lo pidió, qué pidió exactamente, qué commit lo corrigió) y el cliente sigue escribiendo "¿alguna novedad?" porque, desde su lado, nada ha avanzado. La solución no es un helpdesk mejor ni un gestor de tareas mejor: es un único registro que viaja desde la petición del cliente hasta el código.
La cadena, eslabón a eslabón
Cada paso lo hace una persona distinta y cada una pasa el mismo registro a la siguiente: sin copiar nada y sin un segundo sistema.
- 1Cliente
Envía un correo a la dirección de Vi de tu organización o rellena un formulario del portal de clientes, y recibe al instante un número de seguimiento y un enlace a una página de estado.
- 2Responsable del equipo
Revisa la solicitud en la bandeja de clasificación y la convierte en trabajo real, escrito con las palabras del propio equipo: una tarea o — si describe varios problemas — un épico con las tareas que necesita, hasta 20. El mensaje original del cliente queda en la conversación de la solicitud en lugar de pegarse en una tarea.
- 3Flujo de trabajo
La tarea entra en tu flujo de trabajo, se asigna automáticamente a la persona con menos carga del rol adecuado y arranca su reloj de SLA, igual que cualquier otro trabajo que entrega tu equipo.
- 4Desarrollador
Elige la tarea en VS Code, Visual Studio, RAD Studio o Lazarus y pulsa Start. Cuando el trabajo está listo pulsa Done: Vi hace commit del cambio con un mensaje como "[#123] Título de la tarea", hace push si el repositorio tiene un remoto de Git y marca su paso como terminado. La tarea avanza; todavía no está cerrada.
- 5Revisor / QA
Revisa, prueba o aprueba en los siguientes pasos de tu flujo de trabajo, tantos como necesite tu proceso. Rechazar devuelve la tarea con un motivo; aprobar la hace avanzar.
- 6Flujo de trabajo
Cuando la tarea (o, en una petición dividida, todas las tareas de su épica) llega al paso final del flujo, la petición cuenta como hecha. Que un desarrollador termine su propio paso nunca cierra por sí solo la petición del cliente.
- 7Cliente
Recibe un correo de que la solicitud está resuelta y la página de estado la muestra como hecha. Por separado llega una encuesta de satisfacción de un clic. Si vuelve a escribir después, el mensaje va a la bandeja de clasificación y tu equipo decide si reabrir el trabajo o empezar algo nuevo.
Dos vistas del mismo registro
Tu cliente y tu equipo miran la misma petición, pero cada uno ve solo lo que le resulta útil.
Lo que ve tu cliente
Un número de seguimiento, uno de cuatro estados sencillos (recibida, en curso, resuelta, cerrada), un porcentaje de progreso y, en una petición dividida, cuántas partes están hechas ("2 de 3"). En el panel de cliente: las respuestas que tu equipo decidió enviarle, además de sus propios mensajes y adjuntos. Sin nombres de agentes, sin pasos internos del flujo y sin la discusión interna.
Lo que ve tu equipo
La tarea completa: paso del flujo, responsable, SLA, comentarios internos, aprobaciones, tiempo dedicado — y en la sección Entregado de la tarea, cada commit hecho para ella, con hash, rama y número de líneas. Una tarjeta de solicitud del cliente en la tarea (y en el épico si la solicitud tiene varias tareas) muestra el número de seguimiento, exactamente lo que el cliente ve ahora, el resultado de satisfacción y la conversación con el cliente, donde responde el equipo.
¿Cómo se vincula la petición del cliente con el código?
La petición del cliente se vincula con el código a través de su tarea: Commit & Close escribe el número de tarea en el mensaje del commit como [#123] y envía los metadatos del commit a esa tarea, así que la petición, la tarea y sus commits forman una sola línea trazable. Del equipo del desarrollador solo salen metadatos (hash, mensaje, rama y número de líneas, y los nombres de archivo si tu organización lo activa). El código fuente nunca sale.
¿Y si una petición son en realidad varios trabajos?
Si una solicitud es en realidad varios trabajos, conviértela en un épico y enumera las tareas que necesita, o divide más tarde una tarea existente en hasta 20 tareas separadas. Cada tarea se asigna como siempre a través de tu flujo, y no se crea ninguna tarea de relleno solo para guardar la conversación: la conversación pertenece a la solicitud. El cliente sigue viendo una sola solicitud, con el progreso como partes hechas sobre el total; cuenta como resuelta solo cuando lo están todas.
Para quién es, y para quién no
Encaja bien
Equipos de software que construyen un producto y dan soporte a sus clientes ellos mismos: agencias, estudios de producto y equipos internos donde el desarrollador que corrige un error está a pocos pasos del cliente que lo reportó. Si tus peticiones de soporte acaban a menudo en cambios de código, esta cadena elimina la mayor parte del trabajo manual a su alrededor.
No es lo ideal
Un gran departamento de soporte independiente que resuelve la mayoría de tickets sin ingeniería, o que necesita teléfono y chat en vivo, centros de ayuda multimarca o macros sobre miles de tickets al día: una suite de helpdesk dedicada lo servirá mejor. Vi tampoco despliega tu código: la cadena termina en el commit, el push y el paso final de tu flujo.
¿Qué plan necesitas?
Commit & Close y las extensiones de IDE están disponibles en todos los planes, incluido Free. El lado del cliente de la cadena (correo a tarea con correo de ticket bidireccional, la bandeja de triaje, el portal de clientes, las páginas de estado, el panel de cliente y los correos automáticos) forma parte del plan Business. Las cuentas de cliente nunca ocupan un asiento, y el correo funciona en la dirección de Vi de tu organización sin un helpdesk ni un servicio de correo externos.
Preguntas frecuentes
¿El Done de un desarrollador avisa al cliente?
No: el Done de un desarrollador termina su propio paso del flujo y lleva la tarea al siguiente; al cliente solo se le avisa cuando la tarea llega al paso final del flujo. Así el cliente oye "resuelta" después de la revisión y las pruebas, no cuando llega el primer commit.
¿Puede el cliente ver los commits o el código?
No: el cliente solo ve el estado y el progreso de la petición y las respuestas que tu equipo le envía. Los commits aparecen dentro de la tarea para tu equipo, e incluso ahí Vi solo guarda metadatos del commit, nunca código fuente.
¿Qué IDE admiten Commit & Close?
Commit & Close ya está disponible para VS Code, Visual Studio, RAD Studio 13 y Lazarus. En cada uno, el desarrollador inicia la tarea, pulsa Done cuando su parte está lista, y Vi hace commit con el número de tarea, hace push si hay un remoto de Git configurado y lleva la tarea al siguiente paso del flujo.
¿Todos los correos se convierten en tareas automáticamente?
No: cada correo espera en la bandeja de clasificación, incluso si viene de alguien que ya tiene cuenta en tu organización, hasta que un administrador lo convierte en tarea o épico, o lo rechaza. El administrador escribe la tarea con las palabras del equipo; el correo original queda en la conversación de la solicitud.
¿Qué recibe el cliente y necesita una cuenta?
El cliente recibe un número de seguimiento, una página de estado que se abre sin iniciar sesión y correos cuando la petición se recibe, se resuelve o se cierra, sin necesidad de cuenta ni de asiento de pago. Si quiere ver todas sus peticiones, responder o adjuntar archivos, entra en el panel de cliente con un enlace de un solo uso que se le envía por correo.
¿En qué se diferencia de la página de helpdesk de Vi?
La página de helpdesk describe las propias herramientas de soporte (la bandeja, el triaje, CSAT y las respuestas predefinidas), mientras que esta página sigue una petición de principio a fin, por el IDE del desarrollador y tus pasos de revisión, hasta volver al cliente. Ambas describen el mismo producto: en Vi, una petición de soporte es una tarea.
¿Vi despliega la corrección en producción?
No: Vi se detiene en el commit, el push y el paso final de tu flujo; el despliegue sigue en tu CI/CD actual. Si publicar forma parte de tu proceso, añade un paso como "Publicado" como paso final del flujo, para que el cliente reciba el aviso solo cuando la corrección ya esté en producción.
Sigue explorando: helpdesk y correo a tarea · cómo funciona Commit & Close · seguridad del código fuente · haz un piloto acotado · planes y precios
Cierra el ciclo con tu cliente: de la petición al código y de vuelta
Empieza gratis en dos minutos. Sin tarjeta de crédito.
Empezar gratis