Length Isn’t Complexity: How I Look at Document Automation 

I used to think long documents meant complex automation 

It seems obvious, right? 

If someone showed me a 120-page trust and a 10-page document, my first instinct would be that the trust has to be more complicated to automate. 

More pages. More work. More complexity. 

But the more documents I’ve seen over the past 25 years and the more conversations I’ve had with people trying to automate them, the more I’ve realized: 

Page count really doesn’t tell me much. 

I’ve seen huge documents that are actually pretty straightforward. 

Put the name here. Insert the date there. Repeat that information throughout the document. 

And then I’ve seen much shorter documents where I think: 

Okay…there’s a LOT going on here. 

Because behind those few pages are conditions, calculations, people playing multiple roles, different documents being generated based on one answer, and relationships between people and entities. 

That’s the stuff I’ve learned to pay attention to. 

So now, when someone tells me, “Our documents are really complex—they’re over 100 pages,” my brain immediately goes somewhere else. 

I want to know: 

What does the document have to understand? 

Over time, I’ve found myself coming back to five areas. 

1. How much is actually happening on each page? 

This is what I think of as density. 

Some pages really are just fields. 

Name. Date. Case number. Judge. 

Nothing wrong with that. Sometimes that’s exactly what you need. 

But other pages are doing a surprising amount of work behind the scenes. 

Maybe custody language changes depending on whether parenting is joint or sole. 

Maybe most clients use a standard holiday schedule, but some need a customized one. 

Maybe a provision in a trust changes when a beneficiary reaches a certain age. 

When someone starts explaining a template to me and I hear: 

“If they answer this, then we use this section…” 

followed by: 

“Well, unless they also answer this…” 

and then: 

“Oh, and in this situation we do something completely different…” 

That’s usually when I think: 

Okay, now we’re getting into real automation complexity. 

It’s not the number of pages that catches my attention. 

It’s the number of decisions hiding behind them. 

2. Why are we entering the same person again? 

This one drives me a little crazy. 

Let’s say Jennifer Marie Carter is my client. 

Jennifer is also the petitioner. 

Why should I enter Jennifer once as my client…and then enter Jennifer all over again because she’s also the petitioner? 

She’s still Jennifer. 

“Client” and “petitioner” are simply roles she plays. 

Now flip the matter. 

This time I represent David, and David is the respondent. 

I shouldn’t have to rebuild everything because my client happens to be on the other side of the “v.” 

I should be able to tell the system: 

Jennifer is my client. 

Jennifer is the petitioner. 

Or: 

David is my client. 

David is the respondent. 

And then move on. 

I find myself coming back to this question a lot: 

Why am I telling the system something it already knows? 

Every time someone has to re-enter a name, address, birthdate, or other piece of information, we’re creating more work and another opportunity for something to be entered incorrectly. 

The same issue shows up in estate planning. 

A person might be a trustee, successor trustee, beneficiary—or more than one of those at different points. 

To me, good automation should understand the difference between who someone is and the role they’re playing. 

That’s what reusability and roles really means. 

3. Who is remembering which documents belong in the package? 

This is another question I like to ask when I’m looking at someone’s process. 

Because sometimes the individual documents aren’t the hardest part. 

The hard part is knowing which documents you need. 

Maybe a California loan requires one package and an Idaho loan requires another. 

Maybe the county determines which probate forms need to be included. 

If someone on the team is expected to remember all of that every single time, I don’t really consider that process fully automated. 

I want to be able to choose California and have the system know what California requires. 

Choose Idaho, and it adjusts. 

Choose a different county, matter type, or deal structure, and the right documents follow. 

I don’t want someone keeping all of that logic in their head. 

That’s exactly the kind of repetitive decision-making I want the automation to take off their plate. 

4. Why are we reaching for a calculator? 

This is one of my favorite signs that there’s an automation opportunity hiding in plain sight. 

If I watch someone creating documents and they stop to open a calculator, pull up a spreadsheet, or do the math in their head, I immediately wonder: 

Could the system be doing that for them? 

Maybe we know a child’s birthdate. 

Why should someone calculate the age manually? 

