Most agencies set up a new engagement by copying the last one and deleting what does not apply. It takes a couple of hours and produces a slightly different project every time. Here is the alternative I built, what it cost, and what it is honestly worth.
The problem this removes
Ask most agencies how a new engagement gets set up and the answer is some version of: someone copies the last similar project, deletes what does not apply, renames the rest, and fixes the dates. It takes a couple of hours, it is nobody's favourite morning, and it is done slightly differently every time.
The lost hours are the smaller cost. The real cost is that no two projects have the same shape, so nothing downstream can be relied on. You cannot compare progress across clients, you cannot report on phases that are named differently, and a step that was quietly dropped during the copy does not surface until QA, or worse, until the client notices.
Copying a project forward carries the previous project's mistakes into the next one, silently, forever.
What I built
An intake form feeds a script that generates a complete project: one epic plus 28 child tickets, organised into phases, with components, owners and due dates calculated from the start date. One submission, and the structure exists.
It runs on Jira with ScriptRunner, but the pattern is not tool-specific. The same thing can be built in Asana, ClickUp, Linear or Monday, and a simplified version works in a spreadsheet feeding an API.
How to build it
1. Write the work breakdown down, once
Not from memory. Take three recent projects of the same type and list every ticket that existed in each. The overlap is your template. The items that appeared in only one are the interesting ones: either they were exceptions, or they were forgotten in the other two.
2. Decide what varies and what does not
Client name, start date and scope size vary. Phase names, task sequence and QA steps should not. Everything in the second category belongs in the template rather than in the form, and keeping that boundary strict is what stops the form growing to thirty fields.
3. Store the template as data, not as code
A spreadsheet or JSON file listing each ticket, its phase, its component, its default owner role, and its offset in days from the project start. Anyone can edit it without touching the script, which matters enormously for whether it survives you.
4. Write the generator
Read the form response, read the template, create the epic, then loop the child tickets, calculating each due date from the start date plus the offset. Under a hundred lines in most tools.
5. Handle the exceptions explicitly
Some engagements skip a phase. Add a checkbox to the form rather than letting people edit the output afterwards. The moment people start hand-editing generated projects, the structure begins to drift again.
6. Run it in parallel for three projects
Generate alongside the manual setup and compare. You will find two or three tickets missing from the template. Fix them, then switch over.
Tools and what they cost
| Option | What it costs | Honest trade-off |
|---|---|---|
| Jira + ScriptRunner | ScriptRunner is a per-user paid app on top of Jira seats. Jira Standard is roughly $8 to $9 per user per month at small team sizes. | Most powerful option, and the cost scales with headcount whether or not you use it. |
| Jira native automation | Included, but capped. Free is 100 rule executions a month, Standard 1,700 pooled across the site, Premium 1,000 per user pooled. | Fine for a handful of rules. A generator that creates 29 issues burns the Standard allowance in about 58 runs. |
| Google Apps Script into any API | Free with Google Workspace. | No per-task fee and you own the code. You write the API calls yourself and manage the six-minute execution limit. |
| Connector platform (Zapier, Make) | Billed per task or per operation. A 29-issue generator is 29+ tasks per run. | Fastest to a first version. The pricing model works directly against exactly this kind of high-count automation. |
Watch the pricing model, not the sticker price. Anything that bills per action is the wrong home for an automation whose whole job is creating a lot of things at once.
What it is actually worth
I want to be careful here, because this is where most automation writing invents numbers. So, three honest tiers.
What I measured myself. Setup went from a task measured in hours to one measured in seconds, and the structure became identical across engagements, which is what made reporting across clients possible at all.
What you can calculate for yourself. Take your own setup time, multiply by projects per year, and multiply by a loaded hourly cost. Two hours per project, forty projects a year, is eighty hours. Whether that is worth building depends on your numbers, not on mine.
What the wider evidence says about why these projects fail. Ernst and Young, drawing on their own delivery work across more than twenty countries, put the failure rate of initial robotic process automation projects at 30 to 50 percent. That figure is from a consultancy that sold the implementations, and it is roughly a decade old. It is still the most-cited number in the field, and its cause is consistent: automating a process that was never defined.
Which is exactly why step one above is writing the work breakdown down rather than opening a code editor.
How it breaks
The template drifts from reality. The delivery method changes and the template does not, so people start deleting generated tickets. Review the template quarterly, and treat mass deletion as a signal rather than an annoyance.
Someone hand-edits the output. Once one project is customised after generation, the consistency argument is gone. Push variation into the form.
It generates too much. Twenty-eight tickets is right for a substantial engagement and absurd for a two-day job. Have more than one template rather than one template with lots of optional parts.
How to tell whether it worked
Not by how clever it is. Three measures: time from signed to first ticket, the number of tickets manually added after generation (which tells you the template is wrong), and whether you can now produce a report that spans clients, which was impossible when every project was shaped differently.