Done doesn't mean complete. Awaiting feedback status and star ratings create an explicit closure process that eliminates the "I thought you were done" conversations.
A feedback loop in ticket management is a workflow state where the assignee marks work complete and the beneficiary rates it before the ticket closes. Without a feedback loop, "Done" means the assignee decided it's done — which may or may not match what the beneficiary actually received.
The feedback loop exists because different stakeholders define "done" differently. A developer considers code deployed as done. A product manager considers a feature accepted as done. A client considers an invoice paid as done. One status cannot express three definitions — so the feedback loop adds a structured review step between Done and Closed.
The feedback loop is a simple concept: when work is marked Done, it doesn't close immediately. It moves to "Awaiting Feedback" — a holding state where the beneficiary (the person who requested or will use the work) rates it 1-5 stars.
Here's the flow:
This sounds strict. In practice, it creates something most teams lack: an explicit sign-off process.
Without a feedback loop, work gets marked "done" and forgotten. The assignee moves on. The beneficiary never checks. Months later, someone finds the ticket and says "this was never finished."
With a feedback loop, this can't happen. The ticket stays in Awaiting Feedback until the beneficiary explicitly closes it. If the beneficiary reopens it with a low rating, the assignee knows exactly what needs to be fixed and why.
This is especially valuable for:
Client-facing work — When a client rates work 3 stars instead of 5, you get immediate feedback about what didn't meet expectations before the project closes completely.
Internal deliverables — When a designer delivers assets to a developer, the developer rates the work. If the assets are missing something, it gets flagged immediately — not three sprints later when someone discovers the issue.
Cross-team dependencies — When marketing sends copy to design for a campaign landing page, design rates the copy. If the copy doesn't match the brief, design reopens it with feedback. No assumptions.
The star rating isn't a satisfaction survey. It's a quality gate.
5 stars — Work meets expectations, ready to close. Beneficiary is satisfied.
4 stars — Work is acceptable but with minor notes. Closes automatically but feedback is recorded.
3 stars — Work is acceptable but beneficiary wants minor changes. Ticket reopens with feedback — assignee addresses notes and resubmits.
2 stars or below — Work doesn't meet expectations. Significant issues. Ticket reopens with detailed feedback. Assignee and beneficiary discuss before resubmitting.
In practice, most completed work lands at 4-5 stars. The 1-3 star cases are where the feedback loop actually adds value — catching issues before they're buried in closed tickets.
A digital agency was managing a website redesign project. Twenty-three tickets, multiple rounds of revisions, tight deadline. Without a feedback loop, the process looked like this:
With a feedback loop, the process looked like this:
The difference: issues were caught before project closure, not months later when the client found them.
"Won't this slow us down?"
It adds one step. The assignee finishes work, notifies the beneficiary, waits for a rating. Most ratings happen within hours. The alternative — rework after closure — is much slower.
"What if beneficiaries never rate?"
Set expectations: if no rating within 48 hours, a reminder goes out. If no rating within 5 business days, ticket auto-closes at 4 stars (acceptable but not exceptional). You can configure the threshold for your team.
"What if someone rates everything 1 star?"
That's a conversation, not a system problem. If someone consistently rates work low, the team discusses why. Is the brief unclear? Are expectations misaligned? The feedback loop surfaces the issue so you can fix the root cause.
Here's how to start:
Configure the status: In Sunday, Done moves to Awaiting Feedback automatically. Configure your feedback threshold (we recommend 3 stars minimum to close).
Set expectations: When a ticket moves to Done, the beneficiary gets notified with context: what was delivered, what to review, how to rate.
Train the team: Not everyone understands the feedback loop initially. Explain that it's not a performance evaluation — it's a quality gate. The goal is to catch issues before they become problems.
Use the data: Over time, you'll see patterns. If certain types of work consistently get low ratings, the issue is probably in the brief or the process, not the execution. Use feedback data to improve upstream.
The feedback loop is simple in concept: work isn't done until the beneficiary says it's done. In practice, it eliminates the most common source of project overruns and client dissatisfaction: work that slips through without explicit sign-off.
Want to see the feedback loop in action? <a href="/dashboard" className="text-[#D6BFA3] hover:underline">Try Sunday's ticket management platform</a> — set up your first feedback loop in under 5 minutes.
Try Sunday's ticket management platform — start free, upgrade when you're ready.
Start for free