Legal Use Case

Legal Use Case

Bill of Sale

Tag can be used for document automation in the Legal sector, to create many different kinds of documents. This use case describes how a lawyer could use Tag to automate bill of sale contracts.

Goals

  • Save time for more important tasks
  • Eliminate manual data entry (using a pen on paper)
  • Reuse useful legal clauses
  • Keep it easy
  • Keep it easy

How is Tag used?

The following lists the main steps of this use case.

The starting point for most smart content projects is the desired output. What should the generated document look like, and what kinds of text fragments will be used to create it. Ideally start with an existing contract that can serve as a good example.

Bill of sale contracts typically have these components:

  • Static content and clauses
  • Contract details
  • Scope of contract

Static content and clauses refers to all the chunks of text that never change. Section headings, signature blocks, governing law clauses, and so on.

Contract details includes information about buyer, seller, the goods being sold, price, delivery location and sometimes more. For buyer and seller this includes name and some other form of identification, commonly an address.

Scope of contract refers to some indication of what clauses will be needed. This can often be reduced to a set of true/false questions. For example, are any of the following applicable?

  • security interest (existing legal claim or lien on the goods)
  • late payment penalty
  • warranty
  • fitness for a specific purpose (as opposed to “as is” condition)
  • inspection of the goods prior to sale
  • witnesses
  • notary public

There are many other possibilities, depending upon the nature of goods being sold.

At a minimum, a bill of sale requires three groups of data.

  • Parties information
  • Contract details
  • Scope of contract

How the parties information is handled depends on your legal practice. Are the parties known to you and, if so, can their identifying information be pulled from another tool or system (e.g., using CSV files)? If the parties are not known to you, this information can be entered manually when the contract is created.

Contract details are most likely entered manually when the contract is created. You can use text fields to collect names and short phrases, while text areas make more sense for longer descriptions (e.g., what goods are being sold). Specifying this distinction for the form is simple in Tag, and is done within the data setup screen.

The scope of contract, in this use case, will be entered manually. It amounts to a set of checkboxes which signal that specific clauses (or other text fragments) need to be included. Since contract details and scope are all entered manually, we can combine both into one “contract” data setup file.

The contract data setup file might look like the following.

Note that scope checkboxes are all grouped within a field section called “scope”. This makes the form display a little cleaner, but other than that has no other purpose (which means using a field section is optional).

When writing smart content, you often start with one template that contains all the static content you want to automate (e.g., sample bill of sale). This can be done by importing a word processing file, or copying and pasting from another system.

Next you replace buyer and seller information by inserting parties data. For many contracts, this has the added benefit of making the final contract more readable. All of the underlined spaces, which someone is expected to fill in manually, are replaced by logic bubbles. No underlines will appear in the final document.

For example, if the starting paragraph looks like this in a static contract.

In dynamic contracts, the same introduction would look like this.

Legal contracts are a great fit for content automation, in part because so many clauses are conditional. As you customize a contract for any situation, much of the thinking involves deciding which clauses are relevant. In fact, this is one of the most important services that lawyers provide for their clients. Therefore, improvements in this area could be valuable.

In this use case, each scope checkbox is used to include a specific clause or not. For example, if the standardWarranty field is true, the contract would include a clause something like “The Seller warrants that the Goods are free of any liens and encumbrances and that the Seller is the legal owner of the Goods”.

More complicated logic may involve choosing between more than one clause. This is where you can use a choose/when instruction. A choose/when inserts the first “when” that is true, and if none are true inserts the “otherwise” if one exists. This could look something like the following:

when -> isInternational checkbox is true insert the governing-law-international template
when -> isFederal checkbox is true insert the governing-law-federal template
otherwise -> insert the governing-law-state template

Yet another level of complexity can be supported using dynamic templates. In this case, clauses do not have to contain static text, but instead can also include logic and data. This could make sense for payment schedules, which can be defined in a wide variety of ways (e.g., lump sum, in installments, in installments with interest). Logic within the payment schedule clause would insert party names where appropriate, while describing the flow of funds over time.

