Countdown to NAPE - Part 2
Countdown to NAPE Summit
Do You Manage your Title the Old Fashioned Way?
Delivering More for Less - Increased Efficiency = Increased Competitiveness
Note: This series is geared toward land brokerages. It is designed to help them realize how they can differentiate themselves and therefore be more competitive by utilizing technology solutions already available to them. Obviously, if you are engaged in the hiring of brokerages, this information will be helpful to you as well. A more efficient brokerage can deliver more for less, and everybody wins.
Part 1 of 5 – Broker and Client Billing
Part 2 of 5 – Title Management
Part 3 of 5 - Field Acquisition
Part 4 of 5 – Asset Tracking
Part 5 of 5 –The Status Quo is too Expensive
Title Management
All brokerages need an efficient broker and client billing system, as discussed in Part 1 of this series. Just as central, though, is title management. Almost nothing happens without legal documents (recorded or otherwise) being the primary determinant. Documents are first obtained in any number of ways, such as researching online or at the courthouse, or in a package already compiled and presented for review. Regardless, the legal document, or instrument, is an asset from the moment it is brought into the realm of the handling brokerage.
As with any asset, it generally bears at least some cost associated with its acquisition, and should be treated accordingly. For those who have ever had to copy or scan a document, there is no need to explain how time consuming that can be. Doing so once or twice every now and then might not seem to present an issue, but when multiplied across the entire staff and over the years of potentially needing to handle that instrument, the inefficiencies, and therefore the costs, begin to add up. For an intangible, though, consider how nice it is to be able to pull up and email a digitized version of an instrument (or any document for that matter) to a client in moments rather than hours or days.
So a system of storing and indexing instruments is absolutely vital. The last thing that should happen is that the instrument be stuck in a file (whether paper or digital) where it cannot be easily retrieved via indexing. Let’s look at the possibilities.
Paper only is once again not only a possibility, but the default system for too many brokerages. They simply create paper files during the course of a project, many or most of which contain one or more instruments, then take the working files or the lease packets and store printed copies in a filing cabinet or box. Simple? Yes. Efficient? No, especially when it comes time to retrieve that document for whatever reason. Consider the instance where the client asks for a copy of a particular instrument. The odds of delivering it in a speedy manner, particularly if the project has been closed for any length of time, are low. Time wasted is money wasted, and the client will not be impressed.
A system of scanning and saving instruments can address many of the shortcomings of a paper only system, but can be time consuming and prone to errors, and therefore costly. Scanned instruments are very common nowadays. Certainly instruments purchased online are already in digital form. Many brokerages scan the rest and store them in a way that is (hopefully) easy to locate, simply by using the file system on a computer or file server. First, a system needs to be established that will be honored going forward. Typically, it would start with a folder for a client, then subfolders for projects, then subfolders for executed documents, instruments, plats, etc. The key to retrieval then depends on the naming convention used when saving the files, i.e. “123-456-7890123 Mary Jones Cash Deed”.
This system can and does work, but it has a number of shortcomings. First, it is very vulnerable to the GIGO principle (garbage in, garbage out). If a file is misnamed or put in the incorrect folder, retrieval will be far more difficult.
A variation is to save all image files with a sequential counter number, maybe 15-0123456, then keep a spreadsheet which serves as an index. In other words, each file is indexed in the spreadsheet, with key info in columns, such as grantor, grantee, book, page, entry number, date, STR or other location data, client, project, etc. The pros of this type of system are that you can sort by different columns to find important things like all the instruments with Mary Smith as grantor, etc. The cons are that it is still vulnerable to GIGO, and again very time consuming. A drawback to the entire solution is that digital data needs to be reliably backed up, both locally (within the physical location) and remotely (at a separate location far enough away to not be vulnerable to a common event). Backup systems are not difficult to implement any more, but good ones—good enough to bet your business on—come with a cost, both in the form of licenses and personnel.
Finally, the biggest drawback by far, particularly when contrasted with the solution addressed next, is that it falls short if asked to provide conclusive and reliable information with regard to the relationships between instruments and other data. This will be further developed in the next section.
A database-driven, web-based system provides the most effective and efficient means to manage title, not only for the reasons outlined in Part 1 of this series, but also for the benefits specific to title management.
When an image file is uploaded into a web-based system, it is instantly available to those users to whom that authority has been given. The image can then be associated (or related) to other data. The first would likely be a project, then a tract, then anything else applicable to the task at hand.
At the time of the upload, the user should be prompted to search first to ensure that the instrument image has not already been uploaded. This is done to save time, of course, but primarily to maintain data integrity (this point will be developed further later within this article). So from the outset, multiple handling of any instrument passing through the brokerage is eliminated. It becomes part of an accumulating body of instruments that can be searched by the aforementioned fields (grantor, grantee, type of document, etc.).
As a normal course of business, however, the instrument would then be associated with a tract as part of creating an ownership report. That tract then would be associated with parties with ownership information included. By doing so, the user does not have to retype the key information about the instruments to create a chain of title, list of source deeds, etc.—rather simply point to the instrument. A good system should be able to pull the images of the instruments right into the ownership report. Very handy and efficient. No more handling of paper, making copies, or keying in the same information over and over. This process also by default establishes a relationship between the instrument and anything subsequently associated with the tract, such as leases, parties, units, etc., allowing a user search for all instruments associated with a unit, for instance.
And the benefit is multiplied in those many instances where an instrument applies to more than one tract. An instrument that may apply to dozens or even hundreds of tracts would only have to be handled once.
Back to the data integrity issue, let’s say an image is uploaded as an instrument and over the course of a project (or multiple projects) users create ownership reports with the referenced instrument in the chain. While the user saves time by simply linking to the existing instrument record and image, an index is passively being created to show all other data associated with the instrument. Referring back to the data integrity issue, if the same instrument is uploaded multiple times, that benefit is potentially lost if some users point to one instrument and others point to another.
So a major benefit of a well-designed web-based system is the need to only have to handle an instrument once (in the history of the brokerage) and of course the benefit inherent to web-based systems such as wide area networking. But what about an even more practical, short-term benefit? Well, consider how many times the same instrument might be handled in the course of obtaining a single lease? First, the ownership report, then a run sheet, then the purchase report, the lease packet and possibly in an abstract. Some of these may involve images and recordation data, others only recordation data, but either way, not having to copy or retype saves time and therefore money. By the time the process is done, a system like the one described here has already paid for itself with the processing of just one lease.
One more advantage of a web-based system is that email can often be bypassed altogether as the client can be given access to go grab the instrument or any other info himself/herself.
Finally, web-based systems as a rule do not require software to be installed on the user's computer, and provide hardware redundancy (for maximum uptime) and data redundancy (multiple backups spread across multiple locations). Referring back to the build or buy question, this is simply too costly for almost all individual brokerages to do economically.
We at TotaLand have seen dramatic improvements in the lives of our clients, reducing title management costs through increased efficiency, and allowing them to focus on what the client is paying them to do. How much is that worth to any organization, particularly one trying to remain competitive in a difficult environment? If your organization is not utilizing such technology, come visit us at booth 2552 next week at NAPE Summit, or give us a call at 800-465-5877.
Most importantly, now is the time to implement a quality, web-based billing system. When things get busy again (and they will), the golden opportunity to become more efficient will have passed.
As we approach NAPE next week, we will be posting more articles about how brokerages can become more efficient, and therefore more competitive. See you at NAPE!
Bill Justice – Founder / President, TotaLand Technologies