Agency Project Management Software: What Matters When You Run 20 Clients

Agency project management software is the system that turns client requests into shipped work when you run many accounts at once. At about 20 clients it has to take intake from Slack, calls, and bugs, keep each account on its own stages, and show a roadmap counted from tickets. Project management for agencies fails when that queue lives in three tools and nobody can say what ships this cycle.

What agency project management software has to hold

Twenty retainers is where a shared spreadsheet and a heroic producer stop working. Each client has a contract, a cadence, a stakeholder who messages at odd hours, and a definition of done that doesn't match the next account's. At that scale, agency project management comes down to one queue that still works when someone is out sick.

The tool should answer, without a meeting: what came in and whether it's in scope, who owns it and what's blocking it, what rolls if it doesn't finish, and what you can tell the client on Thursday. If answering that takes Slack, a doc, a time tracker, and a roadmap deck, the software is only a viewer.

One queue, many contracts

A product team with one backlog can live on a single board. An agency can't. Client A is a monthly retainer. Client B is a fixed-scope build with a change-request clause. Client C is ads, where yesterday's brief is already wrong. Often the same people work on all three.

Keep the contracts apart and the capacity together. Stages should differ by type of work, while one view shows the same designer booked on six accounts on Thursday. Separate boards hide that overload until someone misses a date.

The work that never becomes a ticket

Most slippage starts before anything reaches the board. A client says something on a call and a producer nods. A Slack thread agrees to a "small tweak." A production error fires on a site you still maintain. None of those are tickets yet, so none of them compete for time, and they show up on Friday as surprises.

Every request should become a ticket the same day, with a source, a client, and a scope flag: in retainer, change request, or out of scope. Meeting notes are raw material for someone to review into tickets. Don't let them grow into a second system. Turning client meeting notes into tickets the same day is the habit to build. A paste, a file, or a call transcript should land on the client record and come out as reviewed work.

The jobs the tool has to cover

At 20 clients the tool has a short list of jobs to do well. When one is missing, people invent a side channel, and the side channel becomes the real system.

Intake from the places work already arrives

Agencies get work in Slack, on calls, by email, and as production errors. A message should become a ticket without retyping, with a link back to the source, because retyping is where scope gets softened. Triage needs only a few states: new, accepted, needs estimate, rejected, parked. Rejected and parked matter. A board that only moves forward teaches people to hide "no."

Ticket types and stages that match the work

A bug, a landing page, a copy deck, and a monthly report don't share a life cycle. Give each type its own stages, five to eight, named after the decision ("ready for client", "approved to ship") rather than a department. Go past eight and people start skipping stages.

Cycles, rollover, and recurring work

A cycle is a fixed window with an agreed set of tickets. Unfinished work rolls over in the open, with a note on why it slipped. Recurring work (rank checks, ad reviews, uptime, content calendars) belongs on the cycle too. If it only lives in a calendar, it doesn't count against capacity until it's late.

The Scrum Guide describes a time box, a goal for that box, and a review of what finished. You can borrow that part without adopting every role. SEO agency project management is where cycles pay off first, because monthly work is easy to wave off as "just maintenance."

A roadmap counted from tickets

A date on a slide means little unless it points at a ticket. Group the same tickets by client or outcome, order them by cycle, and update the roadmap when a ticket moves. A new promise either becomes a ticket or stays off the roadmap.

A client record instead of a second database

The client record holds the account, the notes, the files, and the tickets that came out of them. If the notes never become tickets, the record is a diary. Client management software for agencies that build software covers the account side. A simple test: can a new producer open one client on Monday and see the open tickets, the last reviewed notes, and the cycle those tickets sit in?

Dates you can explain

Answer "when?" with a range based on how long similar tickets took and what's already committed. Cycle time percentiles beat an average, which hides the slow tickets. A Monte Carlo forecast reruns the remaining work against that history. Say what would move the range: a change request, a blocked review, or another account pulling on the same people. With no history yet, say what's in the cycle and don't make up a day.

A worked week with 20 retainers

