Do what I say … not what I do

Document assembly anecdotes anyone?  Today I was called on to draft a consulting agreement for a new project. I had sent the client a Term Sheet in an excel file which laid out the documents to be automated, the terms of the project, the price for the software, and the phases of delivery. We had reached an agreement. Now, it was just a matter of formalizing the arrangement.

Now I had designed a Master Agreement and project schedule template in GhostFill to handle this very document type. The interview had a range of variants. The output came close to what was required. However, the result came short of “assemble and deliver”. It required another hour to polish and clarify the terms. Now this is where I fell down.

I tell my clients, go back to the master template, make your revisions there, and reassemble. That way the system continually improves to meet new issues. Of course, I was in a rush to get the document out, and didn’t take that wise step of “do what I say”. The result is that I am doomed to repeat the same corrections for the next agreement.

Luckily, I have another project about to go to contract. If I am less rushed, I will tackle improving the template, rather than repeat my mistakes.

Practice Systems – Starter Kits

From a collection of templates to a “practice system” interwoven with document assembly – is this a business model that would be of use to all the would-be Basha clients out there? Let us know!

In automating a collection of documents that form a “Practice System” there is inevitable overlap between the information required between the documents constituting the practice system. Properly attacked, there are two phases to such an automation project:


Identifying all the variables and organizing them into a series of dialogs/pages and grouping the dialogs/pages into logical interviews.


Using those variables to markup and code the templates.  Many document assembly tools allow you to drag-and-drop from a dictionary/component file into a document and then save that document as a template in the practice system.


What if the first phase could be eliminated?  What if someone already had a taxonomy of variables and questions that covered most, if not all the questions you needed for the practice system?  Would that be valuable?  Could you use that object? And what would you pay for that convenience which could save you hundreds of hours (and tens of thousands of dollars of opportunity cost developing that dictionary)?


If you had this dictionary of variables, you could then take your forms and drag-and-drop or select-and-wizard, quickly replacing all you matter-specific information and your conditional text with codes.  These could be processed through an automation tool … and voila, you would be done with the automation project.


We are exploring whether this is a possible business model … Is there a market for “practice systems” as taxonomies?  Let us know.

Dealing with Irrelevant Answered Variables in HotDocs

Irrelevant answered variables in HotDocs can have their consequence.  This blog notes the problem, its consequences and some solutions.

HotDocs is very friendly, as programs go, in dealing with “unanswered” data.  HotDocs gives you the option, if it doesn’t have sufficient data to fill in a variable or figure out an IF Expression, to display (1) Nothing, (2) A line, (3) [Variable Name] or (4) *** Variable Name ***.  This friendliness, has some consequences.

As recently posted on the HotDocs list, one consequence is that if a field “is answered” and stored in the answer file, but not relevant to a particular set of interview choices, that answer will still be used in the assembly.  The result will be that “irrelevant client data” will show up in the document.

The solution to this problem is to properly nest variables and conditions.  This is not as easy as it seems.  In a complex template, the web of dependencies and conditions can be difficult to track down.  Good dialog scripting and organization can help, but it can take some time to hunt down the proper conditions.  More often, you can over conditionalize a variable, and whole sections that should be relevant will not come in.  Because the “interview script” and the “template” are independent objects in the assembly system, both have to be separately validated and scripted.

The Value of “Polish”

What is “polish” and why is it so valuable to clients?  Surely if the functionality is the same, the polish is just “eye candy”, but then, perhaps not.  This article explores why polish takes so much time, yet repays itself hugely

I was once approached by a young man to provide one-on-one HotDocs training, unconnected to a particular consulting project. When I asked why he chose me over the vendor-based training of LexisNexis, he said, “BECAUSE YOU GOT POLISH”. I agreed, yes, I was Polish (my maternal grandmother was from Warsaw).

Read moreThe Value of “Polish”