22
April

Beyond Databse Merge Fields

by Matthew Pitts

So what are we really talking about when we mention automated document generation in elawyering or virtual law office applications? The answer is not a simple one. Based on the various blog posts that I have read on the subject, and the public information of companies who provide this service, I conclude that it does not have a central definition.

My Take

I admit that I have been less than enthusiastic about the prospects of automated legal document generation in the past. I have worked in a number of positions where I have developed various forms of document automation processes. Unfortunately, all of these processes involved some type of database field merging. Database field merging in its basic state is rigid and unintelligent. Basically you set up a document template, designate existing merge fields (which exist in a database table or view) and initiate the merge process. Using a mail merge based approach to legal document generation almost always involves "cleaning up" or refining the document in some way. To make matters worse, most giant law office database applications have these archaic and  weird predefined merge fields used to extract information from the database. More often than not, i opted to create smaller more efficient databases with user-friendly merge fields.

The Future of Automated Legal Documents

This blog is all about shaping the future of the online delivery of legal services, and document automation is included in that vision. Although I do believe that there are some worthy alternatives to mail merge document generation out there, I have not yet seen any truly robust systems. Of course I don't know how every company's technology works, but I really don't need to.

For instance, Wizilegal is a company that claims to be the most cutting-edge provider of SaaS automated legal document software. They have very little information available pertaining to the inner-workings of the software. I don't even know the output of the generated documents. What I do know is they require the attorney to upload their documents. Next, the software will generate documents? Yes, it is confusing. I guess there is no wonder that their most recent blog post was in September 2009.

The future of automated legal document assembly has about as much to do with traditional mail merge as this blog has to do with typewriter maintenance. :-)

The Role of the .PDF

I really like .pdf documents. However, I think they have been miscategorized in their intended role for automated legal document solutions. A .pdf is great for what it is, a portable document format. Because of its long tenure in the world wide web, it has become the standard for shuffling documents through cyberspace. The King County Superior Court in Seattle now requires attorneys to electronically file documents in .pdf format. I think this is great. The problem is that .pdf files are not particularly suited for pure automated document generation. I'm sure it works for some people, but it is not ideal.

Conclusion

The future of automated legal document generation is all about file format. What type of file format can be best used to completely generate legal documents on the fly? The idea of mail merge definitely has a place in automated legal document generation, but only the idea. The future I envision detaches us from our desktop programs and thrusts us into the cloud where virtually anything is possible. I'm excited about the possibilities!

23
March

ABIEE™ - Client Registration Use Case - Entry 4

by Matthew Pitts

What follows is the client registration use case for the ABIEE™ (Alliance of Bankruptcy Information and Expert Exchange). If you were following the previous related post, you will see that the client registration use case specifically builds upon the global client use case. Before the client can access any major features of the application, he/she must register an account. Although it is possible to allow anonymous browsing and functionality, up front registration makes the most sense.

The Registration Process Overview

Basically, a client will complete a brief and painless registration form. When they click submit, pertinent data will be entered into a database table. Next, the client and the site administrator will receive notification of the event.

Developer's Perspective

The programming portion of the registration use case is fairly straight forward. Once the client enters information on the form and clicks submit, logic will be written to add that information to a database table. Additional code will be written to confirm the registration with the client. Finally, code will be written to notify the site administrator that a new user has in fact registered an account.

Designer's Perspective

The eventual graphic design of this input form will reflect the overall look and feel of the application (the graphic design will come much later in the process). The focus should be on modern design techniques with an emphasis on usability.

Marketing Perspective

At this point, it is important to realize that the client has an open mind and may be interested in additional services/offers. One thing that I will add here is an opportunity to opt-in to marketing  communications such as newsletters and special offers. One more marketing feature that I will add here is an opt-in for a printed information packet of some kind.

Conclusion

Once the client is registered we will have non personally-identifying identity parameters to use for future programming, design, and marketing implementations.

Client_Reg_UseCase.pdf (143.40 kb)

 

 

14
March

ABIEE™ - SRS for the Client/Consumer - Entry 2

by Matthew Pitts

