October Conference Schedule

by

This October finds me on the road.

Today I was in Lincoln Nebraska.  We ran a seminar on our Nebraska Probate System V (powered by GhostFill).  Over 3 hours we went in detail how to use the system and how to customize the forms.  We are now off to Atlanta for the LexisNexis CIC conference.  Lexis management has invited me to speak on a panel of document assembly specialists on how to make the most out of practice automation.  I have a little surprise … a preview of a real “sexy client”.  Attend the session and find out.

Correcting Bloated Images in RTF Templates

by

HotDocs, DealBuilder and GhostFill all work with RTF Templates.  On occasion, a template may include an image for a watermark, a logo, or some other purpose.  Thanks to an ingenious feature of Word, when you some a document to rich-text format (RTF) the images are converted to a useless, but huge windows metafile.  This ensures compatability with ANCIENT word processors, but does nothing for you.  In fact, a simple company logo can expand the size of a short letter from 20K, to 1,200K (or 1.2 MB).  And that is before you start adding text.  The solution is a simple change in the registry for WORD on each machine.

Read moreCorrecting Bloated Images in RTF Templates

Future of Document Assembly

by

For better or worse, the future of document assembly is on the Web. The web offers cheaper maintenance, quicker updates, and a more consistent look and feel. The web is also the most cost-effective on total cost of ownership (“TCO”).  The catch is that startup costs are much greater for web deployment of automated templates.  Particularly since most law firms wish to “dip before they dunk”, the presence of desktop or networked document assembly solutions is critical to the development of automated content.  In the past five years, millions of dollars have been invested in innovative web-delivery of automated document creation systems.  By contrast, the investment in client/server based document assembly software has been minimal.

The sole exception has been LexisNexis’s continuing development of the HotDocs platform.  Korbitec, once the leading rival to LexisNexis, has ceased further development of its powerful GhostFill document assembly engine.  No other viable vendor has stepped up to fill the gap and compete head-on with LexisNexis.  LexisNexis deserves real credit for investing resources in building an ever-more powerful version of HotDocs.  They should be encouraged to keep up the good work and rewarded with license sales.  As I have written in my review of HotDocs 2006 posted in Technolawyer, the HotDocs platform has been transformed into a toolkit that can do some amazing things to manipulate data and forms.  However, in the absence of a viable direct competitor on the client/server space, there needs to be a clear reason for LexisNexis to continue to innovate.

Before I talk about the future, let me talk about the present. Let’s look at the pricing of document assembly software.  HotDocs Standard desktop costs $300 and HotDocs Professional costs $850 per license.  What that means is that for a small user base (1-10 users) your software investment is very small. As the user base increases beyond 50 users, the cost of software starts to become a factor. The reality is that most document assembly installations start out as departmental efforts (under 20 users) or occur where the firm purchases a form set (in which case the “player software” is free). By contrast, online software starts at $12,500 and goes up to $100,000 for the server software.  These fees do not include the server hardware, the consulting services configuring (and securing) the webserver, or the usage fees charged by a number of vendors.

It is this GAP which forces many users to look at the “cheap” software and get locked in.  This benefits LexisNexis which offers both cheap HotDocs desktop software and a much more expensive HotDocs Server product.  The cost, however, is that the web-based developers (Business Integrity, iXio, Exari, Perfectus and others), have template development environments that offer alternative design philosophies some of which may be better suited to your firm or company.  But because the startup (or prototype) costs are so high, such software is only available to the AmLaw 100 law firms and large corporations.

The FUTURE of document assembly.

Microsoft, with the release of Vista and Office2007 has closely aligned its software with the web through Sharepoint webservices, integrated throughout.  The 2-ton gorilla in the room is Microsoft which is starting to move into the “vertical” space and recognize the needs of legal.  Microsoft Legal is currently using Business Integrity’s DealBuilder product, which means that they have had an opportunity to evaluate closely a very power and flexible automation system.  It is only a matter of time before some of the features of DealBuilder show up in future versions of Office and Sharepoint.

