Blog ·
Jira for agencies: client projects and the retainer routine
Jira for agencies works when each client gets its own project. One project per client gives you a board per account, permissions that keep one client's work away from another's, and a clean place to log time against the retainer. The part agencies underestimate is the retainer itself: the monthly report, the site health check, the plugin updates, the quarterly review. Every client gets the same deliverables on the same clock, and none of them appear on a board unless somebody creates the ticket. This guide sets up the client projects first, then makes the retainer work show up on its own.
Statements about Jira's built-in features are as of October 2026, from Atlassian's own documentation.
Why agencies end up in Jira #
Often because a client asked. A software client already runs its roadmap in Jira and wants the agency's tickets in the same place. Sometimes because the agency builds software itself and the developers would not use anything else. Either way, the agency ends up running many small, parallel accounts in a tool designed around one team's backlog.
Jira handles that well if you shape it for accounts rather than for a product. It suits agency work that is:
- split by client, with each client's work reviewed and billed separately;
- made of deliverables with owners and dates, such as a landing page, a monthly report or a sprint of fixes;
- repeated on a retainer, which is where most of the hidden work lives;
- shared with the client at some level, from a monthly summary to full access to the board.
It is a weaker fit for quoting, invoicing and resource planning across the whole agency. Keep those in the tools built for them and link out.
One project per client, or one shared project? #
This is the first decision, and it shapes everything after it.
| One project per client | One shared project, a label per client | |
|---|---|---|
| Board | One per client, nothing to filter | One board, filtered by label |
| Keeping clients apart | Permissions per project | Hard, since everyone who can see the project sees every client |
| Retainer routine | Set up inside each client's project | One long list, tagged by hand |
| Reporting per client | Every filter starts with project = CLIENT |
Every filter depends on a label being right |
| Setup effort | Higher, once per client | Lower at the start |
| Best for | Retainers, long engagements, client access | Many tiny one-off jobs |
For retainer clients, one project per client is the safer choice. A label is one missed click away from a ticket landing under the wrong client, and that is exactly the kind of mistake a client notices.
If your client projects should all look alike, set one up properly and create the rest from it. Our Jira project template guide covers the ways to copy a project's configuration and starting work.
Keep clients out of each other's work #
Each project's access is controlled by a permission scheme, which decides who can browse the project, create work in it and log time on it. For an agency the usual shape is simple: your own team can see every client project, and a client's people (if they have accounts at all) can see only their own.
Check your plan before you promise a client a private board. Atlassian's page on the Free plan says:
Space permissions, roles, and work-level security aren't customizable in Jira Free. If your site has always been on a Free plan, everyone with access to Jira is an admin for all Jira spaces.
(Jira's interface now calls projects "spaces" and issues "work items". The meaning is the same.) So on Free, adding one client's contact to the site shows them every other client's work. If clients will log in, plan on a paid plan where permissions can be set per project.
Many agencies avoid the question by not giving clients accounts. The client gets a written monthly report instead, built from a saved filter, and the board stays internal. Our Jira weekly report guide shows the filter and the email subscription that make that report quick to write.
Track time against the retainer #
A retainer is usually a number of hours a month, so the question you are asked most is how much of it is left. Jira's built-in time tracking covers the basics. Atlassian describes logging time like this:
To log time on a work item: Open the work item and select More actions ( ), then Log work. Or, select the Time tracking field.
Time logged shows on the work item next to the remaining estimate, and a filter on the client's project for the current month gives you the total. A few habits keep the number honest:
- Log against the deliverable, not a catch-all ticket. "Misc client work, October" hides what the hours were spent on.
- Give the recurring deliverables their own tickets each month, so the report hours and the update hours are visible separately from project work.
- Close the month with a review ticket, so somebody checks the hours before the invoice goes out.
That second habit is where the routine starts to matter.
The retainer routine nobody creates a ticket for #
Project work gets tickets because it starts with a brief. The retainer does not, because it is the same every month. Here is a typical retainer for a web or marketing client:
| Deliverable | Cadence | What goes wrong without a ticket |
|---|---|---|
| Monthly performance report | First working days of the month | Written late, with no owner when the usual author is away |
| Site and plugin updates | Every month | Skipped in a busy month, noticed when something breaks |
| Uptime and backup check | Every week | Assumed done because nothing failed |
| Hours review before invoicing | Last working days of the month | The client is billed before anyone checks the total |
| Quarterly business review | Every quarter | Booked in a hurry, with nothing prepared |
Multiply that by fifteen clients and you have dozens of tickets a month that exist only in somebody's memory. When the account manager is on holiday, the retainer quietly misses a month, and the client finds out before you do.
Three ways to make the routine appear #
| Create by hand | Jira Automation scheduled rule | Recurring Work Items for Jira | |
|---|---|---|---|
| Effort per client | Every ticket, every month | One rule per routine, written once | One rule per routine, chosen from a form |
| Schedule | Whoever remembers | Fixed rate or cron expression | Daily, weekly, monthly or quarterly, with working days |
| Lives in | Somebody's calendar | The automation rules list | The client's own project |
| When it misses | Nobody knows | Check the rule's audit log | Run history with the reason |
By hand #
Fine for two or three clients. Somebody keeps a checklist and creates the tickets on the first of the month, ideally by cloning last month's. Our Jira task template guide covers making those clones quick.
Jira Automation #
Jira's own automation can create a work item on a timer. Atlassian's trigger reference says you can "run the flow at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules." That covers most retainer routines, with two things to plan for. Calendar rules such as "the first working day of the month" need cron, and some cannot be said in cron at all; our Jira cron expression guide covers the gaps. And every run counts toward your plan's monthly automation usage, which adds up when each client has five routines. Jira Automation pricing explains how that usage is counted.
A scheduling app #
Recurring Work Items for Jira is built for exactly this job, and its scope suits agencies: rules are scoped to one project, so each client's routine lives inside that client's project rather than in a site-wide list mixing every account. A project administrator turns it on for the project, and rules made there create work only there.
Set up a client's retainer with Recurring Work Items #
- Open the client's project and turn the app on for it.
- Create one rule per deliverable: the monthly report, the updates, the weekly check, the hours review, the quarterly review.
- Pick the cadence in the form: weekly, monthly or quarterly. For "first working days of the month", set the rule to avoid weekends and your holidays, so it never lands on a Saturday.
- Write the title with tokens so each month's ticket has its own name, for example
Monthly report {{now.monthName}} {{now.year}}. - Fill in the template: assignee, priority, labels, a due date a few days after the run, and the description the deliverable needs.
- Add a subtask checklist where the deliverable has steps, such as pull analytics, write summary, send to client for the report.
The next client is quicker. Duplicate copies a rule inside a project, which helps when two routines differ only by cadence. Rules stay in the project they were made in, so each new client project gets its own set. If your routines already live in Jira Automation, Import from Automation reads an exported rule set instead of making you retype it.
Every run is recorded in the rule's history, created, skipped or failed, with the reason. When a client asks whether last month's update ticket was ever raised, that history answers in one look.
Client onboarding and offboarding #
A new client and a departing client both come with a checklist: access, kickoff, handover, removing access. These are triggered by an event (the contract is signed, the notice period ends) rather than by the calendar, so a schedule is the wrong tool. A template project or a cloned epic fits better; our Jira epic template guide shows how to keep one ready.
The one part of offboarding a schedule does help with is the end of the retainer. A rule can be given an end date, so the monthly tickets stop when the contract does, instead of appearing for a client you no longer work with.
When the manual way is enough #
Scheduling earns its keep once the routine is bigger than one person's memory. You probably do not need it if:
- you have a handful of clients and one account manager who already creates the monthly tickets reliably;
- your retainers are hours, not deliverables, so there is nothing fixed to create each month;
- clients send their own requests and the work is reactive, which a service queue handles better than a schedule.
Once you pass ten or so clients, or the person who remembers goes on holiday, the gaps start costing more than the setup.
FAQ #
Should each client get its own Jira project? For retainers and long engagements, yes. It keeps permissions, reporting and the routine separate. A shared project with labels works for many small one-off jobs.
Can clients see only their own project? On a paid plan, yes, through each project's permission scheme. On the Free plan, Atlassian says permissions are not customisable and everyone with access is an admin for every project.
How do I track retainer hours in Jira? Log work on each deliverable and filter the client's project by the current month. Giving each recurring deliverable its own ticket keeps the hours readable.
Can Jira create the same monthly tickets for every client? Yes. Jira Automation can, with a scheduled rule per routine. Recurring Work Items for Jira does it from a form, scoped to each client's project, with working-day handling and a run history.