The Complete Software Agency Workflow: Ticket, Sprint, Development, Testing and Billing

The chain, in one view

Ten stages. Most agencies do all ten. The difference between a comfortable month and a chaotic one is almost never the quality of any single stage, it is how much information survives the boundaries between them.

Stages 1 and 2: request and intake

Everything downstream inherits the quality of this step. A ticket that arrives with a client, a project, reproduction steps and acceptance criteria can be estimated, scheduled and built by someone who was not in the original conversation. A ticket that arrives as "it is broken again" requires the person who read the email to stay involved forever.

Failure mode: intake is nobody's job, so it happens whenever someone has a spare moment, which is usually after the client has followed up. Signal: developers regularly ask "what does this ticket actually mean?" in standup. The fix is in turning client emails into developer-ready tickets.

Stage 3: SLA and priority

The priority is not a mood, it is the contract. Each level needs a response time and a resolution time, attached to the ticket rather than living in a signed PDF nobody opens. The system should warn before a deadline, because a breach notification is a report on something you could have prevented.

Failure mode: everything is P2, so nothing is. Signal: the ticket that gets worked on is the one whose client complained most recently, rather than the one with the nearest deadline. More on the mechanics in preventing stale tickets.

Stages 4 and 5: estimate and sprint

Two different units are in play, and conflating them is the most common planning error in agencies. Story points size the work relative to other work. Capacity is measured in days, and only days compete with days.

Capacity must be derived, not typed: working days in the period, minus contracted part-time days, minus public holidays, minus approved leave, minus a support reserve sized from your own history. When someone books leave, the sprint should shrink without anyone remembering to make it happen.

Failure mode: the sprint is planned on headcount, so it is 30 to 40 percent oversubscribed before it starts. Signal: the same three tickets roll forward every sprint, and the team believes it is slow. The full calculation is in sprint capacity planning.

Stage 6: build, across every repository the project touches

A client-facing feature is rarely confined to one repository. It is an API change, an admin interface, sometimes a mobile client. Treating those as three tickets creates three estimates, three reviews and one integration surprise. Treating them as one change with one pull request per repository keeps the intent in one place.

This is also the stage where AI agents can carry real weight: a planner that reads the codebase and writes its approach onto the ticket before code exists, and a coding agent that implements across the linked repositories. The constraint that makes this safe is that the run ends at an open pull request, never a merge. See AI coding agents for software teams.

Failure mode: the ticket does not know which repositories it concerns, so nobody can trace a deployed change back to the request that caused it. Signal: "which release was that fix in?" takes more than a minute to answer.

Stages 7 and 8: verification and review

Verification answers a narrow question: does the change do what the ticket said, without breaking what already worked. Cheap checks run first — linting, unit tests — because a build that fails those should never consume anyone's attention, human or model. Then the application is actually booted, and where the change warrants it, driven in a browser.

Failure mode: review is a formality performed by whoever is free. Signal: pull requests are approved faster than they could be read. Note that this failure gets worse, not better, when agents write the code: a rubber stamp on an agent-authored change adds the appearance of review to something nobody examined.

Stages 9 and 10: time, billing and the client update

Hours logged against the ticket already know the client and the project, which is what makes an invoice a review rather than an investigation. Two independent invoice states — one for what you bill the client, one for what a freelancer bills you — prevent the two most common billing errors in agencies.

If AI agents did part of the work, their cost belongs in the same place: booked per phase, rolled up to the client and project, with your markup applied if your contract allows it. Both numbers, hours and machine cost, on the same client line. See tracking billable hours per client and controlling AI development costs per client.

The last stage is the one agencies most often skip: telling the client what happened. An automatic weekly summary per client organisation — completed, new, updated, still open, grouped by project — costs nobody any time and removes most of the Monday status emails.

The four joins that make the chain hold

Consolidating tools is not the goal. These four relationships being real, rather than conventional, is the goal.

If those four hold, the number of tools you use is almost irrelevant. If they do not, no amount of integrations will stop the reconciliation work. That argument in full is in managing multiple clients without tool sprawl.

Where to intervene first

You cannot fix ten stages at once, and you do not need to. In our experience the order of return is fairly consistent:

1. 1Intake. Cheapest to change, and it improves every stage downstream at no additional cost.
2. 2Time logging on the ticket. Fastest measurable financial effect, usually visible within one billing cycle.
3. 3Honest sprint capacity. Turns chronic overcommitment into a planning conversation instead of a morale problem.
4. 4Stale ticket detection. Removes most client escalations, which removes most unplanned interruptions.
5. 5Ticket to repository traceability. Makes delivery auditable, and is a precondition for using agents sensibly.
6. 6AI agents, with a budget and a human at the merge. Last, because it only pays off once the five above are in place.

That order is not theoretical. It is roughly the sequence our own agency went through, and each step only became worth doing because the previous one had made its cost visible.