Giving a client access to your bug tracker
Clients report bugs whether or not you give them somewhere to do it. The only real question is whether those reports land in the tracker or arrive at 9pm as a screenshot with the caption "this is still broken".
Give the client read-only access to their own project, ask them for observations rather than diagnoses, and keep priority-setting on your side. The failure mode is not clients breaking things — it is clients having nowhere to report things, so the reports arrive in five different channels instead.
Why the default is "no access", and why it's wrong
Most teams keep clients out of the tracker for two reasons, and only one of them is about the client.
The first is cost. If a tool charges per seat, the occasional participant who logs in twice a month is the hardest seat to justify — so they don't get one, and their bug reports arrive as email instead. This is the single most common reason small teams end up with bugs scattered across channels, and it is a pricing artefact rather than a decision anyone made deliberately.
The second is exposure. If the only options are full access or nothing, letting a client in means letting them reassign work, change priorities, close bugs and see every other project on the install. That is a reasonable thing to refuse. But it is an argument against that permission model, not against client access.
What a client should actually be able to do
| Capability | Client | Why |
|---|---|---|
| See bugs in their project | Yes | The entire point — it replaces "any update on this?" |
| See status and progress | Yes | Removes most status-chasing messages |
| Report a new bug | Usually | Better filed imperfectly than sent by text |
| Set or change priority | No | Depends on effort and risk they can't see |
| Reassign or close bugs | No | Not their scheduling decision to make |
| See other clients' projects | Never | Obvious, and worth verifying rather than assuming |
That row about priority is the one people argue with, so it is worth being precise: a client is the best possible source of impact and a poor source of priority. Impact is "this blocks checkout for everyone on mobile", which only they can tell you. Priority is what you do about it given the three other things currently on fire — which requires knowing about the three other things. The distinction is worth reading in full.
Brief them in one paragraph, not a process document
Nobody reads a wiki page about filing conventions. What works is a short message, sent once, when you hand over access:
When something looks wrong, file it here rather than messaging me — that way it doesn't get lost. Three lines is plenty: what you did, what you expected, what happened instead. If you can paste a screenshot, do. Don't worry about whether it's a real bug; I'd rather sort that out than not hear about it.
That last sentence does most of the work. The most expensive client behaviour is not filing bad reports — it is silently not reporting things because they were unsure it counted, then mentioning it three weeks later when it is much more expensive to fix.
The one habit worth encouraging explicitly is reporting observations rather than diagnoses. "The API is caching wrong" sends you chasing their theory; "the total still says 40 after I delete a row, until I reload" is something you can reproduce. More on that here.
Keep the comment thread client-safe
This is the part that actually bites, and no permission model protects you from it: if the client can read comments, the comments are client-facing writing. Things that do not belong there:
- Effort estimates and commercial talk. "This is two days we're not being paid for" is a conversation to have directly, not in a thread.
- Blunt assessments of the cause. "This is because the previous agency's code is a disaster" reads differently to the person who paid the previous agency.
- Speculation stated as fact. Clients reasonably read a comment as a commitment. "Probably a caching thing" becomes "you said it was caching".
None of this means being guarded. It means treating the thread as what it is: a shared record, not a private channel. Teams that get this wrong usually respond by removing client access entirely, which trades a small discipline problem for the much larger one they started with.
At the end of the engagement
Two things worth doing deliberately rather than by drift:
- Remove the access. Not out of distrust — an account that nobody owns is a loose end, and the person who set it up is the only one who remembers it exists.
- Export the project. A CSV of the bug list is a genuinely useful handover artefact, and it costs you one click. It also quietly demonstrates that their data was never hostage to your tooling.
Frequently asked questions
Should clients have access to your bug tracker?
Usually yes, read-only, scoped to their own project. They report problems regardless — access only decides whether those reports are structured or scattered.
What if the client files something that isn't a bug?
Close it with a one-line reason rather than leaving it open. An honest "working as designed, here's why" is a better outcome than a backlog quietly filling with items nobody will action.
Do I need a separate tracker per client?
No — separate projects on one install is enough, provided membership is per-project. One install, one thing to maintain, and no client can see another's work.
A read-only role, included
BugTrack's viewer role is read-only and scoped to one project, with no per-seat charge for adding a client. Self-hosted, free, running in about 15 minutes.
See how it works for client work →