The solution of last resort
If document generation is easy to build, why does anyone buy it?
Here’s the obvious follow-on question. If features are quick to build now, why wouldn’t every ERP, HR and CRM system simply include document generation? Nearly all of them need some. There’s no real argument against it – every one of those systems holds data that ends up in a document sooner or later. If the cost of building has collapsed, the capability should just arrive, out of the box, everywhere.
The first article in this series argued that building software has become cheap enough that rebuilding document automation software with AI is a real option worth taking seriously. That’s the premise this question tests.
It already happened
The awkward part of that question is a prediction. It’s been happening for decades.
SAP has output management and Document Builder. Dynamics generates documents. Salesforce has a whole ecosystem attached to it, Conga among others, and we’ve lost deals to that ecosystem more than once. These aren’t hypothetical futures. They’re capabilities your prospects already own and have owned for years.
And dedicated document automation software survived anyway.
So the interesting claim can’t be that embedded generation arrives. It’s already here. The claim has to be narrower: the line where “good enough” sits moves up. Embedded modules get better – if the vendors who own them give them attention, which is genuinely an open question – and each increment takes another slice of what used to require a dedicated tool.
I should be honest about how much of this I can actually see. I have no data showing embedded document generation improving. I’m inferring it from the general collapse in development cost.
The bigger blind spot is worse than that. We have clients who came to us from SAP Document Builder, and we’ve had clients pulling HR data out of SAP to generate documents with our software. What we can’t see is the much larger group who never contacted us at all, because what they already owned was adequate. I assume there are many. I have no way to count them.
The ladder
Here’s the pattern I do see, repeatedly, and it organizes everything else.
When they want their documents automated, buyers work through three rungs in order:
- Use what’s embedded in the systems they already own.
- Build something
- Buy dedicated document automation software.
Dedicated document automation software is the solution of last resort. Clients who reach us have usually exhausted the first two rungs, sometimes several times over. An architect at a large pharmaceutical client told us they had fifteen different document generation systems in the organization before they landed on ours. He didn’t arrive through a procurement process. He arrived through exhaustion.
AI raises both of the lower rungs. Embedded improves; DIY gets dramatically cheaper.
The funnel above the dedicated category narrows. Not because the value of dedicated document automation disappeared, but because fewer organizations struggle badly enough to go looking for it.
That produces a specific prediction. The document automation software category doesn’t shrink evenly across the board. It loses its entry point. The clients who would have found us on their third attempt now succeed on their first.
It was never about complexity
There’s a comfortable story dedicated vendors tell about this, and I think it’s wrong. The story goes: embedded tools handle simple documents, dedicated tools handle complex ones, so as documents get harder the dedicated tool wins.
SAP Document Builder disproves it. It is notoriously difficult to work with – ask anyone who has. And it is entirely adequate for a logistics company with a handful of documents that hardly ever change. Difficulty of use is survivable when you’re only going to feel it a few times.
Complexity is the wrong axis. The right one is cost per template over time.
With embedded tools, you can nearly always produce one working template, no matter how complex. What they struggle with is producing the four hundredth one, and keeping the whole estate alive across five years of regulatory change, rebrands, and staff turnover.
That gives two archetypes which predict the right answer far better than company size does:
Narrow. A handful of templates, changing rarely. Software cost dominates the economics. Embedded generation copes perfectly well. Don’t buy dedicated document automation software.
Wide. Hundreds of distinct templates, continuously added to and maintained. Finance, insurance, government legal departments, court systems, anywhere with a large body of distinct documents. Here the template estate is the economics and the software is a rounding error.
How big a rounding error? In wide estates, we’ve seen initial template conversion run at twenty times the cost of the software itself. And it compounds, because the estate keeps growing and everything in it needs maintaining. That multiple isn’t universal – where an organization has few templates but very high document volumes, it sometimes inverts – but where it applies, it dominates every other consideration in the business case.
The real cost of document automation software is not the software license but the cost of creating and maintaining templates over its lifetime.
A few footnotes to this distinction:
- Note that the volume of documents doesn’t matter. This has historically benefited solutions for high volume generation with difficult code-like templates.
- Between the Narrow and Wide archetypes sits an awkward middle: too much to embed comfortably, not enough to obviously justify a dedicated tool. The first article in this series gave a threshold for building versus buying – under roughly twenty pages of automated content, with simple logic and a low rate of change, build it yourself. It’s the best line I have for embedded versus dedicated too. Different question, same threshold, which I take as a sign the line is real.
The boundary embedded tools struggle to cross
There is an area of tension for software vendors who embed document generation functionality in them. Moat building versus functionality.
The documents that matter most draw content from more than one system. HR data plus CRM data plus pricing rules plus an approved clause library plus a rules engine. Embedded generation is often confined to the data its host owns. That’s not a feature gap that gets closed in the next release.
It’s a lock-in strategy, driven in part by making everything inside the platform work seamlessly, and everything outside of it look difficult, and in part by real technological obstacles. On its own terms it’s rational. Applied to document generation, it backfires. It makes the embedded module unusable for precisely the documents with the highest value – the ones that need to reach across the business – and hands that work to somebody else. The moat manufactures the escape hatch.
If you’re evaluating an embedded module, this is the thing to test before you commit rather than after. Not “can it generate the document?” but “where can it get content from, and what happens when the answer is a system this vendor doesn’t own?”
The same gap runs through everything around generation, which is where large estates actually spend their time:
- Template management across hundreds or thousands of templates
- Document management workflow after generation
- Approval workflow for the content going in
- Integration with external content sources
- Integration with rules engines
Worth being careful about how much weight to put on integration as a differentiator, though. Anyone can build a connector now – that’s the whole premise of this series. The work isn’t building twenty integrations, it’s maintaining twenty integrations across other people’s deprecation cycles.
What happened to CCM
If you want to see what happens when document generation becomes an ancillary feature of a bigger platform, you don’t need to speculate. That experiment has run.
Customer communications management largely dissolved into experience and marketing platforms, where content generation is positioned as one component of a story about customer behavior and engagement. Gartner no longer produces CCM Magic Quadrant.
But the work didn’t shrink. In our experience, converting content into automated templates remains the largest single line in an implementation – plausibly larger than the software license. For CCM platforms the multiple is probably lower than the twenty times I quoted above; if I had to guess I’d say nearer ten, partly because the platforms themselves cost more and partly because that conversion work has historically been offshored.
The point for a buyer is that when a vendor is displacing an incumbent, they will often subsidize the conversion work to win the deal. That doesn’t remove the cost. It hides it, and then it reappears in years two through five as the estate grows and every new template carries the full price.
Embedding document generation doesn’t eliminate the template cost. It makes it unpriced.
Template gravity
We had a client, for years, with CCM software and a top-down mandate to use it. They kept putting more and more templates into ActiveDocs anyway, because it was quicker and cheaper to build them there.
And the pharma architect with fifteen systems didn’t consolidate onto ours because of a policy decision. They expanded use of it because it was the easiest and fastest place to build a template.
The lesson is that adoption in this space is bottom-up, and mandates lose to authoring speed.
That isn’t laziness, and it isn’t preference. In a wide estate it’s arithmetic. When template cost sits an order of magnitude above software cost, the tool that’s quicker per template is the cheaper tool, by a margin no procurement decision can outweigh. Policy that ignores that gap gets routed around by whoever has a deadline.
So where does the category go?
If embedded generation is everywhere and slowly improving, the future of dedicated document automation software probably isn’t “the system that generates the documents.” It’s the governance layer above other people’s generation. Consistent policy, approval, branding, retention and audit across estates that were embedded first and governed never.
If you run six systems that each generate documents, you already know the shape of this: six template estates, six approval processes, six versions of the mandatory disclosure, and branding that drifts apart within eighteen months. Nobody feels it at the point of adoption.
Two things stand between the category and that future.
There is no standard to build it on. No common format for templates, for automation definitions – fields, rules, conditional logic – for data connectivity, or for the questionnaires where users enter and review data before generation. Without those, reaching into systems you don’t own is a translation problem rather than a plumbing one. Solvable, but the hard way. Somebody should be championing open standards for all four, and I think that includes us – I’ll come back to why that’s less selfless than it sounds.
And you can’t sell it. Governance layers get bought top-down and routed around bottom-up. The only version that holds is one that arrives the way it arrived at those two clients – one template at a time, because it was the quickest place to build.
Which reduces the whole strategic question to a plainer one: who wins authoring?
What you should hold us to
Incompatible template formats protect incumbents, and we are an incumbent. Every estate built in our software is sticky partly because moving it is painful. That’s real, and we benefit from it today.
But AI is very good at converting one set of exact specifications into another, and a template is exactly that. Conversion cost is trending towards zero, which makes format lock-in a depreciating asset – and advocating open standards cheaper than it looks, because the stickiness is going away whether we champion anything or not.
So here is what we’re left competing on, and what you should hold us to: being the most cost-effective place to author and maintain a template. That’s the design-time line from the second article, drawn again for economics. It’s also the only mechanism this market has ever respected – win the authoring decision often enough and the estate concentrates, and whoever holds the estate is the only party in a position to govern it.
The hard part is everything that never concentrates: the templates that stay inside the CRM, the ERP, the HR system, because that’s where they were born. Governing those needs no industry agreement, welcome as one would be. It needs the ability to read another system’s templates, check them against policy, and write changes back – continuously, not once. Call it repeated bi-directional migration. Converting a template once is the thing getting cheaper fastest; doing it repeatedly, in both directions, without drift, is a great deal harder. That’s the open problem, and it’s ours to solve.
Today we’re the solution of last resort – reached after the embedded module disappointed and the internal build ran out of road. The future version isn’t a system that gets chosen first. It’s one that, once reached, becomes accountable for every document the organization produces – the ones it builds and the ones it can reach.
And in a market with free conversion and open formats, none of that is permanent. You could leave as easily as you arrived, and we’d have to re-earn the position every year – first on authoring cost, then on whether we can actually govern what we’ve accumulated. That’s the market this series has been arguing for. It would be strange to argue for it and then hope it doesn’t arrive.
ActiveDocs builds document automation software that works with Microsoft Word: template design, template governance, conditional logic, approval workflow, version control, and audit trails, for banks, insurers, government agencies, and healthcare organizations running contract automation and other compliance-critical document generation at volume. If you’re weighing up embedded, DIY, and dedicated document automation software for your own template estate, get in touch.
Martin Srubar is Senior Technology Evangelist at ActiveDocs. He works with prospects and customers on where document automation fits their architecture, and feeds what he hears back into product direction.