Exari has announced the conquest of the “holy grail” in document assembly—The ability to assemble a document, send the result out for comments and editing, and then to bring the document back into the automation environment so that the variables and business logic continue to function on what is now the “customized template”.  They offer a feature which previously was only available in Smartwords (now defunct) and Rapidocs via a proprietary word-processor.  With the advent of WordML (a new open file format of XML files packaged together) it is possible to “safely store metadata” about the rules and structures of a word document, separating content, structure and format.  All of the web based developers are looking at what can be done with WordML to allow the “round tripping” of templates and documents.

Word currently allows you through macros and forms (including InfoPath and Taskbar data entry) to do much of what document assembly software does.  The catch, is that building such system requires specialized expertise in programming.  That means, to do court forms, form agreements and other automated documents requires hiring an experienced programmer.  The strength of the document assembly software is the “easy markup” which can be understood by the lawyers and managers who work with these forms, and the ease of deploying updates. Also with the separation of “business logic” from the word document, such document assembly systems allow the templates to run on multiple versions of Word (and WordPerfect) without recompiling macros.

LexisNexis is continuing to explore new options for its HotDocs platform.  A while back, it built into HotDocs Professional the ability to “Publish Templates” for HotDocs Server.  This means that for a very low investment, you can develop templates for internal use, and when the templates (and users) hit a critical mass, then invest in HotDocs Server.  We at Basha Systems, now work with Accudraft and offer HotDocs Online hosting services for our clients.  We offer our clients NO STARTUP COSTS and NO HARDWARE COST hosting.  For a nominal monthly fee, plus ongoing document automation consulting, we can put a law firm or company online.

So the future is ONLINE … it is just a matter of time.

Why does my email inbox take so long to load

by

When you open your Inbox it may appear to take up to several minutes to load. Time Matters will seem like it is not responding.  Time Matters inbox is “personal” to each user. The inbox contains both Internet Email and Time Matters emails, as well as attachments. The mailbox can quick get overloaded, even when you appear to have been keeping the list of items in your inbox to a manageable roar. In fact, your mailbox is most likely overloaded. There could be hundreds of emails in the Deleted Items folder. There could be emails in subfolders. All take time to load.

The solution lies in regular dilligence on managing your inbox.

  • Keep the number of items in your inbox folder to under 50
  • Set your mailbox settings to show on email list (not inbox) any records that have been associated with a Contact or Matter
  • Create a folder for List-Server mail and set a rule to automatically move the incoming email to that folder
  • Empty the deleted items folder (right-click on folder and choose empy bin)

Limit Spreadsheet Lines Appearing

by

You want to control the number of lines that appear on a dialog that displays in “Spreadsheet” style.  Quite often, the default number of lines visible on a spreadsheet style dialog are aesthetically offensive. We need to control this for two reasons: 1) its ugly; and 2) screen real estate is quite often at a premium.

Basha Systems use a CNT prefix for specific purpose number variables, to differentiate between a “true” number variable used in document assembly templates, and those number variables used for tracking, counting & limiting. Lets presume we are dealing with a spreadsheet to enter in children’s names and DOB’s. In the dialog PRIOR to the spreadsheet dialog relating to children, create a variable something similar to Var_CNT. The prompt should be something like “How many children do you wish to enter?” In the script of the spreadsheet dialog, place the following:

LIMIT Var_CNT

This will ensure that the spreadsheet is LIMITed to the number of lines that the user has indicated are required. You may wish to REQUIRE the Var_CNT variable, so the user must enter a number to gain access.

If the spreadsheet dialog is actually “Spreadsheet on Parent”, you should script the dialog so that it doesn’t even appear until such time as the Var_CNT variable has been answered. Using this approach, the REQUIRE option is redundant.

Migrating from Legacy Document Assembly Systems

by

