The file's text, extracted by GovTribe without its formatting.
SOFTWARE FUNCTIONALITY MATRIX
Incorporated County of Los Alamos Procurement Division 101 Camino Entrada, Building 3 Los Alamos, NM 87544
Offeror Company Name:
| Solicitation No.: |
| RFP27-21 |
| Solicitation Title: |
| Clerk Recorder System |
Instructions for Offerors: The following are minimum features and functionality requested by the County. For each line item, indicate if the functionality is provided as described below in the legend and provide a description of how the Solution provides the requested feature or if an alternate solution is proposed. County reserves the right to award any Offeror whose combination of functionality or proposed alternate solutions best meets the County’s needs. Offerors should prepare to present all the features and functionalities below during their scheduled demonstrations, if selected as Finalist(s) for Step 2.
Legend:
| S = Standard functionality out-of-the-box or meets requirement fully |
| C = Requires customization to the base code/API |
| M = Modification required (i.e. standard script or other work-around) |
| N = Unable to currently provide this feature or requirement |
T = Provided by a third party. Name the third party and describe Offeror’s relationship with this third-party.
Ref.
No.
| Functionality: Please indicate with an X, using the legend above, to indicate how Offeror’s Software provides the following features and functionality. |
| S |
| M |
| T |
| C |
| N |
| Description of Solution |
| 1.1 |
| Software will have the ability to grant access to an unlimited number of users. The minimum number of full users included in the agreement must be at least twenty (20), including at least five (5) users with administrator privileges. |
| 1.2 |
| County shall be able to assign unlimited users with limited/read-only permissions, at no additional cost. |
| 1.3 |
| Offeror will provide Software enhancements, patches, and new versions free of charge in a timely manner upon release. County staff will coordinate with the offeror as needed. |
| 1.4 |
| Ability for users to create customized dashboards, screens, and layouts easily without having technical knowledge and without having to contact vendor. |
| 1.5 |
| System should have the ability to enter data manually. Data input should be easy, simple, and not time consuming. |
| 1.6 |
| Software must be able to save and track audit history by User. |
| 1.7 |
| Administrators must be able to revert files and document images to previous versions if needed. |
| 1.8 |
| Software and public access sites shall be designed to be accessible for people with disabilities and verifiably compliant with applicable standards and laws, which may include but are not limited to, sections of Section 508 of the Rehabilitation Act of 1973 or equivalent, which defines standards for electronic and information technology and web-based applications, and Web Content Accessibility Guidelines (currently WCAG 2.2), which defines how to make Web content more accessible to people with disabilities. |
| 1.9 |
| Software should allow for the creation of forms that insert record data. |
| 1.10 |
| Vendor shall supply data to the County of average percentage of uptime/downtime, as gathered from existing customers. |
| 2. |
| CORE RECORDING OPERATIONS |
| 2.1 |
| Software must provide a recording workflow that complies with State and Federal recording requirements. |
| 2.2 |
| Numbering of document/instrument numbers must be permanent with integrity maintained. Unique document identifiers other than document number or book/page must exist to differentiate between historical documents with similar/same numbers. Unique identifiers must, at the least, be accessible by admin users. |
| 2.3 |
| Software should create timestamps on each page of documents at the time they are scanned. |
| 2.4 |
| Administrators shall be able to configure, add, edit, and remove document types. |
| 2.5 |
| Administrators shall be able to create and edit the fee schedule for each recording/document type. Changing the fees for a recording in real time will be simple for the cashiering user. |
| 2.6 |
| A clear workflow for rejection of documents submitted will be included. |
| 2.7 |
| When documents are manually indexed, the verifier will be able to return the document to the indexer for corrections. |
| 2.8 |
| Recorders will be able to process multiple documents as a batch, whether before or after scanning. |
| 2.9 |
| Workflow for documents will begin even if no image is included at the time of recording. |
| 2.10 |
| System shall store all documents in a non-proprietary image format at 300dpi or higher. |
| 2.11 |
| System shall have the ability to handle large image files when color documents are required/appropriate. |
| 2.12 |
| Clerk staff shall have the ability to download/export files directly as PDF files. |
| 2.13 |
| Clerk staff shall have the ability to send PDF files directly to clients from within the system. |
| 2.14 |
| For multi-document files, Clerk staff shall have the ability to download or email all attachments at one time. |
| 2.15 |
| System shall provide email previews, including all attached documents. |
| 3.1 |
| System shall provide Model 2 eRecording compatibility |
| 3.2 |
| eRecording module must meet current Property Records Industry Association (PRIA) standards, with updates when those standards change |
| 3.3 |
| Software must integrate with third-party eRecording vendors |
| 3.4 |
| Software will allow for batch eRecording |
| 3.5 |
| Electronic rejection notices shall be provided to both the Clerk’s Office and the submitter immediately upon package rejection |
| 3.6 |
| Submitters will receive an electronic receipt when their package has been accepted by the software’s eRecording module. |
| 3.7 |
| Software will provide a portal for internal County document filing/recording that includes automatic return of the recorded document to the internal submitter. |
| 4.1 |
| Software must allow for manual optical character recognition (OCR) indexing. Automatically identified fields are preferred. |
| 4.2 |
| AI indexing should be an option with published accuracy statistics and software learning capability |
| 4.3 |
| Clerk’s Office must be able to override any automatic indexing as determined necessary |
| 4.4 |
| Indexing fields should be configurable, ideally by internal administrators. Fields must be, at a minimum, configurable by vendor |
| 4.5 |
| Software shall require Grantor, Grantee, and Legal Description indexing for each document, with “None” allowed in the case that no Legal Description applies to the document. |
| 4.6 |
| Software shall include indexing of Parcel Numbers. Parcel numbers and Legal Descriptions should correspond to the County Assessor’s records |
| 4.7 |
| The indexing of County documents will contain fields referencing agreement, ordinance, code ordinance, resolution, or other internal document identifiers recognizable by County Staff outside of the Clerk’s Office |
| 5.1 |
| Search interface shall contain instructions that are easily accessible for the use of wildcards and other search tools. |
| 5.2 |
| Administrators shall be able to configure search interface to allow for advanced searches with Boolean controls |
| 5.3 |
| County Staff must be able to search, print, and download documents without watermarks. |
| 5.4 |
| Staff must be able to save searches. |
| 5.5 |
| Search abilities must allow for complex terms using multiple fields |
| 5.6 |
| Software should recognize text within a document to allow searching for key words not entered into indexing fields. |
| 6 |
| REDACTION AND RESTRICTED RECORDS |
| 6.1 |
| Software should automatically recognize and redact PII, such as Social Security Numbers and Dates of Birth. |
| 6.2 |
| Software should allow automatic redaction of user-identified numbers, such as mortgage account numbers. Fully automatic identification is preferred. |
| 6.3 |
| Software must allow manual redaction of documents with permissions based on user roles. |
| 6.4 |
| Redaction audit logs must be accessible to both administrators and regular Clerk staff |
| 6.5 |
| Software must preserve the original archival images without redactions applied. |
| 6.6 |
| Publicly accessible documents must include redactions. |
| 6.7 |
| Software must allow for specific document types to be restricted, either by document image, type, or document category controls |
| 6.8 |
| Software should allow manual controls to show only recording date, document number and document type if the rest of document indexing is restricted. |
| 6.9 |
| Access to DD214s shall be restricted. |
| 6.10 |
| Access to Death Certificates shall be restricted. |
PUBLIC ACCESS
| 7.1 |
| Software must provide a public search portal. |
| 7.2 |
| Customer portal shall include clear instructions to the public for searching. |
| 7.3 |
| Public portal users shall be able to view watermarked documents at no charge. |
| 7.4 |
| Portal users shall be able to purchase and download unwatermarked copies of desired documents without contact with the Clerk’s Office. |
| 7.5 |
| Portal users shall be able to download multiple documents at one time. |
| 7.6 |
| Bulk document access subscription accounts shall be available to users such as abstract or title companies. |
| 7.7 |
| Bulk access subscribers shall be able to download both images and indexing information. |
| 7.8 |
| Public portal must meet all State and Federal accessibility requirements |
| 7.9 |
| Documents in the public portal will be available to view or download in color format if recorded/saved in color. |
| 7.10 |
| The public portal shall be accessible by personal computer, tablet, and smartphone. |
| 7.11 |
| Software should allow admin users to edit the public portal interface without vendor involvement. |
| 8.1 |
| The system shall support the full marriage license issuance workflow, including application intake, review, issuance, recording, and certificate generation. |
| 8.2 |
| The system shall allow Clerk staff to enter and manage marriage license applications submitted in person. |
| 8.3 |
| The system shall support secure online marriage license application intake and allow Clerk staff to review, approve, and convert submitted applications into official marriage license records. |
| 8.4 |
| The system shall restrict access to marriage license applications and supporting data to authorized Clerk staff through role-based security permissions. |
| 8.5 |
| The system shall automatically assign recording book number, page number, and document number for marriage licenses and certificates in accordance with New Mexico Clerk recording practices. The system shall allow the Clerk to begin a new book and reset page numbering when a book is full. |
| 8.6 |
| The system shall allow marriage license applicants to sign the application in person using a digital signature pad. The captured signature shall automatically populate and become part of the Clerk’s official permanent marriage license record. |
| 8.7 |
| The system shall automatically index marriage license applications and certificates and auto-populate applicant information across: |
· the Clerk’s official dual Marriage License/ Certificate record
· the decorative copy issued to the couple.
| 8.8 |
| The system shall allow fully-online marriage license applications only in accordance with New Mexico law. |
| 8.9 |
| The system shall allow Clerk staff to generate and manage certified and non-certified public copies of marriage certificates. |
| 8.10 |
| The system shall allow Clerk staff to search marriage records by: |
· applicant name
· spouse name
· date of issuance
· date of marriage
· document number
· book and page
| 8.11 |
| The system shall generate and print the decorative Marriage License and Certificate issued to the applicants. |
| 8.12 |
| The system shall allow Clerk staff to generate duplicate decorative or certified copies of marriage certificates when requested. |
| 8.13 |
| The system shall require and securely collect and store the Social Security Number (SSN) of each applicant applying for a marriage license as required by NMSA 1978 § 40-1-10(C)(1) and § 27-1-10 NMSA 1978. |
| 8.14 |
| The system shall ensure Social Security numbers are protected from public disclosure and are not visible in public records, indexes, or public search portals. |
| 8.15 |
| The system shall support the ability to securely purge Social Security number data after the statutory retention period in accordance with NMSA 1978 § 40-1-10(C) and related confidentiality requirements. |
| 8.16 |
| The system shall maintain an audit log of access to sensitive marriage license data, including SSN access and purge actions. |
| 8.17 |
| The system shall allow entry and indexing of ceremony, officiant, and witness information upon the return of completed marriage certificates. |
| 8.18 |
| The system shall allow Clerk staff to track and report on the status of marriage licenses, including: |
· issued
· returned/recorded
· unused
· expired
| 9.1 |
| The system shall allow the recording of informal probate cases processed by the County Probate Court |
| 9.2 |
| The system shall allow the scanning or multiple probate documents into one case file with the ability to mark breaks between each document. |
| 9.3 |
| The system shall automatically place a recording stamp on every document’s first page and multiple page stamps on the following pages. |
| 9.4 |
| The system shall require each document to be labeled with the document type from a limited list. |
| 9.5 |
| The system should create a Court Docket for each item uploaded without additional manual data entry. |
| 9.6 |
| The system shall allow the export of a full case file as a PDF or PDF package. |
| 10 |
| INTEGRATION WITH COUNTY FINANCIAL SYSTEM |
| 10.1 |
| System must provide integration with Tyler Munis for revenue, GL, AR/AP, and financial reporting. |
| 10.2 |
| System will allow revenue exports and reconciliation with Tyler Munis ERP or directly transfer data to a batch within the ERP. |
| 10.3 |
| System will allow check receipt reports to submit with daily deposits into the Finance system. Ideally, these should list each check as a single item rather than for each document in a transaction. |
| 10.4 |
| System will provide a means for balancing each day’s business transactions. |
| 10.5 |
| System will provide a means for tracking escrow accounts for eRecording vendors. |
| 10.6 |
| System will provide reporting for fee processing and GL account deposits. |
| 10.7 |
| Software will directly connect to a PCI-compliant credit card processing system. |
County’s preference is that Offeror’s Software have the ability to interface with First Data, the County’s current Credit Card Processing contractor. Offerors are asked to describe this available process in detail. Offerors are asked to include in their cost proposals any fees for such integration services and automated updates. If First Data is not an available option Offerors are asked to identify the Credit Card Processors who can be integrated with Offerors Software.
| 11 |
| INTEGRATION WITH COUNTY ASSESSOR SYSTEM |
| 11.1 |
| Integration with Assessor’s Property Records System (Currently Tyler Eagle Assessor) |
| 11.2 |
| Software will synchronize property records using Parcel Numbers (tied to Legal Descriptions) to avoid duplicate records |
| 11.3 |
| Vendor will train Assessor staff on the integration function and how to minimize their workload with integration. |
| 11.4 |
| Staff in the Assessor’s Office must have search/view/download directly from the software interface. |
| 12 |
| REPORTING AND ANALYTICS |
| 12.1 |
| Reporting: Software should be able to export all reports into a CSV or XLS/XLSX file, word document, or PDF. Describe any other formats offered. |
| 12.2 |
| System should provide the ability for end users to easily create saved reports and ad-hoc reports. |
| 12.3 |
| System should have the ability to allow users to create custom reports independently of vendor assistance. Vendor will provide report design support as needed with no additional cost to County. |
| 12.4 |
| System will provide workload and productivity reports by user, activity, and document type. |
| 12.5 |
| System will provide reporting for indexing errors, whether by the automated function or manual input. |
| 12.6 |
| System will create revenue reports customizable by product, date range, general ledger accounts, and other criteria as determined by the County. |
| 13 |
| DATA MIGRATION / BACKUP / DISASTER RECOVERY |
| 13.1 |
| Vendor will provide migration services for both data and images into new system (approximately 100GB and 278,000 records), whether hybrid or cloud-based (Preferred) |
| 13.2 |
| Implementation will include migration validation and reconciliation reports |
| 13.3 |
| Vendor will conduct test migration runs to ensure no data loss between software systems. |
| 14.1 |
| Vendor will provide in-depth system training for current staff upon implementation of system. |
| 14.2 |
| Vendor will provide up-to-date unlimited online training resources throughout the term of an agreement, at no additional cost to the County. |
| 14.3 |
| Vendor will provide software training for new staff as needed by the County. |
| 14.4 |
| Vendor will provide advanced system training for system administrator. |
| 14.5 |
| Vendor will provide instructional user manuals for both general and administrator level users. |
Additional or Optional Features and Technical Specifications
Describe any additional or optional features and technical specifications not already stated that may be relevant or offered to County. Use a separate document if more space is needed.
Describe whether the feature is provided as part of the standard base proposal or if it is offered optionally for free or for a fee. Include all costs for these additional or optional features in the Cost Proposal
Index approximately 131,000 historical documents with, at the minimum, date/time, grantor, grantee, and property legal description Comment by Rodgers, Derrill: Is this a current requirement or a carry over from a prior solicitation (RFP25-32)? I’m guessing that a third party vendor will be required to conduct the indexing work based on a prior solicitation for that service. I’d suggest that if included this items is stated as an optional service, and included as an optional service in the Cost Proposal Worksheet. The costs proposed to index the 142,800 documents at the time of RFP25-32 was very high. Comment by Collins, Allison: Interesting - between this version and what I have, I must have edited this. My version has this item as an optional item.
RFP No. 24-15 Issued by Procurement Division: J. Kephart image1.jpeg