How We Rebuilt Our Workflow from the Inside Out
Intellectual property work doesn’t move in straight lines. A trademark portfolio might contain hundreds of active marks across registration, renewal, and affidavit cycles — each at a different stage, each with its own registrar, deadline, and document trail. Managing that complexity is not just a legal challenge. It’s a data and operations challenge. This is the story of how we approached it, what we tried, what didn’t work, and where we landed.
The Silo Problem
Before we could fix our workflow, we had to be honest about the shape of the problem. Information about any given trademark file lived in at least three separate places — and none of them talked to each other.
The IP management software was our system of record for legal facts, but it wasn’t built for document retrieval. Searching for a specific filing receipt or a client’s power of attorney meant switching to the document management system — which knew nothing about deadlines or owners. And the most important context of all — what a client actually said in an email, or what the registrar responded — was buried in Outlook, unconnected to either system.
Every time someone needed a full picture of a file, they were stitching together information from three places by hand. That’s not a workflow. It’s archaeology.
Bringing in Jira — and the First Attempt
We decided to introduce Jira as a connective layer — a place where work could be made visible, tracked, and moved forward without having to rely on who happened to remember what. The question was how to structure it.
The intuitive answer was to organize around portfolios. A client’s collection of marks felt like a natural unit. So we started by creating Epics at the portfolio or mark level — one Epic per trademark, with tasks hanging underneath it for each stage of work.
This worked — until it didn’t. The real issue surfaced quickly: trademark work is batched. When renewals go to the registrar, they don’t go one at a time. A group of marks might be filed together, processed together, and received back together. When those batches moved through a stage, the relevant tasks weren’t all in the same Epic. They were scattered across however many mark-level Epics existed for that client.
Moving tasks between Epics to reflect a batch shift wasn’t just time-consuming — it was error-prone. Work was getting lost between the cracks.
We also found that a single mark could have work happening at different stages simultaneously — a renewal at one step, a separate class of the same mark at another. The Epic structure forced all of that complexity into one container, which made it hard to see clearly what was actually happening.
The Pivot: Recognizing What the Work Actually Is
The realization came gradually, then all at once. The model needed to change — and once we saw it clearly, we moved quickly.
The insight was simple: the natural unit of IP work is not the client, and not the portfolio. It is the file. A registration is a file. A renewal is a file. An affidavit is a file. Each file has its own lifecycle, its own registrar touchpoints, its own deadline, its own documents. Trying to squeeze multiple files into a single Epic was fighting the grain of the work.
THE NEW MODEL
We restructured around file types, with a dedicated space for each kind of work:
Each ticket = one file. Each space = one type of work. Stages are board columns within each space. No task moves between Epics — because there are no Epics.
Each ticket carries the matter ID, client, mark name, and links to the relevant records in the IP management software and document management system. The stage it’s in on the board tells you exactly where it is in the process: “Pre-Audit”, “Filed”, “Receipt Logged”, Hold for PTO”, “Hold for PTO,”” Ready to Ship.”
What Jira Actually Solved
The shift to file-per-ticket didn’t just make the board easier to read. It changed the relationship between our three information silos in a meaningful way.
Instead of asking “what’s the status of this client’s portfolio?” — and then going to find out — we could now ask: “what’s the status of this specific file?” and get the answer immediately from the ticket, with links to the document and the matter record. The ticket became the connective tissue that the other systems lacked.
Outlook didn’t disappear from the picture — email is still where a lot of critical information arrives first. But now when an email comes in about a filing, it has a ticket to land on. Context accumulates in one place rather than dispersing across inboxes.
The board doesn’t replace the IP management software or the document system. It connects them — giving every file a home base where its stage, its documents, and its correspondence can all be found from one place.
The Journey in Brief
October 13, 2025
First tickets created — portfolio-as-Epic model
[Client Mark A] (KAN-5), [Client Mark B] (KAN-14), [Client Mark C] (KAN-17) structured as Epics with tasks underneath. Felt right — until batching exposed the friction.
October 14–16, 2025
Recognizing the problem in real time
The team adapting in the board itself — renaming tickets, creating new ones, realizing the model needed to change.
October–November 2025
Iteration — testing the file-per-ticket model
Separate spaces stood up for Renewals, Affidavits/Declarations, Registrations, Inactive Files, and Office Actions & Oppositions. Stages as board columns. Batching friction disappears.
January 2026
Stabilization
Model settled. ~90 renewal files and ~100 declaration files in their respective queues, moving through defined stages. Registration spaces consolidating.
Now
Automation layer under construction
With the framework stable, the next phase begins: wiring the system to move itself forward without requiring manual intervention at every step.
What Comes Next
The framework we’ve built — file-per-ticket, stage-as-board-column, spaces by work type — was always meant to be a foundation, not a destination. The real payoff comes when that structure becomes programmable.
We’re now building the automation layer on top of it. When a filing is submitted to PTO or Chamber of Commerce (CCIH), the system will track the wait, send a follow-up when it sits too long, log the receipt when it comes back, and flag the file when the certificate is ready to ship — all without anyone having to remember to check. The ticket becomes not just a record of where the file is, but an active participant in moving it forward.
Upon receipt from registrar, the document that's scanned will attach to the record. The dashboard will reflect the real state of the portfolio without anyone having to assemble it by hand.
We’re not there yet. But we have something we didn’t have six months ago: a system with enough structure that automation can actually work. You can automate a file with a known state, a defined next step, and a clear owner.
That’s what we built. The next chapter is letting it run.