Over the past decade, document assembly systems have come and gone.  Some, like HotDocs 4.2, HotDocs 5.x, CAPSAuthor, WinCAPS, SmartWords, Agility, FastDraft, Form Bank, MasterDraft, MillRace, NovaDocs, PowerTXT, Scrivener, ThinkDocs, and WorkForm, are no longer supported.  Some like GhostFill, ProDoc, WinDraft, and Perfectus have only a small developer community that provides limited support. Others, like WordVBA and Wordperfect have macros tools that require dedicated technicians to support and maintain. Yet other systems, like Pathagoras, D3 and qShift lack support for traditional programming techniques like repeat loops, nested IF statements, and variable scripting.

The result is that thousands of legal templates are locked in poorly supported legacy systems, representing hundreds of thousands of hours of programming and invaluable legal workproduct.  This article explores a process of identify and extracting the business rules and workproduct from these legacy systems and moving them to more powerful and better support platforms such as HotDocs or DealBuilder.

At root, all document automation systems are the same.  They address the same fundamental issues: which documents, paragraphs, and phrases to include in output document and what data to use to fill in the blanks.  The hard work in document assembly programming is NOT the programming, but rather crafting the business rules which govern whether to include or exclude text and how best to fill in the blanks.

It is for that reason that we have developed a universal approach to marking up documents and document automation interviews that can work with any document automation system.  This approach allows us to take templates in legacy document assembly systems: (1) identify and catalog all the conditional rules, (2) identify and fully describe all the variables (by function, type, prompt and defaults), (3) identify all the dialog objects and scripts, and (4) extract all the text objects, clauses and subdocuments.

From there we structure in Excel a prototype interview in HotDocs, GhostFill or DealBuilder) that mirrors the functionality of the legacy system.  In describing each new variable, object, script in the new platform, we maintain a reference to the comparable object in the legacy platform.  Once the interview and datastructure is completed in the new platform, we turn to the text objects, clauses and subdocuments.  Where possible, we have preserved the markup of the legacy platform in the text documents.

We generally consolidate the text objects into master templates so that they are more easily edited as a whole.  Where text objects are used in multiple templates, we keep them separate and use INSERT or INCLUDE commands to bring in the text where appropriate.  As part of the process, we also strip the text of all formatting and then carefully apply a Word style sheet using outline schemes, paragraph styles and character styles to handle ALL text formatting, spacing, letting, kerning, outlining, numbering etc.  This allows use to use the stylesheet pro grammatically to change the document templates and the assembled documents.

There is a tendency to want to “throw out the baby with the bath water” when a firm decides to adopt a new document assembly system.  While the process described above TAKES time and planning, it does preserve the MOST valuable part of the automation process, the attorney time and workproduct.  If you have a system that WORKS, but is old and dated, it is best to use that as a base for the new system, rather than to scrap it entirely.  That gives you a result that will WORK when delivered.  And then, you can have fun, spend money, adding in the new features and enhancements that the new document automation platform offers.

LEGACY DOCUMENT ASSEMBLY PLATFORMS

HotDocs 4.2 & HotDocs 5.x: LexisNexis no longer supports these early Windows versions of HotDocs.  Hundreds of thousands of licenses to HotDocs were bundled with WordPerfect Legal Edition. Early HotDocs had limited scripting and presented questions in a series of popup-dialogs as the document was assembled from within Word or WordPerfect. With HotDocs 6/2005/2006/2007, HotDocs transitioned to a single interview object and moved the assembly outside the word-processor into an RTF-Assembler.

CAPSAuthor & WinCAPS: Once the best and most advance document assembly platform for MS-DOS.  CAPSAuthor still runs in a DOS-window.  WinCAPS is the assembly environment, built to run in Windows 3.1 on a 16-bit platform.  There were hundreds of systems built with CAPS, including several that were sold commercially.  We were responsible for converting one CAPS system, Drafting Wills and Trust Agreements (“DWTA”) from WinCAPS to the GhostFill platform.  We have also converted a document lending system that had over 5000 CAPS objects into GhostFill. The process of extracting the business rules, text and variables used for those conversions, could just as easily been applied to converting those systems to HotDocs.

