In a meeting one day, the author of this page was met with disbelief upon stating:

"Many complex and semi-complex documents can be produced by a document assembly in their final forms - first draft"

This was not thought to be possible. Why not? In my experience, designing a system that is able to produce a majority of legal documents without post assembly editing is not impossible, it is just logic and reading enough documents to produce templates that take into account all the variations. It is difficult because of volume.

If you make a decision to include or not to include a paragraph, you can program a computer to ask you the same question. If you can program a computer to ask you that same question, you can program a template to deal with the answer.

Building document assembly systems that can seriously reduce drafting times is not an impossibility or an endless task. It is very doable and very profitable. I am not saying that every decision a lawyer makes can be programmed (and the result), but a great deal of them can be programmed. While the practice of law is considered to be many hazy shades of grey, there are a remarkable number of practice areas that are largely black and white when it comes to decision making and drafting. When I refer to a "decision", my meaning is a question of correct drafting. Entering a Borrower's name is a "field" or a "variable" - a changing piece of information between matters or projects. But dictating or not dictating a paragraph asking for trust funds is a "decision". A decision can refer to any choice you make that effects what appears in your signed document.

This case study deals with drafting a litigation type Claim in Queensland. Whilst this example may not apply to your firm specifically, the process and the concepts applies to every area of practice: if you can make a decision in drafting a document, a computer can usually be programmed to make the same decision and produce the same result. So whether it is designing decisions regarding the amount of a debt, security on a loan, the beneficiaries of a will or the trustees in a trust, the concepts are the same.

The disbelief that this approach is possible appear to centre around law being "too complex" - surely it is far too difficult to program a computer to simulate a lawyer's thought processes. Well, here it is:

The Challenge: How Many Decisions?

Many Claims that a lawyer may have to draft from day to day will not be able to be produced in a finalized form on first draft by a document assembly system - there are simply too many shades of grey. Defamation, TPA claims and the like simply change far too much from matter to matter to draft them systematically on a production line type system (you could easily reduce the amount that has to be drafted though). However, claims for goods sold and/or services rendered under a contract, loan agreements and credit card contracts, preference actions by a Liquidator, dishonoured cheques, WorkCover recovery claims and such are all readily automatable - the bread and butter of debt recovery and a large chunk of commercial litigation.

So here's the challenge: How many decisions in the lawyer's thought process are needed to draft a finalized claim, and why is producing a system that covers all these decisions impossible? Sometimes there will be very few decisions, but a plethora of language to be hand drafted. Other times, it is a case of (for the most part) if you can make a decision, we can program it. So lets look at a small example of a system to draft a claim. This hypothetical system will be able to draft claims for dishonoured cheques, "trade" type credit applications (not loan applications but supply agreements for say building supplies and the like), schooling & tuition and goods sold and/or services rendered. In addition, we will provide the ability for a user to state that none of these apply, and that they wish to draft a "generic" claim, meaning it is hand crafted and drafted. Along the way there will be several other options introduced.

Initial Decisions

Every system has some basic questions & "initial decisions" to be settled. These are things such as "who is our client?", "who are we suing?" and "what is our cause of action?". In our system, here are the initial questions we ask, and what the system does with the answers to those decisions:

• Are any of the entities in this matter a corporation? If the answer is "yes", pop up a help window from ASIC so the user can check to ensure that the instructions provided to us are correct (exact name of company, ARBN etc...)

  For each plaintiff:

• Their name
• Any trading name? Trading under the name or style of? Trading under the registered business name of? A division of? Not applicable?
• If they have a trading name of some type, what is that trading name?
• Address details. If a company, registered office details and incorporation date also

  For each defendant:

• As per the plaintiffs
• Note: this system "repeats" parties to the action. This means that plaintiff data goes into a "table" - you can have as many as you want. Ditto defendants. This setup allows indexing defendants (ie: direct a document against a specific or all defendants), plural calculations and other such things.

Time To Draft

Now that we know who the good guys and the bad guys are, we have to ask some questions so that the system knows how to prepare the document and produce it correctly. This is where the document assembly system cuts drafting times to a minimum and increases quality control.

