I own part of a small (but highly automated) five-year-old title insurance agency in North Carolina. I've been the author of all its production systems and, to get us closer to a totally web-based production system, I am considering writing from scratch an all-new "Version 2." Presently, I know next-to-nothing about InfoPath (sorry Microsoft and Madison Avenue...) - and I think I should remedy this before making any Grand Plans for the upcoming re-tooling.
I'd like someone sufficiently conversant with (1) InfoPath, (2) SharePoint, and (3) an appropriate database engine to join me some evening (EDT) in a remote-access-session tour through our existing Word-and-Access based system described below. Then, assuming we establish InfoPath is the appropriate train to board, I'd like to develop a program to educate me in what I need to know to create from scratch an all-new InfoPath web-forms driven production system.
So I need in this order (1) a newbie-mentor, (2) a teacher, (3) an engineer to design and install the necessary infrastructure, and (4) a follow-on guru-mentor to help me as I create and integrate the forms into this system.
Our company routinely uses various “remote access” techniques to meet/work on-line with each of our other independent contracting consultants (all Microsoft MVP’s). We have no rigid time-of-day meeting requirements and we will bear all expenses incident to these computer/phone conference connections.
If this project interests you, please contact me here and we’ll find a way to make the final introductory connections. Richard T. Rodgers, Sr.
-=-=-PRESENT “WORKING PROTOTYPE” DESIGN-=-=-
Our business workflow model is as simple as it gets:
1. Our customers (all NC lawyers) presently use OUR MSWord “Binder Application” template to complete an Application for Title Insurance. The form itself is available via FTP, web folder and/or download (via a custom-written ActiveX routine) off our SharePoint 2003 site.
2. The customer then sends the completed Application to us as an EMAIL attachment.
3. Our "receptionist" (a licensed title insurance “Underwriter”) opens the mail and loads the customer's Application in Word.
4. After a little "manual" reviewing and elementary error-correcting (something I presume InfoPath would accomplish before the work is sent to us), our Underwriter launches a VBA macro that transfers field-by-field the relevant customer data into the first draft of the Binder that the customer is requesting. (ASIDE: Yes, this is an XML-type process – but I wrote it before XML tools were widely available.)
5. The Underwriter puts some "serious human thought" into this request and then makes whatever editorial changes to the machine-made Binder Draft that the situation requires.
6. When completed, the Underwriter runs another VBA routine that (1) creates and automatically names a new Windows folder for this job, saves both the Customer's Application (as edited) AND our completed Binder in both MSWord *.doc AND PDF format. Data about this transaction is also automatically poked into an Access database.
This, of course, isn't the end of the process.
· 60% of the time we must "amend" the original binder at least once (due largely to Lenders' requests) and then,
· after the lawyer closes the transaction, we must translate the "promise" in the Binder into a real Policy of Title Insurance. Yes, this step is also automated into something approaching a one-click operation; the Policy itself is a PDF file we EMAIL back to the customer.
I'm pretty happy with what we've developed. Our best turn-around time from the moment-of-receipt to the moment we send the completed binder back to our customer is three and one-half minutes (by comparison, our competition is pretty proud of its 24hour turnaround…).
-=-=-VERSION TWO DESIGN GOALS-=-=-
Our new system must be at least as efficient as our present one PLUS have the following additional features/capabilities:
· Error Trapping. We need to control/filter the data input our customers now supply us in MSWord documents. I am satisfied InfoPath will do a better job than our present MSWord system....
· Web-based. I’d like to remove MSWord from any part of our back-office production process. Hopefully, we will be able to respond to any customer request/project from any “terminal” on the planet with web access.
· SharePoint based. And configured so that our customers can see all their past policies as well as their current work-in-progress. Also, we want our customers to have the ability to make the majority of their own Binder-changes. Unless we get customer resistance (a possibility…), we’d like to distribute our work-product to them via the SharePoint site rather than by EMAIL attachments.· Transaction logging. So we’ll know who did what to each file – and when.
· Search capabilities. Presently we use Windows Desktop Search to answer customer queries re whether we’ve ever insured title to a “boat slip” – or similar random retrieval/omniscience exercise. This capability should be integrated into the web-service.