SmartWords: Built on bTrieve and Xyrite, a very sophisticated engine. When the owner went out of business, the software was taken out of circulation.  Two years ago, Basha Systems converted Wealth Transfer Planning, the one commercially viable product built on Smartword, to the HotDocs platform.  That content is now owned by Interactive Legal Systems, which built a custom wrapper around the HotDocs templates that expanded on the document and answer management features of the original software.

Agility, from RealWorld Solutions, was a DOS-based product most suitable for offices using pre-Windows versions of WordPerfect.  The program had a deliberate strategy of simplicity.  Agility included most of the basic features one would expect in a document assembly tool, including nested logic and repeat loops.  But as there is no Windows version, non integration with any word processor, and no math functions it lacked viability for search document assembly applications.

FastDraft, from Interactive Professional Software, allowed a user to select a type of document, choose from available clauses and then fill in the blanks in the selected clauses.  The user could reorder the clauses and easily back up to previous steps in the process.  In this way, it was similar to the more powerful qShift.  FastDraft lacked features that make sophisticated rule-based practice systems, such logic, math functions, and validation of dates and numbers.

ThinkDocs started out as a graphic forms engine, which applied the concept of data stored in a database and hooked “live” into the assembled document.  It used DocVariables in assembled documents to retain a live-link to “answer data” stored in a database after the document was assembled.  As such, the system lacked any support for conditional logic on text in the template, unless the text itself was stored in the database and used to set the value of a DocVariable in the assembled document.  ThinkDocs appealed to users because of the “live” link—but in practice such live links worked only with simplistic documents – those templates lacking any complex embedded logic.

Form Bank, from now defunct ExperText Systems Ltd, was developed by Doug Simpson.  It made clever use of an automated teller metaphor, with developers depositing materials into the system, users withdrawing them, and a :”bank manager” determining who can do what.  It depended on Microsoft Access for a database of clauses, questions and other components that could be shared across multiple forms and managed by a group of cooperating users.

MillRace, from Old Mill Software was designed to allow attorneys to build documents by combing through annotated collections of forms and clauses, based on client requirements and negotiated issues.  It rejected the “QUAIL” – question, answer and imbedded (sic) logic – approach of most document assembly system. Development was ceased in 1997.

NovaDocs, from Novation Corporation in was conceived by James Conger.  It provided the basics of document assembly in an easy-to use and attractive package that exploits such features as collapsible outlines and drag and drop. Clauses and questions could be edited on the fly while assembling documents and making for little distinction between developer and user modes.  However, it lacked conditional logic, repeat loops, answer validation and other features standard in most document assembly engines.

PowerTXT, from Intercon Associates, Inc. was a feature rich, and easy-to-use program that evolved from FlexPractice, a popular DOS-based document assembly program in the 1980s.  In PowerTXT, model documents showed up as graphical outlines on the screen.  After users point and click thyeir way through necessary decisions, questions are asked that gather the details needed to assemble the desired documents.  The program did not support traditional programming techniques like repeat loops and nested IF statements.  Those who liked the outline and document-model structure of PowerTXT, would like IXIO.com’s qShift document modeling software which places clause libraries and document models on a privately hosted and secured web-server.

Scrivener was created by Dan Evans.  It was distinctive in being build on a true rule-based expert system engine and was among the first document assembly products to make good use of outline representations of document structure.  It provided support for incremental model revision as you use the system in everyday practice.

WorkForm and Visual WorkTool, developed by Analytic Legal Programs, Inc. was a powerful set of document assembly tools was a dominant player in the 1980s.

DOCUMENT ASSEMBLY PLATFORMS LACKING TRADITIONAL PROGRAMMING TOOLS

Pathagoras: Developed by Roy Lasris as that “alternative” to programmed document assembly. This system supports “quick and dirty” clause based assembly with rudimentary variables. If you want to build a library of “snippets” for reuse and throw some fields in, this software can save you time over traditional word processing. But to call this software document assembly suggests that this software is in the same league as HotDocs and DealBuilder (which it isn’t). That said, there is a lot of good forms built by lawyers with Pathagoras that could be made better in HotDocs.  The markup and structure of Pathagoras would make conversion fairly easy, and give users much more power and flexibility.

