So what document assembly approach is best for ME? It all depends - on your needs, your documents, your staff, your pleading styles - document assembly is all about you and your firm. As well ask "What is the best car on the market?" - 10 different dealers will give 10 different answers for each of the 10 people that asked them. From simple precedent libraries to complex document producing systems, it all depends on what you firm needs and how willing you are to invest. Before making this sort of decision, do the research! In respect of HotDocs (or any other document assembly product), I suggest the following:

• What features do you need? All the bells and whistles mean nothing if you wont use them. Do you need to be able to write from your document assembly platform to a database? Do you require the ability to access and assemble documents online? Do you need to integrate with a specific accounting/case management product? Decide on what you need, before you ask a vendor to provide a sales pitch!
• When drafting your requirements make it a dream-list.  A lot of the 'outrageous' things you might ask for are actually simple, common place or even stock standard.
• Speak to colleagues in other law firms and companies - ask about their experiences, the time spent and the end result.  Ask them whether they dedicated a staff member (or several) to the project and what the feedback was from the people who use the system - your office staff.
  
• Research discussion topics and white papers on the internet.  Particularly, look for "active communities" - places where larger numbers are people are involved in discussion and problem solving.  An active community means an active product and solid support.
  
• Subscribe to any list-serves supported by manufacturers - HotDocs has a free email list that you can unsubscribe from easily - hundreds of independent consultants who answer questions and contribute to the community freely.  Recently they have launched forums as well.
  
• Ask developer opinions - people who have worked with the products and similar products. A software manufacturer will attempt to "sell" you their product, highlighting strengths and glossing over the weaknesses. A consultant or developer is far more likely to provide a less biased opinion based upon your needs - because they will be picking up the pieces if your purchase is bad and its their name on the line if your result is poor.
  