This week is an illustration, not a benchmark. Call the agency Northline: twenty retainer clients, a team of 14, two-week cycles. Here is Monday intake, before anyone "starts":

Source	Count	What happens
Slack requests	18	Tickets, tagged with client and in-scope or not
Call notes from last week	4 accounts	Reviewed into tickets or explicitly dropped
Production errors	3	Tickets on the maintenance type instead of a side chat
Recurring cycle items	20	Already on the cycle, so nothing is retyped
Change requests	2	Separate type; estimate before they enter the cycle

If those 18 Slack messages stay in Slack, the cycle plan stops describing the week Northline is about to have.

Two designers are spread across seven accounts, and the cycle already holds 46 tickets. The two change requests need about three days and don't fit. One waits for the next cycle. The other falls outside the retainer, so it's quoted as paid scope. Both decisions are recorded on the tickets.

Mid-cycle, a campaign client sends a new audience cut. The producer adds a ticket, marks the previous cut as superseded, and drops a lower-priority item on the same account so the cycle size stays honest. Ad agency project management is mostly this motion: change is expected, but swaps should never be silent.

On Friday, four tickets roll, each with a one-line reason: waiting on the client, underestimated, blocked on an asset, pulled for a production fix. The next cycle starts with those four in plain view. When someone asks for a date, you answer from the same tickets with a filter applied.

How to judge a tool on last month's work

Trial three real clients: a quiet retainer, a noisy stakeholder, and a fixed scope with change requests. Recreate two weeks of their work. If the tool fails two of the checks below, expect a side spreadsheet within a month.

1. Create tickets from a Slack thread, a pasted call note, and a bug, each linked to the client.
2. Give two ticket types different stages. Confirm someone can't skip a required review by dragging.
3. Put the work on a cycle and leave three items unfinished. Confirm they roll only after someone records why.
4. Open the roadmap. Every bar should be a ticket, and changing a ticket's cycle should move the roadmap.
5. Ask for a date on what remains. You want a range from your history, or a clear "not enough history yet."
6. Hand the three clients to someone who wasn't in the trial. Within 15 minutes they should find open work, the last notes, and this cycle.

Ignore galleries, "summarize" buttons, and integration counts. A notification isn't intake until it's a ticket with an owner and a scope flag. Ask to see the view you'd send a client and the view you'd use to say no.

Where a generic board breaks

General project tools fit one team with one backlog, and they strain when the product is a client relationship. Separate boards hide the editor booked on six accounts. Without a scope type, a retainer item, a bug, and a change request look the same, so invoice arguments get settled from memory. Wiki notes drift away from the board. A second roadmap matches delivery on the day of the quarterly meeting and drifts after that. Recurring templates that nobody fires are how retainers under-deliver. And story points measure the estimate, while cycle time from finished tickets is much harder to fake.

Custom fields can stretch a general tool if one producer maintains the rules. If the process is still fuzzy, a new product will copy the mess. Fix the rules first, then replace the tool if they're clear and it still can't hold client, cycle, and scope.

Creative review and marketing dates

Creative agency project management software is often sold as proofing: versions, comments on frames, brand assets. That helps with design review, but it can't run the agency. An approval on a file has to become a stage on a ticket, or the people planning next week never see it.

Marketing splits the same way. Project management for marketing agencies has to hold launches, small requests, and fixed dates in one cycle, so a campaign doesn't quietly eat the retainer.

If you do both creative and engineering work, keep one record of the commitment: owner, stage, cycle, client, and whether it's in scope. Leave the frames in the review tool and link out to them. The code change follows the ticket. A ticket marked shipped while its branch is behind main is reporting a false status.

The board next to delivery, and what the client sees

Hiring, invoices, and sales handoffs are real work, but on the client board they inflate delivery. Keep an operations board in the same system. If a client would recognize the item on an invoice or a status note, it's delivery.

Clients want to know what moved, what you need from them, and whether the date holds. A portal works when its status can't drift from the tickets. So does a short note pulled from those tickets, including what's waiting on the client and the date you asked. A lot of "agency delay" is client delay that nobody wrote down.