D3 Documents. MicroSystems SQL-Based clause manager and form filler is a great tool for fitting into the workflow of simple documents.  As a replacement for WordVBA and macros, it is a major improvement, serving as the glue for all those communications and simplistic documents.  What D3 does not support is traditional programming techniques for nested IF statements, loops, repeats and while statements, as well as script objects.  However, it represents a good start in that it forces the user to identify the data necessary for assembling templates and actually choosing and structuring the model language that will form the basis of the template.

qShift.  IXIO built a system that I would have loved to use when I was practicing law a decade ago.  It automatically takes a well-structured agreement, and breaks it into its constituent elements and presents a document model to which you can then apply automation rules.  We have reviewed it elsewhere.  It is great for choosing and crafting and dynamic form which will then be customized to a particular clients needs in a word-processor.  However, it lacks support for traditional programming techniques used in document automation software: multi-variable conditions, nested IF statements, computed variables, variables that share the same data source but are displayed differently, and full string and arithmetic manipulation capability.

WinDraft, from Eidelman Associates, was innovative and powerful when it come out in the 1990s.  It accomplished, inside the WordProcessor a level of dynamic automation that it took the other document assembly software years to catch up to.  However, the website (www.lawtech.com) hasn’t been updated in several years.  It’s business logic works with a simplified document markup and structure that did support nested logic and variables.  As such, the systems can be easily converted to HotDocs and DealBuilder.

CONTENT SYSTEMS:

DL Drafting Libraries: This proprietary form set, originally in DOS, but now in Windows, represents the “TurboTax” for
LawGIC
WealthCounsel

Instruction Model: ADD TEXT TO MULT_CHOICE

by

This tip covers when to use and how to use the HotDocs Instruction Model: ADD TEXT TO MULT_CHOICE.  HotDocs supports dynamic multiple choice variables.  A list of options (and their associated prompts) for a multiple choice variable can be seen in the definition of a particular component. However, this restricts the user to options known at the time that a component file is authored. This instruction model lets the developer dynamically change the option values and their associated prompts based on answers given by the user during an assembly.

What are the elements?

  • ADD: The instruction to Add Text
  • TEXT: A Text Value, a Text Variable, or a Text String consisting of Text and Variables
  • MULT_CHOICE: A Multiple Choice Variable (Single select and Multi-Select)

Other Related Instructions?

  • CLEAR MULT_CHOICE:  Will clear ALL options and prompts for a Multiple Choice Variable

How do you use it?

1. Build from a Repeat

The sample below is used to set the options for a Beneficiary selector.  This option could itself appear on a REPEAT.  The beneficary variable is first CLEARed. Then the script loops through the list of children, adding each child’s name, one at a time to the option list.

CLEAR BENEFICIARY Name MC
REPEAT CHILDREN RPT
ADD CHLD Name TE TO BENEFICIARY Name MC
END REPEAT

2. Build from a Script

The sample below is used to set the options for a Beneficiary selector.  This option could itself appear on a REPEAT.  The beneficary variable is first CLEARed. Then the script loops through the list of children, adding each child’s name, one at a time to the option list.

CLEAR CLI Married MC
ADD "Married|Client is married" TO CLI Married MC
ADD "Single|Client is single" TO CLI Married MC
ADD "Divorced|Client is divorced" TO CLI Married MC
ADD "Widowed|Client is widowed" TO CLI Married MC

3. Build from a Repeat and Add Custom Prompt

The sample below is used to set the options for a list of children to disinherit from a will.  The variable is first CLEARed. Then the script loops through the list of children.  For the option value, it adds each child’s name.  However, for the prompt, it puts in the child’s relationship to the , one at a time to the option list.