The system already has the information it needs. 

Maybe we know the marriage date and separation date. 

Maybe we have a loan start date and a 30-year term. 

Maybe we have the principal, interest rate, and number of days. 

Why should a person calculate the maturity date or daily interest? 

And if the document needs to say both $1,250,000 and “one million two hundred fifty thousand dollars,” why should someone type both? 

These might seem like little things individually. 

But I’ve learned that document automation gets really powerful when you stop asking people to do all of those little things. 

5. How are all of these people and companies connected? 

This is probably where I see some of the most interesting complexity. 

Because eventually, you stop dealing with individual fields and start dealing with relationships. 

Think about an estate plan. 

A client has children. 

Those children may have children. 

Now we have grandchildren. 

Some of those people may become beneficiaries. 

What happens may depend on their age, their relationship to someone else, or choices made earlier in the interview. 

That structure matters. 

Loan documents can get just as interesting. 

You might have a company signing on behalf of another company. 

And then that company has two individual managers who need to sign. 

When I see a signature block like that, I’m not thinking: 

“Wow, that’s a long document.” 

I’m thinking: 

“Does the system actually understand how all of these entities relate to one another?” 

Because if it does, it can build the signature block correctly. 

If it doesn’t, someone is probably fixing it manually. 

Three documents can be “complex” in completely different ways 

This is why I like showing people real examples. 

Take a Utah divorce petition. 

At first glance, parts of it are simple: names, case number, judge. 

Then you start looking underneath. 

Who is the client? 

Are they the petitioner or respondent? 

How old are the children based on their birthdates? 

Which children are minors? 

What custody language applies? 

What holiday schedule should appear? 

What are the income totals? 

Suddenly, there’s a lot happening. 

Now take a promissory note. 

We have a loan amount, rate, and dates. 

Pretty straightforward. 

Until the borrowers are an Idaho LLC and a Wyoming LLC. 

The maturity date needs to calculate automatically. 

Daily interest needs to calculate. 

The dollar amount needs to appear numerically and in words. 

The governing law or document package may change depending on the state. 

And one company may be signing on behalf of another company, followed by two managers. 

Again: 

A lot is happening behind the document. 

And then there’s estate planning. 

Children. Grandchildren. Trustees. Successor trustees. Beneficiaries. Ages. Distribution provisions. QTIP versus credit shelter decisions. Percentages. Different documents depending on the circumstances. 

A finished trust might be 120 pages. 

But I’ve learned not to be impressed by the 120 pages. 

I want to know what had to happen to produce the right 120 pages. 

That’s where the complexity lives. 

Does that mean you need Knackly? 

No. 

And I genuinely think that’s important. 

If you show me a template and it’s mostly: 

Put the client name here. 

Insert the date. 

Put the address here. 

I’m not going to try to convince you that you need sophisticated automation. 

You probably don’t. 

There are simpler and less expensive ways to solve that problem. 

But when someone starts saying things like: 

“Well, if they choose this…” 

“This person is also the trustee, unless…” 

“We need these documents in California, but not Idaho…” 

“Someone has to calculate this before we generate the note…” 

“This company is actually signing for this company…” 

That’s when my ears perk up. 

That’s the kind of problem Knackly was built to solve. 

Here’s what I’d do before choosing any automation platform 

Grab one of your real templates. 

Not your easiest one. 

Grab the one that makes everyone groan a little. 

Then forget about the number of pages for a minute. 

Look for five things: 

Density. Roles. Document sets. Calculations. Data relationships. 

And when you talk to an automation vendor, give them those examples. 

Don’t just let someone show you how easily their platform can put Jennifer Marie Carter into a blank. 

Ask what happens when Jennifer is both the client and the petitioner. 

Ask what happens when the next client is the respondent. 

Ask the system to calculate the maturity date. 

Ask it to figure out which documents belong in the package. 

Give it the company signing for the company with two managers. 

Show them the messy stuff. 

Because after seeing enough documents, that’s the biggest thing I’ve learned: 

The question isn’t whether a platform can automate a document. 

It’s whether it can automate the way your documents actually work.