• Show your vendor/consultant a document or two and ask them - could you program a system to produce this document in final form without post-assembly editing? (if that's what you plan to do of course...) - make sure you specify how parties and pieces of information inter-related (see this Transfer? We need multiple properties, with different purchasers and vendors for each property - not all vendors may appear on all properties)
  
• And the most important test: where's the money? Are you looking to make a loss leader profitable? Production line property matters for your five banking & finance clients? Produce a few wills & estates documents each month? Produce a lot of them? Look to where investment would make sense. This isn't rocket science, its pure and simple investment like any other software product or specialist lawyer - are you going to make money or stop losing money as a result of your investment? Is it worth thousands to be "keeping up with the Joneses"?

If your research shows that document assembly is going to be (one way or the other) profitable for your firm, undertake the following steps before buying a thing:

• Identify your goals Are you seeking simple templates to produce basic documents, or something more complex to significantly reduce drafting times? Quality control? Introduce a flat rate billing structure? Reduce staff overhead? What you wish to achieve with document assembly will determine the product to select, how much time and money to invest, time frames, and other such project related decision.
• Research. Don't conduct "research" with a single entity or "vendors only", as you may receive biased or limited views; a sales pitch is not "research", its a sales pitch; remember that.
  
• If you wish to rollout a pilot project, select an area of law that will yield profits sooner rather than later. Typically, this would be an area of practice with large amounts or repetitive content (i.e.: certain parties' details are repeated over and over on many documents), such as conveyancing, or perhaps an area of law that requires a large amount of data up front, but relatively small amounts of data for successive documents, such as leasing or mortgage work
• To really educate someone in-house - Get a consultant to do a smaller library for you.  The biggest hurdle for new developers is having no idea just how far you can take these products.  So get a living, breathing example and review what they did.  You'll spend more cash up front, but your newly trained staff member will now have an example with approaches, ideas, tricks and design, all produced by someone with years of experience.  There's no point having the biggest toolkit in the world if your people only 'get' 20% of the tools available.
  
• Purchase enough licences to meet your pilot project user base. If you are absolutely certain that document assembly will (eventually) be a firm-wide rollout, purchase to suit your entire firm's requirements, bearing in mind that most vendors offer volume pricing. Among commercial entities, it is common to over purchase by approximately 5-10% of your "seat count", to obtain the best possible volume pricing to ensure new users in the entity are adequately licensed
• Create a "projects overview" - a time line or "hitlist" of areas of law that you wish to automate. Essentially, you will wish to realise maximum profits at the earliest opportunity, so that the each successive document assembly project assists in funding the next one.  When you're finished - whatever time frames you had, double them.
  
• Decide whether you have sufficient resources internally to achieve your goals. When considering this, be aware that interrupted document assembly time is much like interrupted drafting time - once a train of thought is interrupted, it takes time to recover it and momentum is lost. If you wish to develop systems internally, devote dedicated resources and personnel to the task! A secretary or receptionist doing document assembly part time will likely return a profit equal to the resources you dedicated: none.
• Put someone in charge of each project! The managing partner or CEO's secretary is usually not a good option - have a developer liaise with someone who can answer all the technical and content questions, and make sure its a priority on their agenda. If you want to build profitable templates & systems, you will need them to reflect the intellect and expertise of your best professional staff!  Paralegals generally make a great intermediary for managing projects - they know a lot about the day to day options and variations of most of your templates, and they know the documents that are complex and needs solicitor review.  Paralegals provide answers fast and know when to ask questions from the "next level up".

Functional Questions - Document Assembly Specific Questions

These are the questions you should ask of vendors when they are selling you their product.  Some of these questions may not be necessary or relevant to your firm, others may be absolutely critical.  To evaluate anything, you need a criteria.  This is a draft criteria - feel free to add or subtract from it, but make sure you have one.  And if you don't know what features you should ask about, that's fine - read on.

Generic Features

These are the general features - how it operates, what it manages and how it manages your documents.

• Does it support online document assembly?  If so, is there a royalty fee?
• (If online) Can I provide 'portals' for clients to access specfic (limited) document lists and fill them out and have the documents sent to us?
• Does it support local networking - can all users in my office access a single precedent base?
• Does it incorporate any document management, workflow or case management features? (Beware: "suites" of products have their focus and inevitably perform at least one of their features ina less-than-competitive manner).
• How does it store answers that I enter? Are those answers retained so that I only have to enter data once per matter?  What format are answers stored in?
  
• Is the data storage mechanism proprietary/locked or is it open and readable by other applications?
• Is the answer storage centralised? Can all users see all answers and manage them? What permissions can I impose on the answers?
  
• How do users access the precedents I create? Is there a screen where all precedents are listed? Can I have multiple 'libraries' or 'banks' of precedents, each with their own screen? Can I have folders and groupings of templates within a library or precedent bank?
• Does it include version tracking and/or histories of templates?
• Does it have a feature that will "auto detect" fields in a document and present a user with all the questions, without me having to specify anything?
• Can multiple templates utilise a single code base or does every template have its own separate code?
• Can I insert one template into another template?  Can I have one template 'queue' or 'call' another template so that they assemble in sequence?
  
• Does it feature a development environment where I can search, sort, filter and report variables and the component pieces?
• Does it feature any add on tools to simplify development? Examples are toolbars to automatically perform routine tasks, reports, variable/coding duplicators and the like.
• Can we self support? If yes, how much training is involved to get us to the point where we can start working on our own systems?
  
• Are there independent consultants who work with your product that can assist with support?
• What is the annual maintenance fee, if any?
• How often does your product update?
• Will we require assistance to install and configure the product?

Design Features

How much control do you have over the "design" of the end product?  These will relate to how "user friendly" you can make your systems.

• Does it allow me to draft interviews and specify the order of questions and screens presented?
• Can I write logic to hide/show or gray and ungray fields, depending upon a user's prior answers?
• If yes, does it do it dynamically instead of having to 'move to the next screen'?
• For visual elements and screens - does it have a drag and drop interface?
• Does it automatically handle navigation, finalisation and word processing automatically?
• Can I place text on screens that isn't a question?
• Can I embed HTML or other help text/resources and attach it to variables and dialogs?
• Can I create buttons for screens that will launch other dialogs, calculate amounts, launch programs and other such things?
• Am I able to create "input formats" that force an answer to a specific format when entered (phone numbers, dollar amounts with 2 decimal places etc)?
• Can I create "output formats" - a name may appear with "Each Word Capitalised" in one place, but the same name may appear "ALL IN CAPS" elsewhere - can I do that without re-entering information?  (This applies very commonly to names, dates and numbers).
• If output formats are available, can I have as many formats for a given variable as I want?
• Can lists have different text in different places (you may have a list of states, but sometimes it should show as "QLD" and other times "Queensland" and other times "in the State of Queensland")

Programming Features

These are the features that will dictate just how far you can program any given template.

• What variables types are supported? The usual ones are: Text, Number, Date/Time, Boolean (yes/no), lists (multiple choice), multiple selection lists, computations/calculations, constants (pre-set values that are always the same, such as your firm's name) and functions.
• Can I "set" or specify the values of variables? If so, can I do it dynamically, based on other answers that a user provides?
• Can I change the "type" of data? For example - you may want to convert a text entry to a number value.
• Does it support logic - IF I said "yes" to this question, put paragraph A in, otherwise, put paragraph B in.
• Does it support logic sequences - similar to yes/no - IF this, ELSE if that, ELSE if something else and if none of those fit, put in something else again.
• Does it support compound logic - IF we have received money AND we require further information.
• Does it support nested logic - questions within questions within questions. 
  
• Does it support loops/arrays/repeats - think of this as "tables" or "rows" of information - the ability to set up a series of questions (say, payment date and payment amount), then collect as many items as you need for those questions - you might have 1 payment or you may have 20 payments.  This is a critical one in terms of maintenance, flexibility and accuracy of content.
  
• Does it support mathematics? Can I perform mathematical operations on numbers and automatically calculate things?
• Can I do date comparisons? ie: Is this date more recent than another date. Or perhaps "what is the difference, in days, between these dates?"
• Can I define my own functions?

Integration Features

These are the features that relate to dealing with other products.  Typically, document assembly is a "receiver" - it takes data from another product to remove duplicate data entry in two places.

• Does it integrate with my word processor? Or do I have to work with a custom environment particular to the product?
• Can it connect to other databases?
• Can it write back to other databases?
• Can it integrate with data sources on the internet - mysql, sql, soap and other published resources?
• What programs is it designed to integrate with?
• For each of the "other programs" it integrates with:
  • Is it done by database connection, or does the other product simply "write a data file" for it?
  • Can I launch templates from within the other program?
  • Can I access all data from the other program, or are there limitations on what data is available?
  • If the other program features "customised fields", can I access those as well?
  • What language will I need to know to connect to the other program?