• What court are we issuing from?
  • Small Claims
  • Magistrates
  • District
  • Supreme
• Which registry of the above court are we issuing from? (only one list is presented to the user, based upon the court type they are issuing from)
• What is our cause of action? (the list of possible causes of action will alter depending on which client is selected)

As soon as the user selects the type of court to commence action in, they are presented with a list of all the registries for that court. As soon as the registry is chosen, the system automatically knows all address & contact details for that court. The system will store this information so it never has to be manually entered by the user. As the system already knows which client we are acting on behalf of for this matter, it is a simple process to show all causes of action relevant to that client. Upon the user selecting which cause of action relates to this matter, the system is "set" so that it will ask only those questions relevant to the designated cause of action.

Cause of action is the first part of the system where we need to look at the decision making process of the lawyer. Everything before this point is clerical data entry - there is no real thought process to filling in plaintiff, defendant and court data (apart from calculating names & addresses). The user's answer to this question will govern all future questions asked in the system and will also dictate what content the system produces. Below is a list of the cause of action options presented and the system's reaction for each answer.

Dishonoured Cheque

Ask for the name of the bank & branch that the cheque was issued from, the account number upon which the dishonour occurred, the amount of the cheque that dishonoured and bank charges claimed in addition to the amount of the cheque. Total of the claim will consist of the amount of the cheque, the bank charges, and any interest claimed.

Credit Application

Ask for the date the credit application was executed, the terms of the default (14 days from invoice? close of following month? etc...). The "start" and "end" dates of the default, being the time over which the debt was incurred. Ask whether any payments had been made during the period and list them if so. Ditto any credit notes or refunds that may apply.

Credit Application and Guarantee

The same data as in "Credit Application", but also including the name and details of the guarantor(s), the terms of the guarantee (including the para reference in the contract, which may or may not be pre-programmed depending on the client) and the date of the demand letter to the guarantor(s) to pay the outstanding amounts.

Schooling & Tuition

Ask the user for student(s) names who were provided with the tuition, the start and end dates of the tuition that forms the cause of action.

Goods Sold and/or Services Rendered

Ask the user whether a) goods were sold, and b) whether services were rendered. The system will require at least one of these to be checked. Once answered, were the goods sold or services rendered provided pursuant to a contract agreement? (if so, revert to credit application type claim for pleading & particulars). If goods sold form part of the claim, describe the goods sold. If services rendered form part of the claim, describe the services rendered. Ask for the start and end dates of the supply of goods and/or services. Ask for whether payments, reductions or credit notes apply and if so, list them.

Generic Claim - Manual Draft

Skip all questions related to the specifically programmed claims. Simply ask for the parties to the action and the court registry to issue in.

If the user answers these questions correctly, they will be asked all the necessary information for the system to complete the document. If the user states they want to manually draft the claim, the system will skip all the questions which relate to the specifically programmed claims, and ask the generic questions that apply to most claims issued.  these questions would also appear the end of every Claim drafted

• Do I wish to claim default interest from the end date of the debt to the date of issue? (If yes, auto calculate this amount and display for verification).
• Do I need to draft a schedule of invoices, payments and credits? If yes, present spreadsheet for completion of each transaction that forms a part of the claim).
• Do I need to claim search fees?
• Am I able to serve all defendants by post? (If yes, auto calculate service fees. If no, ask for amount of service fee).

Finalizing the Drafting Process

Lastly, we need to ask the administrative type questions that go with any document drafting process:

• Select the author (from a list) who is overseeing this matter (if applicable)
• Select my name from a list as author of the document
• If I am a secretary, select my name from the list so that the document annotates who typed the document

The Final Product

As you can see, there were not hundreds of decisions involved in drafting the Claim. In fact, there were less than 50. The more claims that you wish to program and include in your document assembly system, the more decisions you will have to cater for however, it is not an unmanageable figure. The system basically asked who the parties were, what the cause of action was, and some details regarding the cause of action. These are the "moveable parts" of the claim - the information that changes from matter to matter.

Here's the best part - all of the different claims use a very small set of variables - its largely the same stuff over and over again. Most of it boils down to:

• relevant period start date.
• relevant period end date.
• claim amount (usually calculated by subtotals - dishonoured cheque amount + fees, loan + interest, credit limit + late fees etc...).
• any contractual information - signing, payment periods, penalty clauses.
• lending and interest rates and penalty rates.
• which party failed to take actions or avoid ommissions.

When combining a smooth decision making series of questions such as this (also known as an "interview"), with precedents and templates that are correctly organized and set up, drafting times are reduced to small fractions of "regular drafting" times. The court header will always be correct, so long as the user selected the correct court type and registry. Defendants and Plaintiffs will be laid out with smooth hanging indents, at the exact same width every assembly. Why? Because the user isn't typing the document and laying out the text every time, they are filling in the blanks, and the system is producing the document. The pleading for the dishonoured cheque comes out the same every time, regardless of who drafts the claim - because this type of claim must always contain the same information. Ditto for tuition fees and many other regular claims that are drafted on a day to day basis.

The Result

The resulting document (according to MSWord) was 1211 words in length. The system produced a document that calculated all plural references, as it "knew" how many plaintiffs and defendants were involved. As the user provided a "start" and "end" date over which the debt was incurred, the system was easily able to calculate the amount of interest to be claimed. Also, as the system knew which client this matter related to, and the user specified which cause of action was relevant, the system was able to select the correct pleadings, and ask the user only those questions required to produce a complete and correct resulting document.

What I am outlining here is a fairly simple system that can create 6 or so pages of court documentation with approximately 5 minutes of data entry to create one of 6 different claim types. Once staff gain trust in the system (being that correct data entry = correct document produced), the proofreading time is slashed to a few minutes, to peruse an extract of the data entered.

There were not many questions to be asked or decisions to be made and the resulting document was not complex. The template used contains all of the static content (such as required sections of the document) while the variables fill in the blanks. Depending on user choices, different wording for the Claim and Statement of Claim are selected and those blanks are filled in also, using the same set of data entered by the user.

If we took this system to the next level, we would include question sequences for many other types of claims, but also for "client specific" claims. For example, if your firm did the debt recovery for WorkCover Queensland, you would most definitely want the interview to run differently. Why? Because as soon as a user selected that the client was "WorkCover", the interview would ignore all the generic commercial causes of action and switch to the "WorkCover specific" causes of action (premium, premium and penalty, overpayment of claim etc...). Or perhaps you have a bank client that has 15 different loan facilities they seek recovery under - you would program these specifically.

The possibilities of document assembly are endless. As stated, if you can ask yourself a question when drafting a document and make a decision, you can program a computer to ask someone else the same question and program it to produce the same result as your decision. This may not always be true, but for many applications at law, it is.

The challenge

How many decisions are there to draft a claim, and why is producing a system that covers all these decisions impossible?

The response

Less than 50 decisions to be made and accounted for. Producing a system was not at all impossible or even mildly challenging.  A very straight forward system.

If you have a professional staff member who is prepared to sit down with a document assembly programmer and literally embed their intellect and approach into a system, it is purely a matter of structuring, planning and time before the system is done.

Following is a link to the document produced, which has been marked up with colour coding and comments. The data entered by the user is highlighted in red text. Content that is automatically calculated by the system without user entry is in blue text. Green text indicates legal content that was not actually "in" the Statement of Claim template, but instead, was contained in a separate template completely. The system "chose" which template to utilize, based upon a combination of the client chosen and the cause of action selected.

The static content (black colour) of the text is extremely important to the legal profession however, in document assembly terms, it is the least important, as it can be changed in a flash by a precedents manager who knows how to use a word processor. The point to these examples is not so much the legal correctness (which is the only important matter to a lawyer) but more towards the fact that legal content can be generated automatically with just a few short questions.

Please note: The document below contains mathematics based on an outdated scale of costs and fees and dates back to sometime around 2005. The reason for this is the system I have on my network is outdated, as my client maintains the system I provided them without my assistance or intervention. Also, the system was programmed in HotDocs 5.1, which is a somewhat outdated version. The interface is limited and of a fixed width. More current document assembly programs utilize a far more flexible and visually pleasing interface.

Click here to view the document