CLEAR HEIR Disinherit Name MS
REPEAT CHILDREN RPT
// Change prompt based on gender of child
IF CHLD Gender MC = "Male"
ADD "«CHLD Name TE»|Client's son «CHLD Name TE»" TO HEIR Disinherit Name MS
ELSE
ADD "«CHLD Name TE»|Client's daughter «CHLD Name TE»" TO HEIR Disinherit Name MS
END IF
END REPEAT

SPECIAL NOTES:

  • You must create the Variable and assign a default option (e.g. “Name Goes Here” or “1″)

     

  • You must use a computation script for the CLEAR and ADD instructions.

     

  • The script must be processed before you display the Multiple Choice Variable.

     

  • However, given the way the HotDocs interview works, you can accomplish this by putting the computation on the Dialog Script where the Mutiple Choice Variable is used, or in an INTERVIEW script.  If you choose the latter option, it can go anywhere in the script.

Why do my autoentry forms include the wrong task links

by

Auto entry forms are a hybrid between chains and notes. They allow you to structure your tasks and events, much like a chain. And they also allow you to take notes on your tasks. However, if you convert an outline to an Auto entry form, the tasks associated with the underlying record (not the new record) are link to the outline topics.  It is simple to save an outline as an auto entry form. However, before you do that you should make a copy of the form and then remove the links to any associated records.

  • Make a copy of the outline
  • Remove all links to client and matter
  • Make a generic version of the description
  • Right-click on any outline elements that are linked to a task or event records and disassociate the link
  • Standardize and clean up the language
  • Click on the Save As Auto entry Form

You are now ready to go.

SET Command and GRAYed Variables

by

You need to SET the value of a variable, but want users to be able to edit the value even after it is SET.  HotDocs will GRAY a variable (prohibiting editing) if the SET command is processed on the dialog, and DEFAULT will not overwrite a variable’s value.

A “regular” script to SET a variable to a value (based upon a Multiple Choice variable) probably looks something like this:

IF ANSWERED ( Var_MC )
IF Var_MC = “1”
SET Var1_TE TO “red”
ELSE
SET Var1_TE TO “blue”
END IF
END IF

As soon as Var_MC is answered, Var_TE will acquire an appropriate value, and subsequently GRAYed out – because it is processed dynamically by the dialog script, and whilever those conditions are met, the variable will not be editable.

We need to avoid HotDocs GRAYIng the variable. The solution? A button that calls a computation.

Lets say we create a variable called Var1_CO – this is the variable that will be called by the button on our dialog. The content of this computation will be exactly the same as the script above. We don’t wish to do anything different, we just wish to shift the source of the SET command.

In our dialog additional text section, we type

@COMPUTE:Var1_CO: Populate

@COMPUTE is the command to tell HotDocs we want a button to call a computation. Var1_CO is the name of the computation variable we are calling. Populate is the button text which will be displayed. When we click this button, the value is SET (provided all conditions have been made), and the variable is editable.

The Holy Grail

by