A cadence the software can support

Daily, about 15 minutes: triage new tickets and name blockers. Twice a week, go through requests still sitting in chat or notes until each one is a ticket or an explicit no.

Once per cycle, plan recurring items first, then rollover, then new scope. A change request gets in by swapping something out or by being sold. At the review, count what finished, what rolled, and which clients took more than their share. Then fix the estimate, the staffing, or the scope rule.

Once a month, match promised outcomes to tickets. A promise with no ticket either gets one or gets deleted. Drop any external date your cycle time no longer supports. Write the cadence down in the tool or on one internal page.

What good looks like after 90 days

• A request from Slack or a call is a ticket the same day, or declined in writing.
• Every active client has an owner and a cycle view a colleague can open cold.
• No ticket rolls three times without a decision to cut scope, add people, or reset the date.
• External promises are a filter of tickets, with no parallel deck.
• Change requests are a type you can count, per client, per month.
• Any date you give is a range, with the history or the committed cycle behind it.
• One producer can take a week off and the updates still go out.

If three of those are false, hold off on another tool and fix intake and the cycle review first. Software amplifies whatever cadence you already run, bad ones included.

A fair comparison

The right category depends on whether you're mostly creative, mostly media, or mostly shipping software.

General work managers fit when one operator maintains the conventions and the work isn't tied to a codebase. They get loose when client, scope type, and cycle are optional fields. Creative proofing tools are good with frames and struggle to run engineering, media, and monthly reports. Agency suites that sit beside time and billing help when finance and delivery share a screen. They struggle when the board turns into a timesheet, or when every hour has to be coded before work can move.

A workspace built around tickets, clients, and a repository fits agencies that ship software and still run retainers. Falrow is in that category. Slack, calls, and Sentry errors become tickets, and notes from Granola, a file, or a paste become reviewed tickets. Cycles roll with a review, the roadmap is those tickets, and cycle time percentiles plus a Monte Carlo forecast (2,000 runs) sit on that history. It runs on one SQLite database you can self-host, and it's in private beta. It suits a software-heavy agency and is a poor fit if all you need is comments on frames.

Switching without losing a quarter

Move one cycle and leave the archive where it is. Agree on ticket types, stages, and the in-scope rule first. Create the 20 client records, name an owner for each, and load only the current cycle: open commitments, recurring items, and real blockers. Run two cycles and fix the stages people skip. Then bring older open work across and close whatever is already dead.

Tell clients the update may look different for two weeks and the promises haven't changed. Falrow for agencies is the short version of the fit, and the client record is where notes become reviewed tickets. Pricing and the private beta are on request. Judge it on the Northline week.

FAQ

What is agency project management software?

It's the system an agency uses to take in client requests, commit them to a cycle, and show what shipped. It differs from a single-team task board because the unit of work is a client contract, so retainers, change requests, and recurring deliverables stay distinct. At around 20 clients it also has to show shared capacity, so nobody gets silently booked on six accounts. If the board can't do that, the producers end up as the scheduler.

How is this different from internal project management?

Internal project management serves one organization with one backlog and one definition of done. An agency serves many paying clients, each with its own scope, cadence, and stakeholders who add work in chat. You need a client record, a way to mark retainer work versus change requests, and an update you can send without rebuilding the week from memory. A tool built for a single product roadmap tends to sprout side spreadsheets by the second month.

Do we need a client portal?

You need an update that matches the tickets. A portal helps when clients will actually log in and its status can't drift from the board. Many agencies do better with a short note pulled from those tickets, plus a list of what's waiting on the client. Add a portal when clients ask to look for themselves. It doesn't replace triage.

When should we replace our current tool?

Replace it when the way you work is already clear and the tool can't hold it: intake from chat and calls, stages per type of work, reviewed rollover, and a roadmap built from tickets. Don't replace it while those rules are still unsettled, or the new board will copy the old mess. Check the 90-day list above. If intake and the cycle review are solid and you still can't trust a date or a scope flag, trial last month's work and switch one cycle at a time.