This is part 2 of series on building the elawyering application ABIEE™. You can find all related entries by selecting "ABIEE" in the category list.

Portion 1: The Software Requirement Specification for client/consumer users of ABIEE™

In entry 1, I roughly outlined most of the features that I envisioned ABIEE™ containing. I also mentioned the size and complexity of the task at hand. Finally, I noted the fact that I would break the development and design process down into manageable chunks. I decided to start the development/design process by outlining the Software Requirement Specifications (SRS) for the client/consumer portion of ABIEE™. You can see a preliminary list of the features for the client in entry 1. The following list is more refined and should be considered the official SRS for the client/consumer portion of ABIEE™. of course this list is also subject to change as the elawyering application development/design process progresses.

Official Software Requirement Specification for the Clients/Consumer Portion of ABIEE™

Pre-Filing Stage

 

  1. Unregistered clients can browse library of resources (RL  SRS Pending)
  2. Clients must register and login for additional features
  3. Clients can organize case related documents that the BKP will need for document generation (BKP SRS Pending). Case related documents include scanned (.pdf or .xps) versions of documents such as bills, tax returns, etc.
  4. clients can view the documents they have uploaded
  5. Clients can send documents to BKP when necessary (BKP SRS Pending)
  6. Clients can build a personal library of resources and use standard methods to manage their library such as add, delete, and sort (RL SRS Pending)
  7. Clients can follow a process checklist which will guide them through the appropriate processes to completion of BK case (intermittently updated as development progresses)
  8. Clients can browse information about BKP such as BKP supplied BIO, experience, etc. on public BKP list)(BKP SRS Pending)
  9. Clients can inquiry/message BKP they are interested in hiring (BKP SRS Pending)
  10. Clients can hire a BKP and complete retainer agreement/service agreement (BKP SRS Pending)
  11. Clients can submit payment to BKP (BKP SRS Pending)
  12. Clients must submit case review/means test to hired BKP (BKP SRS Pending)
  13. Clients can receive case review/means test result from BKP ((BKP SRS Pending)
  14. Clients can receive completed document copies from BKP(BKP SRS Pending)
  15. Clients can inquiry/message BKP they have hired (BKP SRS Pending)
  16. Clients can create reviews for BKPs they have hired (BKP SRS Pending)
  17. Clients can complete questionnaires for later use in document generation.

 

Post-Filing Stage

 

  1. Clients can have case-level calendars updated by BKP (BKP SRS Pending)
  2. Clients can receive standard built-in information about upcoming hearings

 

Note: BKP = Bankruptcy Professional -- RL = Resource Library

 

12
March

Building ABIEE™ - ELawyering Application - Entry 1

by Matthew Pitts

In my previous post, I mentioned the new direction in which I would be taking this blog. Instead of going on about the individual components of modern elawyering applications, I have decided to embark upon a major project in which I will build an elawyering application from scratch. I'll be documenting this from start to finish, all the way through to deployment on the web. Hopefully, you will stick around and provide input and ask questions along the way. If you have not done so already, please subscribe to my rss feeds so that you know when a new entry is posted.

What is ABIEE™?

ABIEE™ is an acronym for "Alliance of Bankruptcy Information and Expert Exchange". As you can see, ABIEE™ will be an elawyering application focused on bankruptcy practice. In this first entry, I will discuss what my vision for ABIEE™ is and what ABIEE™ will be able to do. 

The Intended Audience

The intended audience for this series of entries can be made up of four distinct disciplines. It may be that you act as two or more of these disciplines. Specifically, I will focus on lawyers/bankruptcy petition preparers; application/web designers; application/web developers; and SEO technicians/web marketers. These ent ries are meant to be a reference for lawyers to use when discussing their own elawyering application with these additional parties.

My Vision for ABIEE™

When I thought of the idea for ABIEE™, I wanted a place for consumers and bankruptcy professionals to meet and connect. The "A" in the name ABIEE™ stands for "Alliance". Additionally, the "E' at the end stands for "Exchange". Both of these terms symbolize connecting at a central location. The "I" stands for "Information". It is my goal that participating bankruptcy professionals will contribute in some way to the building and maintenance of a robust bankruptcy information repository. All these elements combine to make a central location for consumers to connect with and facilitate the exchange of information with bankruptcy experts who can ultimately help them with their cases.

From the bankruptcy professionals standpoint, ABIEE™ will be a place to acquire new clients as well as manage just about every aspect of the bankruptcy case for that client. In a way, ABIEE™ will have a built in case management system which will intelligently integrate with each acquired client. I know this is a lot for one application to achieve, which is why I will break the portions down into manageable chunks. 

Next, let's take a look at a preliminary list of what ABIEE™ will do for each type of user (the bankruptcy professional and the consumer/client).

What will ABIEE™ do for the client/consumer?

The following is a preliminary list of features that will be available for clients/consumers. This list is subject to change over the course of development.

  1. Obtain relevant bankruptcy information from a vast repository of experts
  2. Organize all documents related to bankruptcy in an organizational system that allows the client to maintain everything in one place before they actually file (This will be the focus of the service from the client side).
  3. Maintain a checklist
  4. Create a library of resources
  5. Ability to search and view information, bio, etc of bankruptcy professional publicly listed in the ABIEE™ directory. 
  6. Ability to message prospective bankruptcy professionals through ABIEE's™ messaging system.
  7. Ability to select a bankruptcy professional to complete their documents.
  8. Ability to submit a case review/means test to selected bankruptcy professional
  9. Ability to receive analysis and results of means test from bankruptcy professional
  10. Ability to convert from chapter 7 to 13 on bankruptcy professional's prompting.
  11. Ability to submit payment to bankruptcy professional.
  12. Ability to retrieve completed documents from selected bankruptcy professional.
  13. Ability to maintain a calendar of important case events.
The following is a preliminary list of features that will be available for lawyers/bankruptcy professionals. This list is subject to change over the course of development.

Pre-filing:

  1. Automated means testing result notification and retrieval
  2. Option to start case at chapter 7 or 13
  3. Method to identify red-flags
  4. Method to communicate case review to clients
  5. Method to request more information from client
  6. Method to decline a case
  7. Method tr secure retainer/service/fee agreement/disclosures
  8. Method to set custom amount of payment and ability to collect either on or offline.
  9. Method to retrieve client's core information
  10. Method to automatically generate documents for filing.
  11. Method to retrieve uploaded documents
  12. Method to be notified when a client selects them for service
Post-filing:

  1. Method to export information for back-end use
  2. Method to list all clients
  3. Method to close/inactivate matters
  4. Method to convert matters to chapter 13 and notify client
  5. Method to receive additional chapter 13 information from client
  6. Method to track deadlines
  7. Method to receive reminders for a particular case
  8. Method to message clients
  9. Method to automatically generate more specialized documents, such as motions for a particular client
  10. Method to calendar arbitrary events for a particular client
  11. Method to calendar critical events
  12. Method to tickle events
  13. Secure transactions
  14. Method to request additional information from client when necessary
  15. Activity log generation and exporting (searchable by date)
  16. Built in timer
  17. Memo/note creation and association methods directly appendable to activity log

Published in De Novo

Be sure to read my article in the December 2009 edition of the Washington Young Lawyer's Division publication De Novo. You can read it here.

Sponsors

Thanks for Reading

Matthew A.Pitts

About Matthew A. Pitts

 I am a freelance paralegal in Washington State. I have experience in multiple areas of law in both the private and the public sector. Legal Web Development and Marketing

For the past 7 years I have focused on legal marketing and legal web design and development. I have professional level web programming and design skills.

About this Blog

 The legal service delivery landscape is changing rapidly. Despite the number of options available for legal professionals to establish a web presence and begin to engage in some type of "e-lawyering", there are core fundamentals required for success. In this blog I intend to thoroughly cover these fundamentals. Please subscribe today.

Blog Information

Published by Matthew A. Pitts.
Design by Matthew A. Pitts for Internet Paralegal Innovations™.
Powered by BlogEngine.NET   Icons by Dry Icons
© 2010 All Rights Reserved.