There is much talk about the “Holy Grail” in document assembly.  As those who have seen “Monty Python and the Holy Grail” or more serious students of the Arthurian Romance (as opposed to those who have read “The DaVinci Code”, the Holy Grail is a “chalice” or “cup” which held the blood of the real Christ, was kept as a holy relic by the church for centuries and then was lost to history.  During the middle ages, knights went on quests to “find” and “recover” the Grail.  The Grail was never found.  But the “search for the Grail” filled up thousands of pages of literature, and the hunt for the Grail kept thousands of knights diverted in a quest that kept them from seeking to overthrow corrupt monarchies.

In the world of document assembly, one vendor has claimed to have achieved “the Holy Grail”.  The technology will not be available till late in 2007.  When it is, we will review it.  The question is not whether the Grail can be found, but whether it will be the “solution”.

In a recent newsletter, Exari claims to have achieved the Holy Grail in Document Assembly

The Holy Grail: A Document Assembly System That Reuses Negotiated Clauses
There’s a favorite question that people love to ask when they’re pondering whether document assembly will work for them. It usually goes something like this:

“That’s great, I answer all the questions, the system spits out a great first draft, I send it off to the other side, and their lawyers mess around with the fine print of clauses 11 and 23. Now, can I shove that document back into the document assembly system and change a few of my previous answers?”

http://exari.blogspot.com/2006/11/holy-grail-of-document-assembly-is.html

Looking into the Myth

This article inspired me to look into The Holy Grail and its application to the world of document assembly.  As a youth, I was entranced by the Grail myth.  I knew all the players: Percival, Gawain, Lancelot.  And so, when a document assembly vendor claimed to have achieved the grail, I thought I should take a look.

In the wikipedia encyclopedia, the Holy Grail was:

….  the dish, plate, or cup used by Jesus at the Last Supper, said to possess miraculous powers. The connection of Joseph of Arimathea with the Grail legend dates from Robert de Boron’s Joseph d’Arimathie (late 12th century) in which Joseph receives the Grail from an apparition of Jesus and sends it with his followers to Great Britain; building upon this theme, later writers recounted how Joseph used the Grail to catch Christ’s blood while interring him and that in Britain he founded a line of guardians to keep it safe. The quest for the Holy Grail makes up an important segment of the Arthurian cycle, appearing first in works by Chrétien de Troyes.

http://en.wikipedia.org/wiki/Holy_Grail

In the literature of Chrétien de Troyes, a book called The Arthurian Romances, and other literature, the Grail was a “physical object”.  It is not that the Grail was illusive (it was certainly) and well hidden behind the walls of a fortress (it was), or that riddles needed to be solved and quests achieved. All these were true.  However, the ultimate criteria for “achieving the Grail” was “purity”.  Sir Lancelot, perhaps the greatest knight of all Chistendom, could never achieve the Grail.  For despite his strength, despite his intelligence and ingenuity, and despite his great experience and wisdom, Sir Lancelot lacked a pure heart.  He was (of course) an adulterer, sleeping with the Queen.  And so while Sir Lancelot could come within the presence of The Grail, he could not actually see or achieve the Grail.

What the Grail means today

In some ways, what Exari claims to have achieved parallels the Grail myth.  They have claimed to have built a tool that will effectively import “negotiated changes” back into a template.  When I asked to see the Grail (oh… I was not worthy), I was told to come back in a few months when it went into beta—Not quite yet.  Was this an announcement of a technology like Microsoft, before it existed?  I had a client who was intrigued in building a web-based contract management system and wanted it now. I was on my quest.

But the more serious question is whether the eXari Grail will offer the miraculous curative powers of the real Holy Grail.  This made me ponder.  If you take a “bad form” and automate it, will the Grail of document assembly save you.  Or, will it more likely allow you to continue reusing a poorly automated template well beyond its natural life.  Will the “Grail” be used to prop up a corrupt Monarchy that should long ago have crumbled of its own weight.  Will the “lack of purity” … or poor quality of the automated template mean that you will “not achieve” the bliss that comes from possessing the grail.

When lawyers fail to look at contract automation as an iterative process of regular updates and redesign of forms, such systems fail to meet their full potential.  In fact, it is the “lack of the Grail” that has been the biggest stimulus to effective authoring of templates.  By forcing the template designed to “anticipate” the negotiable issues and build rules, it creates better contracts, better systems, more power.  Yes, I am sure my clients would love to have their own “Grail”.  But in the end, I have a concern that it will diminish their impetus to put the proper resources into automation.  It will allow them to go back to the bad old days of word by word negotiation.

Further Details from Exari:

But there’s good news. The holy grail is coming. When Exari V5 ships in the first half of 2007, a big part of this problem will be solved.

In simple terms, any document produced from Exari which then goes through a process of negotiations (typically in Word) will be able to be “round-tripped” back into Exari in a way that preserves any negotiated changes to the text of particular clauses. This means you’ll be able to save the answers given during document assembly, as well as the edits made during negotiations, and re-use them against the same template, or even against an updated version of that template. So it doesn’t matter that the template has changed since last year. You simply load it all up and what’s relevant will be used, and the rest will be ignored.