Why We Built a Document Routing Agent

I have spent a fair bit of my working life building workflow tooling for business operations teams. Not glamorous work in the way that consumer apps can be, but deeply satisfying in a different way: you make someone's actual job noticeably better, and you see the effect relatively quickly. A process that used to take a day takes an hour. A task that required three people to coordinate now runs on its own. There is something concrete about that kind of improvement.

The problem that eventually became ZippedScript showed up repeatedly across different organizations I worked with. The pattern was almost always the same: a capable, organized ops team spending a disproportionate amount of their time on document work that, once you looked at it carefully, did not actually require their judgment. The drafting was repetitive. The routing was rule-based but done by hand. The follow-up was manual. The filing happened inconsistently or not at all.

These were not poorly run teams. They were well-run teams handling a category of work that had not been automated because it sat at an awkward intersection of document generation, workflow routing, and approval management. The tools that existed addressed one of those three things reasonably well but not all three together.

What I Kept Seeing

The most frustrating version of this problem looked like this: an ops coordinator receives an intake request that triggers a vendor services agreement. She opens a previous vendor agreement, strips out the specific details, fills in the new vendor's information, checks the payment terms against the standard table, attaches the correct addenda depending on the service type, and sends it to legal for review. This takes somewhere between forty-five minutes and two hours depending on how clean the intake request was and whether the template has been updated since the last time she used it.

Then she sends a Slack message to the legal contact saying the agreement is in their inbox. She notes it in her tracking spreadsheet. Three days later, if she has not heard back, she sends a follow-up email. Depending on the response, she may send a second follow-up. Eventually the agreement comes back, signed or with comments, and she closes the loop.

None of that is complex. Most of it is predictable to the point of being mechanical. And yet it consumed a meaningful fraction of her week, every week, because the volume of vendor agreements was high and there was no system to handle any part of it automatically.

I saw versions of this across HR onboarding, client contract renewals, internal approval requests, and procurement processes. The specific document types were different. The underlying pattern was identical: structured information going in, a document coming out, and then a manual process to get that document to the right people and back.

Why Existing Tools Did Not Solve It

I want to be honest about why I thought there was a gap here, because there are good tools in the document space and I am not suggesting they do not work.

Template tools work well for drafting if your starting point is a fill-in-the-blank exercise. They are less well suited to situations where the template itself needs to vary based on input data: where the scope section of a vendor agreement looks different depending on whether the vendor is providing professional services or software, or where the payment terms section pulls from a rate table rather than a fixed value. Getting that conditional logic right in a template tool requires either custom configuration work that takes longer to set up than it saves, or a complex enough implementation that the average ops team coordinator cannot own it without IT support.

E-signature tools handle the signature collection part. They do not handle the drafting. They also do not handle the upstream routing: who needs to review and approve the document before it goes out for signature? That step still happens in email.

Workflow automation platforms can handle routing, but they are built to orchestrate tasks and approvals at a fairly abstract level. Generating a specific document from structured input data, applying conditional clause logic, and then routing that specific document through a defined approval chain requires custom integration work that is well beyond what most small ops teams can set up and maintain.

The gap I kept running into was the integration layer between these three categories. Drafting, routing, and approval management are one workflow from the perspective of the ops team running it. But they required three separate tools, each with their own setup, and the hand-offs between tools were still manual.

What We Decided to Build

When Arjun and I started talking seriously about what ZippedScript should be, we kept coming back to one design principle: the system should handle the full document lifecycle from intake to signature without requiring a manual hand-off in the middle.

That meant the drafting had to be connected to the routing. Not "generate the document and then separately configure who it goes to." The routing rules should be part of how the document is defined: this document type, when it meets these conditions, goes to this sequence of approvers. The AI drafting step and the routing step should be two aspects of the same workflow, not two separate systems.

It also meant we had to take a position on what kinds of documents this works for. We are not trying to handle every document type that a business generates. We are focused on the categories where the drafting is structured enough to benefit from AI generation and the routing is rule-based enough to be fully automated: contracts with definable templates, onboarding packets, vendor forms, internal approval requests, and the like. Documents that require significant bespoke drafting for each instance are not the target. The target is the repeatable document work that currently consumes a disproportionate fraction of ops team time.

The Bootstrapped Constraint and Why It Helped

Building ZippedScript without outside funding has shaped some decisions in ways I think are positive. When you are working with limited resources, you have to be extremely selective about what you build first. There is no option of building everything and seeing what sticks. You have to start with the use case where the value is most immediate and most clearly demonstrated.

For us that was the vendor contract workflow: intake form, AI-generated draft, approval routing, e-signature collection. We spent the first several months on that one flow, getting it to the point where an ops team could configure it in an afternoon, run it without IT support, and see time savings within the first week of use. Only once that flow was solid did we extend to other document types.

The constraint also meant we stayed close to our early users in a way that I think would have been harder if we had been building faster with more resources. The conversations we had with operations managers and coordinators during those early months shaped a lot of the product decisions we made. They told us where the configuration was too complex, which features were genuinely useful versus which were nice on paper but never actually used, and which document types they needed covered before anything else.

What We Are Trying to Be

ZippedScript is not trying to be a comprehensive document management platform. We are not trying to replace the tools that legal teams use for contract lifecycle management or the systems that finance teams use for procurement. We are trying to be the layer that handles the repeatable document work that lives in the middle of ops teams' days and currently has no good automated answer.

We are a small team in Vancouver. We are building this independently. We have strong opinions about what the problem actually is and what a good solution looks like, based on direct experience with it. We are not trying to be all things to all teams, and we are not trying to sell a vision of automated document workflows that we cannot actually deliver today.

What we can deliver today is a system that, for a defined set of document types, handles drafting and routing and follow-up automatically, and does it in a way that an ops team can configure and own without needing developer support. That is a narrow claim, and it is an honest one. It is also, based on what we have seen, the thing that actually moves the needle for the teams we are building it for.

If you are running an ops team that spends a lot of time on repetitive document work, we would like to show you what that looks like in practice. That is why we built it.

- Chris Harper, CEO and Co-Founder, ZippedScript