From customer request to delivered code — in one tool
A customer reports a problem. It becomes a task, a developer fixes it from the IDE, the commit is tied to the task, the work moves through review and testing — and when it reaches the final step, the customer is told it's done. Vi connects every link of that chain, so nothing is copied by hand and nobody has to remember to send an update.
Where does a customer request usually get lost?
A customer request usually gets lost at the handoffs between tools: support logs it in a helpdesk, someone copies it into the issue tracker, a developer fixes it in Git, and the customer only hears back if somebody remembers to return to the first tool. Each handoff drops context — which customer asked, what exactly they asked for, which commit fixed it — and the customer keeps writing "any update?" because, from their side, nothing has moved. The fix is not a better helpdesk or a better tracker; it is a single record that travels from the customer's request all the way to the code.
The chain, link by link
Each step is done by a different person, and each one hands the same record to the next — no copying, no second system.
- 1Customer
Sends an email to your organization's Vi address or fills in a client portal form, and immediately gets a tracking number and a link to a status page.
- 2Team lead
Reviews the request in the triage inbox and converts it into real work, written in the team's own words: a task, or — if it describes several problems — an epic with the tasks it needs, up to 20. The customer's original message stays in the request conversation rather than being pasted into a task.
- 3Workflow
The task enters your workflow, is assigned automatically to the least-loaded person in the right role, and starts its SLA clock — exactly like any other work your team ships.
- 4Developer
Picks the task in VS Code, Visual Studio, RAD Studio, or Lazarus and clicks Start. When the work is ready they click Done: Vi commits the change with a message like "[#123] Task title", pushes it if the repository has a Git remote, and marks their step as finished. The task moves on — it is not closed yet.
- 5Reviewer / QA
Reviews, tests, or approves in the next steps of your workflow — as many as your process needs. Rejecting sends the task back with a reason; approving moves it forward.
- 6Workflow
When the task — or, for a split request, every task in its epic — reaches the final step of the workflow, the request counts as done. A developer finishing their own step never closes the customer's request on its own.
- 7Customer
Is emailed that the request is resolved, and the status page shows it as done. A one-click satisfaction survey follows separately. If they write again after that, the message goes to the triage inbox and your team decides whether to reopen the work or start something new.
Two views of the same record
Your customer and your team look at the same request, but each sees only what is useful to them.
What your customer sees
A tracking number, one of four plain states — received, in progress, resolved, closed — a progress percentage, and for a split request how many parts are done ("2 of 3"). In the customer panel: the replies your team chose to send them, plus their own messages and attachments. No agent names, no internal workflow steps, no internal discussion.
What your team sees
The full task: workflow step, assignee, SLA, internal comments, approvals, time spent — and in the task's Shipped section, every commit made for it, with hash, branch, and line counts. A customer-request card on the task (and on the epic, for a multi-task request) shows the tracking number, exactly what the customer is seeing right now, the satisfaction result, and the conversation with the customer, where the team replies.
How is the customer request linked to the code?
The customer request is linked to the code through its task: Commit & Close writes the task number into the commit message as [#123] and reports the commit's metadata back to that task, so the request, the task, and its commits form one traceable line. Only metadata leaves the developer's machine — hash, message, branch, and line counts, plus file names if your organization turns that on. Source code never does.
What if one request is really several pieces of work?
If one request is really several pieces of work, convert it into an epic and list the tasks it needs, or split an existing task later into as many as 20 separate tasks. Each task is assigned through your workflow as usual, and no placeholder task is created just to hold the conversation — the conversation belongs to the request. The customer still sees a single request, with progress shown as parts done out of the total; it counts as resolved only when every part is.
Who this is for — and who it isn't
A good fit
Software teams that build a product and support its customers themselves — agencies, product studios, and in-house teams where the developer who fixes a bug is only a few steps away from the customer who reported it. If your support requests regularly turn into code changes, this chain removes most of the manual work around them.
Not the best fit
A large standalone support department that resolves most tickets without engineering, or needs phone and live chat, multi-brand help centers, or macros across thousands of tickets a day — a dedicated helpdesk suite will serve that better. Vi also does not deploy your code: the chain ends at commit, push, and your workflow's final step.
Which plan do you need?
Commit & Close and the IDE extensions are available on every plan, including Free. The customer side of the chain — email-to-task with two-way ticket email, the triage inbox, the client portal, status pages, the customer panel, and the automatic emails — is part of the Business plan. Customer accounts never take a seat, and email works on your organization's Vi address without an external helpdesk or mail service.
Frequently asked
Does a developer's Done notify the customer?
No — a developer's Done finishes their own workflow step and moves the task to the next one; the customer is notified only when the task reaches the final step of the workflow. That way the customer hears "resolved" after review and testing, not when the first commit lands.
Can the customer see commits or code?
No — the customer sees only the request's status, progress, and the replies your team sends them. Commits appear inside the task for your team, and even there Vi stores only commit metadata, never source code.
Which IDEs support Commit & Close?
Commit & Close is available today for VS Code, Visual Studio, RAD Studio 13, and Lazarus. In each one a developer starts the task, clicks Done when their part is ready, and Vi commits with the task number, pushes if a Git remote is configured, and moves the task to the next workflow step.
Does every email become a task automatically?
No — every email waits in the triage inbox, even from someone who already has an account in your organization, until an admin converts it into a task or an epic, or rejects it. The admin writes the task in the team's words; the original email stays in the request conversation.
What does the customer get, and do they need an account?
The customer gets a tracking number, a status page that opens without signing in, and emails when the request is received, resolved, or closed — no account or paid seat required. If they want to see all their requests, reply, or attach files, they sign in to the customer panel with a one-time link sent to their email.
How is this different from the Vi helpdesk page?
The helpdesk page describes the support tools themselves — the inbox, triage, CSAT, and canned responses — while this page follows one request end to end, through the developer's IDE and your review steps, back to the customer. Both describe the same product: a support request in Vi is a task.
Does Vi deploy the fix to production?
No — Vi stops at commit, push, and your workflow's final step; deployment stays with your existing CI/CD. If releasing is part of your process, add a step such as "Released" as the final step of the workflow, so the customer is notified only after the fix is live.
Keep exploring: helpdesk and email-to-task · how Commit & Close works · source code security · run a focused pilot · plans and pricing
Close the loop with your customer — from request to code and back
Start free in two minutes. No credit card required.
Start Free