Another consideration is the reuse of clauses between multiple contract types. For example, a bill of sale may require clauses that are also used in subcontracting contracts.

Tag makes sharing clauses (templates) between contracts (reports) easy. All shared clauses can be stored in one template file, which is then imported into as many contracts as needed. As long as all contracts reference the same data fields (if data fields are even used), sharing clauses is as simple as pointing to a file on your network.

There are many ways to approach template reuse. It can be kept simple as described above, or made as complex as necessary to suit the lawyer’s preferences. The key is to consider it a living document, that you continually add to as new clauses and conditions occur to you. Your smart content will keep getting smarter over time.

Tag creates forms automatically to match your data setup files, so data entry can occur as soon as contract content exists. By default, only fields that you use in contract text (templates) are displayed in forms.

Forms should be easy to fill out. Dates are entered using date pickers, you can tab from one field to the next, and dropdown lists can be used if you have a list of items to choose from. Errors in numeric fields are detected in the form by validation rules which prevent saving bad data.

The form for the contract data setup file is shown below, with the Scope field section initially collapsed.

When it’s time to enter Scope, simply click on the plus (+) icon to expand that section.

When the checkbox values are not obvious and/or the issues involved are complex, this section of the form is a money maker. Only a skilled lawyer can work through complex yes/no questions like this, and that represents clear value to their clients.

By eliminating mundane tasks (like finding relevant clauses, copy/paste, and adjusting formatting), an efficient lawyer can breeze through this important section and have a comprehensive first draft generated in minutes. And all this is done with zero copy/paste errors.

Once all the data is entered, it is time to generate. Simply click the magic wand.

Generation usually creates a new word processing document and saves it to a file, however it can also save as plain text or other formats.

The generate page also lets you export data. This allows you to create one CSV file that merges data from all similar contracts. This could be useful when looking for patterns of client needs, or the frequency of use for particular clauses. These kinds of insights can signal where it is worth investing more in content automation.

It is worth noting, that static contracts which are filled in by pen cannot be analyzed like this, unless data is extracted in some way (manual or automated). This represents a new data opportunity, which provides you with a way to mine your own contracts to better understand the inputs and outputs of your practice. Lots can be done to take advantage of this opportunity, but that lies outside the context of this use case.

Benefits and outcomes

These are the goals for this use case.

    • Save time for more important tasks
    • Eliminate manual data entry (using a pen on paper)
    • Reuse useful legal clauses
    • Keep it easy

    Time savings will increase along with the complexity of each contract. Using forms for data entry eliminates many manual steps involved in copy/paste merging of data from multiple sources. There is also less need to search through old contracts for useful clauses, or repeatedly draft similar clauses from scratch.

    The elimination of manual data entry is a significant benefit. The final contract will look much cleaner (no more long underlines), and you have the option to analyze the data gathered.

    Reuse of useful clauses is a big benefit. Once you have given a name to each clause, you only need to select them from a list to use them. A good naming convention goes a long way towards making clauses discoverable and easy to share.

    The end result should be very easy to use. Once the templates have been written, the time spent on each contract is primarily data entry. Entering data will only take a few minutes, at which point the parties can sign and you can move on to the next billable task.

    There may also be practice-level benefits if multiple lawyers use a standardized process. You can share standard fragments and build a shared clause bank. This would improve consistency in contracts between lawyers, and facilitate knowledge transfer for new ones. A rich and deep clause bank could also provide a competitive advantage over law practices that remain stalled using static, non-digital contracts.

    Once your practice’s generated contracts are up-and-running, consider other legal documents that would benefit from automation: legal letters, bylaws, guardianship documents, power of attorneys, wills, trusts, deeds, healthcare proxies and more. The list is as long as the wide range of legal practices.

     

     

    How do I learn more?

    Contact us for more information about this use case.