Our Approach
When we are retained to design a system, there are only 2 things that drive our decisions: your return on investment ("ROI") and your ability to continue to use our system for as long as possible. We see little benefit in spending thousands of dollars on a system that will not receive enough through put to return your investment in a short period of time. And why would we develop a system that requires our intervention to update a letter or fax, or staff list? Our aim is to provide you with a system that you can maintain with minimal (if any) assistance and that will continue to produce ROI.
In our view, a well designed and programmed document assembly system should generate 100% ROI within a 3-6 month period. The exception to this rules are systems that are designed to be very simple, and are undertaken purely as a quality control mechanism. Typically, there is little profit in these systems, as a client is not seeking profit, they are seeking to have all their documents produced with a consistent look and feel.
Programming Approach
There are three major items that set us apart from most "document assembly developers" we have seen:
- We program as close to "plain english" as practicable. So programing that deals with a plaintiff's name is not named "C213E" or something similarly obscure, it is named "PLF Name TE"
- "PLF" is an alphabetical sorting prefix, which all variables dealing with a plaintiff will have
- "Name" is the descriptive part of the variable. In this example, its the plaintiff's name
- "TE" is a suffix applied to all single-line text variables
- Approximately 20% of our work is actually programming document assembly. The other 80% is consulting, planning, structuring and client care on delivery. This benefits our clients as we provide them with the blueprint with which their system was designed. Every variable, every dialog, every condition and every rule is documented plainly, grouped by usage and able to be sorted and filtered. You can see anything in your system at a glance with a few clicks at most.
- Because of our programming and planning approach, we are very rarely re-writing code. If you select the first document in a stack and start programming it, you will encounter issues later, because you are programming a system before you are aware of every result the system needs to produce. We are not prescient, so we plan ahead before we program a system. This means no extra hours expended backtracking our own work due to premature programming.
And this all means...?
This approach avoids many errors and omissions common in document assembly
programming. It also results in a much quicker and concise system, as there
is no "clutter" - every item created has a documented and annotated use,
which can quickly be found in our blueprint. If you wish to change something
minor, you can quickly look at our blueprint and see what is dependant upon
the item you wish to change. No more changing a single variable and then
spending hours of time tracking down what went wrong. No more attempting
to decipher the system you were supplied with, or figuring out exaclty what
F1928 does to your documents. For more information, check out our Document
Assembly Developer section, where we provide some guidelines and approaches
to document assembly developers.