Exhibit_2,_Functionality_Matrix.xlsx
XLSX spreadsheet 58 KB Posted
- Attached to
- Marinas & Campground Management Software Solution State and local contract opportunity
- Solicitation number
- RFP0000007
- Issued by
- Miami-Dade County, Florida
About this file
Summary of Exhibit 2, Functionality Matrix
This Functionality Matrix document outlines the technical and operational requirements for the Marinas and Campground Management Software Solution for Florida's six marinas and campground facilities. The document establishes a comprehensive framework of functional capabilities that the proposed software solution must deliver, including features for wait list management, approval workflows, slip allocation and management, reservation processing, billing operations, reporting analytics, and task management functionalities. The matrix serves as the evaluation tool against which all vendor proposals will be assessed, ensuring that submitted solutions align with the state's requirements for modernizing operations through cloud-based management functions and improving overall operational efficiency and organizational standards across all six facilities.
The Functionality Matrix details specific system capabilities and performance standards that vendors must meet or exceed in their proposed solutions. This document functions as the primary technical specification reference for evaluating vendor compliance and system functionality. The matrix enables consistent comparison of vendor offerings against baseline requirements and facilitates objective scoring of proposals during the evaluation phase, ensuring that the selected software solution will adequately address the operational challenges identified in the RFP, including wait time reduction, workflow efficiency improvements, and enhanced analytical capabilities for marina and campground management operations.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| Exhibit_3,_Profile_Groups.pdf | ||
| 06162026_PR_EVN0055594_1_1_0_06192026_Solicitation_Packet.pdf | ||
| Form_1_-_Price_Proposal_Schedule.docx | DOCX document | |
| RFP_Proposer_Info.pdf | ||
| RFP0000007_RFP_Solicitation.pdf | ||
| Draft_Form_of_Agreement.pdf | ||
| Exhibit_1,_Information_Technology_Security_Matrix.pdf |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
ScopReq
| Source Section | Requirement Description | Requirement Type | Priority | Business Process Area | Notes |
| 2.2 | System must associate all applications with a unique user profile | Functional | High | Waitlist Management | Ensures accurate tracking |
| 2.2 | System must support unlimited applications per applicant | Functional | High | Waitlist Management | No system restrictions |
| 2.2 | System must enforce a maximum of two active contracts per individual across all marinas | Functional | High | Contract Management | Cross-marina validation |
| 2.2 | System must distinguish between commercial and recreational contracts | Functional | High | Contract Management | Separate workflows |
| 2.2 | System must prevent applicants from being bypassed on waitlists without authorized override | Functional | High | Waitlist Integrity | Audit trail required |
| 2.2 | Contracts must correspond to vessel size category waitlisted | Functional | High | Contract Management | Vessel validation |
| 2.2 | System must prevent assignment of slip outside waitlist category unless override applied | Functional | High | Slip Management | Requires authorization |
| 2.2 | System must support migration of existing waitlist of over 5,000 patrons | Functional | High | Data Migration | Legacy system conversion |
| 2.3 | System must provide a public portal for waitlist application submissions | Functional | High | Customer Portal | Online service |
| 2.3 | Users must be able to view waitlist status and placement | Functional | High | Customer Portal | Transparency |
| 2.3 | Users must be able to reserve transient slips online | Functional | High | Reservations | Public portal |
| 2.3 | System must allow advance reservation payments | Functional | High | Payments | Integrated gateway |
| 2.3 | System must allow users to register for memberships | Functional | Medium | Membership Management | Customer services |
| 2.3 | System must support purchase of event tickets and concessions | Functional | Medium | Sales | Integrated POS |
| 2.3 | Users must be able to manage accounts securely with stored payment methods | Functional | High | Customer Accounts | PCI compliance |
| 2.3 | System must accept cash, credit card, ACH and gift card payments | Functional | High | Payments | County payment gateway |
| 2.4 | System must support at least 50 internal users with 20 concurrent users | Functional | High | System Access | Licensing |
| 2.4 | System must allow unlimited external/public users | Functional | High | Portal Access | Public services |
| 2.4 | System must include all third-party licensing costs within the solution | Functional | Medium | Licensing | Embedded solutions preferred |
| 2.4 | System must provide redundant main and backup hosting sites within the United States | Non-Functional | High | Infrastructure | Continuous synchronization |
| 2.5.1 | System must allow online waiting list applications | Functional | High | Waitlist Management | Public portal |
| 2.5.1 | System must determine eligibility of waitlist applications | Functional | High | Waitlist Management | Eligibility rules |
| 2.5.1 | System must process waitlist application fees | Functional | High | Payments | Automated |
| 2.5.1 | System must notify patrons of ineligibility and process refunds | Functional | Medium | Customer Service | Refund workflow |
| 2.5.1 | System must add patron information to marina waiting lists | Functional | High | Waitlist Management | Multi-marina support |
| 2.5.1 | System must allow patrons to track waitlist position online | Functional | High | Customer Portal | Self-service |
| 2.5.1 | System must record declined slip offers | Functional | Medium | Waitlist Management | Audit history |
| 2.5.1 | System must notify patrons of slip availability | Functional | High | Communications | Automated notification |
| 2.5.1 | System must process berth permits | Functional | High | Contract Management | Integrated workflow |
| 2.5.2 | System must verify vessel information for berth permit approval | Functional | High | Permit Workflow | Validation |
| 2.5.2 | System must calculate monthly berth fees | Functional | High | Billing | Automated |
| 2.5.2 | System must support digital signing of berth permits | Functional | High | Contract Management | Integration with e-signature |
| 2.5.2 | System must collect security deposit fees | Functional | High | Billing | Financial workflow |
| 2.5.2 | System must support permit approval workflow paths | Functional | High | Workflow | Configurable |
| 2.5.2 | System must process monthly billing for permits | Functional | High | Billing | Automated recurring |
| 2.5.2 | System must remove patrons from waitlist upon permit issuance | Functional | High | Waitlist Management | Automated |
| 2.5.2 | System must provide permit status tracking | Functional | Medium | Permit Management | Customer visibility |
| 2.5.2 | System must notify patrons of expired required documentation | Functional | High | Compliance | Automated alerts |
| 2.5.2 | System must update berth permit rate changes | Functional | Medium | Billing | Administrative update |
| 2.5.3 | System must provide interactive marina maps for vessel placement | Functional | High | Slip Management | Visualization |
| 2.5.3 | System must support wet slips, dry storage, mooring buoys, and temporary docks | Functional | High | Slip Management | Multiple categories |
| 2.5.3 | System must optimize boat placement based on configurable parameters | Functional | Medium | Operations | Dock optimization |
| 2.5.3 | System must provide slip usage indicators | Functional | High | Operations | Availability |
| 2.5.3 | System must support work order task management | Functional | Medium | Maintenance | Internal tasks |
| 2.5.4 | System must process transient slip requests | Functional | High | Reservations | Customer services |
| 2.5.4 | System must determine discount or promotional rates | Functional | Medium | Pricing | Promotions |
| 2.5.4 | System must calculate transient dockage fees | Functional | High | Billing | Automated |
| 2.5.4 | System must support recurring 30-day billing cycles | Functional | High | Billing | Automated |
| 2.5.4 | System must prorate charges to end of month | Functional | Medium | Billing | Financial accuracy |
| 2.5.4 | System must support refunds and credits | Functional | High | Billing | Finance integration |
| 2.5.4 | System must manage delinquent patron accounts | Functional | High | Billing | Collections |
| 2.5.5 | System must process recurring monthly fees for auto-pay patrons | Functional | High | Billing | Automation |
| 2.5.5 | System must allow add-on recurring charges | Functional | Medium | Billing | Flexible fees |
| 2.5.5 | System must manage security deposits and refunds | Functional | High | Billing | Financial tracking |
| 2.5.5 | System must process late fees in bulk | Functional | Medium | Billing | Batch processing |
| 2.5.5 | System must support credit card processing fee charges | Functional | Medium | Payments | Configurable |
| 2.5.5 | System must support ACH payments | Functional | High | Payments | Electronic payment |
| 2.5.5 | System must process commercial and private landing fees | Functional | Medium | Billing | Revenue stream |
| 2.5.6 | System must provide real-time reporting and analytics dashboards | Functional | High | Reporting | Management insight |
| 2.5.6 | System must integrate with Microsoft Power BI | Functional | Medium | Reporting | Business intelligence |
| 2.5.6 | System must track user activity logs and transaction history | Functional | High | Security | Audit logging |
| 2.5.6 | System must support data export via APIs or data warehouse | Functional | High | Data Integration | Azure Data Lake |
| 2.5.6 | System must generate occupancy and revenue reports | Functional | High | Reporting | Operations |
| 2.5.6 | System must support ad-hoc and custom reporting | Functional | High | Reporting | User defined |
| 2.5.6 | System must export reports to PDF, Excel, XML | Functional | High | Reporting | Data sharing |
| 2.5.6 | System must support scheduled report generation and distribution | Functional | Medium | Reporting | Automation |
| 2.5.6 | System must support predictive analytics and forecasting | Functional | Medium | Analytics | AI/ML capabilities |
| 2.5.7 | System must manage internal work orders | Functional | Medium | Task Management | Operations |
| 2.5.7 | System must track termination requests | Functional | Medium | Contract Management | Workflow |
| 2.5.7 | System must track vessel change endorsement requests | Functional | Medium | Contract Management | Administrative |
| 2.5.7 | System must track security deposit refund requests | Functional | Medium | Billing | Finance workflow |
| 2.5.8 | System must support daily boat ramp passes | Functional | Medium | Access Management | Patron tags |
| 2.5.8 | System must support annual boat ramp passes | Functional | Medium | Access Management | Expiration tracking |
| 2.5.8 | System must manage annual parking decals | Functional | Medium | Parking Management | Tag tracking |
| 2.5.8 | System must support reservation spot sales through web portal | Functional | Medium | Reservations | Gate verification |
| 2.5.9 | System must support campground management functions | Functional | Medium | Campground Operations | Same functionality as marina |
| 2.5.9 | System must provide campground mapping and site information | Functional | Medium | Campground Operations | Site layout |
| 2.5.9 | System must allow reservations up to 180 days | Functional | Medium | Reservations | Campground rules |
| 2.5.9 | System must provide real-time campsite availability | Functional | Medium | Reservations | Customer visibility |
| 2.5.9 | System must allow seasonal rate configuration | Functional | Medium | Pricing | Flexible pricing |
| 2.6 | System must maintain a unified customer profile across all services | Functional | High | CRM | Single customer view |
| 2.6 | System must track customer reservations, events, and transactions | Functional | High | CRM | Customer history |
| 2.6 | System must support automated customer communications | Functional | Medium | CRM | Notifications |
| 2.6 | System must support targeted marketing communications | Functional | Medium | Marketing | Personalization |
| 2.6 | System must include email marketing and social media integration | Functional | Medium | Marketing | Campaign management |
| 2.7 | System must provide a public-facing marina website | Functional | High | Web Portal | Integrated platform |
| 2.7 | System must provide a mobile responsive website | Functional | High | Web Portal | Mobile access |
| 2.7 | System must provide a mobile application | Functional | Medium | Mobile Services | Customer convenience |
| 2.7 | Users must be able to create and maintain personal profiles | Functional | High | Customer Accounts | Self-service |
| 2.7 | Users must manage reservations and services online | Functional | High | Reservations | Portal capability |
| 2.7 | System must allow purchase of merchandise and gift cards | Functional | Medium | Sales | POS integration |
| 2.7 | System must support registration and payment for events and classes | Functional | Medium | Events | Portal functionality |
| 2.7 | System must allow marina staff to update web content | Functional | Medium | Content Management | Controlled access |
| 2.7 | System must comply with accessibility and County branding standards | Non-Functional | High | Compliance | ADA and branding |
| 2.8 | System must support API integration with County Azure Data Lake | Functional | High | Integration | Preferred integration model |
| 2.8 | System must support one-way and bi-directional interfaces with County systems | Functional | High | Integration | Enterprise interoperability |
Core Functions Categories
| System & Back Office Administration |
| Online Waitlist & Mgmt. |
| User Profile, Berth Permit, Status & Approval Workflow |
| Vessel & RV Placement, Mapping & Management |
| Transient Slip Mgmt. |
| Commercial Landings & Boat Tours Management |
| Billing & Security Deposit Functions |
| Dock Walk Module |
| Reporting |
| Task Mgmt. |
| Vendor Mgmt. |
| Boat Launch Annual Pass, Parking Decals & Backfill Reservations |
| Campground Management |
| Customer Relationship Mgmt. |
| Interface & IT Related |
| Training & Technical Support |
Requirements Matrix Proposers Response "Y" - Fully meets or exceeds requirement (without configuration or modification).
"C [Date]" - If the requirement can be met through customization, modification, configuration, or with a plug-in or add-aon. Provide expected date of completion. Any additional cost for this category must be included on the Price Proposal Form.
"N" - Will not be met. A blank or N/A in any box will be interpreted as a "N".
Proposers Comment A comment field is provided for each item to briefly explain any implementation details, limitations or alternative solutions
| # | Feature Description | Core Functionalities | Category | Must Have, Should Have or Nice to Have | |
| Response ( Y / C [Date] / N) | Comment | Scoring Criteria | |||
| System & Back Office Administration | BO- Back Office | ||||
| Online Waitlist & Mgmt. | Web - Onling Module | ||||
| User Profile, Berth Permit, Status & Approval Workflow | I - Interface or IT related | ||||
| Vessel & RV Placement, Mapping & Management | Mob - Mobile Features | ||||
| Transient Slip Mgmt. | T -Technical | ||||
| Commercial Landings & Boat Tours Management | |||||
| Billing & Security Deposit Functions | |||||
| Dock Walk Module | |||||
| Reporting | |||||
| Task Mgmt. | |||||
| Vendor Mgmt. | |||||
| Boat Launch Annual Pass, Parking Decals & Backfill Reservations | |||||
| Campground Management | |||||
| Customer Relationship Mgmt. | |||||
| Interface & IT Related | |||||
| Training & Technical Support | |||||
| 1.01 | Provide online portal to allow customers to create a user profile/account, apply for a wait list position on wet slips, dry storage, moorings or commercial locations on more than one marina. | Online Waitlist & Management. | WEB | ||
| 1.02 | Allow customers to be added to waitlist without boat information. | Online Waitlist & Management. | WEB | ||
| 1.03 | Wait list is charged per slip size and category, per Marina. Examples: 30' & 35' wet slip at Crandon Marina is two (2) applications fees. 30' & 35' wet slip at Crandon & Matheson is four (4) applications fees. | Online Waitlist & Management. | WEB | ||
| 1.04 | No limit on the amount of applications, although a maximum of two (2) active Berth Permits per individual are permited across all 6 marinas. This rule needs to be clear and provided during the application process. | Online Waitlist & Management. | |||
| 1.05 | Waitlist applications are finalized with a online payment at checkout. Wait list applications are placed on the waitlist, once payment is received. Email wait list confirmation and receipt to customer. | Online Waitlist & Management. | WEB | ||
| 1.06 | Allow customers to view their wait list status / placement by marina or slip type online. | Online Waitlist & Management. | WEB | ||
| 1.07 | Allow existing wait list applicants to update their contact information, not name. | Online Waitlist & Management. | WEB | ||
| 1.08 | Allow existing wait list customers to add new wait list applications. | Online Waitlist & Management. | WEB | ||
| 1.09 | The solution must support the migration and management of existing waitlist of over 5,000 patrons into the new system. | Online Waitlist & Management. | WEB | ||
| 1.10 | Ability for Marina staff to review online applications and managing wait lists on all marinas individually. | Online Waitlist & Management. | BO | ||
| 1.11 | Ability to maintain eligibility criteria based on specific marina requirements. | Online Waitlist & Management. | BO | ||
| 1.12 | Ability to set & inform patron on waiting list requirements and parameters. | Online Waitlist & Management. | BO | ||
| 1.13 | Ability to track efforts made to contact a patron on the waiting list with a contact log showing employee who made contact, results of effort, text field for notes and confirmation of receipt by patron. | Online Waitlist & Management. | BO | ||
| 1.14 | Ability to track waiting list activity per patron with a log of when patron was added/removed to/from list. | Online Waitlist & Management. | BO | ||
| 1.15 | Ability to generate email or SMS to inform patron on their movement on the waiting list (waitlist automatic with set parameters). | Online Waitlist & Management. | BO | ||
| 1.16 | The inability for blacklisted patrons to submit application. | Online Waitlist & Management. | |||
| 1.17 | Ability to flag user profile and place on a blacklist. | Online Waitlist & Management. | |||
| 1.18 | The solution shall enforce waitlist integrity by preventing applicants from being bypassed, unless an authorized overide is applied and properly documented. | Online Waitlist & Management. | |||
| 1.19 | Ability to look up customer profiles/accounts by searching partial data input into multiple fields. Search by Name, Permit #, Slip# and Vessel or RV data on desktop or mobile device. | User Profile, Berth Permit, Status & Approval Workflow | |||
| 1.20 | Once patron reaches the top of the waitlist. Marina Staff can assign slip and submit all required documents to Downtown Administrative Staff for Approval. Permit# is assigned at the moment patron is pulled from the waitlist and given a slip assignment. If Patron already has a profile, system should link new permit to patron profile. Permit will remain on "Pending" status until, downtown staff provides final approval. | ||||
| User Profile, Berth Permit, Status & Approval Workflow | BO | ||||
| 1.21 | System should generate a Permit # once approved with Miami-Dade County current 7 digit sequence specific to each Marina associated with a specific waitlist application. | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.22 | Ability to capture and maintain patron and boat information (must be able to track and maintain multiple boats for a patron). | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.23 | Ability to generate new contract agreement/Permits and auto fill with existing patron data records. Patron should have the ability to update only certain profile data. Examples: patron can update phone#, addresss, emergency contacts, email but not slip#, name, permit # or vessel information. | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.24 | Contracts/agreements require three steps for approval. Patron signature, Marina Manager signature & Approval Stamp by downtown Marina Administration Staff. Once completed final copy stored with capabilities to download PDF in printer friendly format. | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.25 | Tickler process to track expiration of vessel registration, insurance or any required document. Capture, maintain, communicate through email and through customer portal. Including the rejection or approval of such documention. Permit status (pending submittal, pending review, approved, rejected). | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.26 | Ability to digitally sign contract as well as print at the facility, upload and mark status. | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.27 | Document management solution should have a "pending" stage that will allow designated users to approve or decline the document before being saved to a user profile. Pending documents should be on a document task management module reflecting status. | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.28 | Provide document management solution with PII (Personally Identifiable Information) security, such as driver license, proof of insurnace, boat registration, vendor registration documents. | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.29 | Document management solution will allow unlimited amount of documents to be attached to any profile. Ability to view and track/manage status of documents by type (Permit, Insurance, Registration, Change Endorsement/vessel rate change, Termination Request, etc). This should be viewed on the customer profile, individual and all Marina Report. Terminations & Vessel Rate Change Request should indicate a effective date set by Marina Manager to ensure task is completed & prioritized by Administration staff. | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.30 | System must automatically determine or allow input of expiry date of documents uploaded or permit with robust internal and external notifications of expiring documents, annual fees or permits (including waitlist, vendors or boat launch decals). | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.31 | Provide functionality to view monthly statements and account history. | User Profile, Berth Permit, Status & Approval Workflow | BO | Must Have | |
| 1.32 | Ability to add notes to existing accounts. | User Profile, Berth Permit, Status & Approval Workflow | Mob | ||
| 1.33 | Allow existing marina customers to edit their contact information online but not name. | User Profile, Berth Permit, Status & Approval Workflow | WEB | ||
| 1.34 | Ability for patrons and staff to upload required berth permits documents online. | User Profile, Berth Permit, Status & Approval Workflow | WEB | ||
| 1.35 | Set requirement of documents for approval status. Depending on contract type, the list will vary. | User Profile, Berth Permit, Status & Approval Workflow | WEB | ||
| 1.36 | System should allow customization of file types and size accepted for uploading. | User Profile, Berth Permit, Status & Approval Workflow | WEB | ||
| 1.37 | Ability for staff to view edit customer and boat details using mobile device. | User Profile, Berth Permit, Status & Approval Workflow | Mob | ||
| 1.38 | Allow existing marina customers to view their balances, make single payments or subscribe to AutoPay online. | User Profile, Berth Permit, Status & Approval Workflow | WEB | ||
| 1.39 | Provide functionality to terminate a patron and track termination reasons/notes. Ability process a termination for a future date. | User Profile, Berth Permit, Status & Approval Workflow | BO | ||
| 1.40 | Ability to view camera feed by designated user groups. | User Profile, Berth Permit, Status & Approval Workflow | WEB | ||
| 1.41 | Ability to register temporary or permanent vessel movements within the marina. | Vessel & RV Placement, Mapping & Management | Mob | ||
| 1.42 | Ability to check slip, dry storage & mooring availability. | Vessel & RV Placement, Mapping & Management | Mob | ||
| 1.43 | Ability to enter multiple slip types such as mooring, wet slip, dry storage, seawall, etc. | Vessel & RV Placement, Mapping & Management | BO | Must Have | |
| 1.44 | Provide functionality to allow multiple bookings at any given time for any slip category (Recreational, Transient, Mooring, Dry Storage, Commercial). | Vessel & RV Placement, Mapping & Management | BO | Must Have | |
| 1.45 | Maintain slip configurations such as Slip #, Pier, Type (Wet, Dry, Mooring, Commercial , Floating Dock, Commercial, Sea Wall) Slip Length (30, 35, 40, 45, 50, etc.), min and max parameters and usability along with history of any changes to slip information. | Vessel & RV Placement, Mapping & Management | BO | Must Have | |
| 1.46 | Permit# should show historical reference to waitlist application. The system shall prevent assignment of a slip outside of the applicant's waitlist category (e.g., assigning a 50' slip to an applicant on the 30' waitlist), unless an authorized override is applied. | Vessel & RV Placement, Mapping & Management | |||
| 1.47 | Provide a visual slip management function to easily move vessels from one slip to another slip either on the same dock or to a slip on a separate dock while maintaining slip history. | Vessel & RV Placement, Mapping & Management | BO | Must Have | |
| 1.48 | Ability to configure slips to accept certain vessel dimensions and warn against vessels to large or small for the space. | Vessel & RV Placement, Mapping & Management | BO | Must Have | |
| 1.49 | Provide a graphical representation of all 6 marinas & campground, including vessels in the dock & RV's in the pod. | Vessel & RV Placement, Mapping & Management | WEB | ||
| 1.50 | Block and indicate Wet Slips, Dry Strorage, Mooring, RV sites is unusable if down for Repairs. | Vessel & RV Placement, Mapping & Management | |||
| 1.51 | Slip/site color indicators on mapping should reflect rate types (Recreational, Monthly Transient, Daily Transient, Commercial). Availability needs to be clearly visible. Examples of color indicators: Red= Long Term, Orange=Transient, Yellow=Daily Transient, Green=Available. Split colors can be used to indicate slip/site with multiple occurrences: Red/Green= Long Term Available (Patron away available for double booking). | Vessel & RV Placement, Mapping & Management | |||
| 1.52 | Provide functionality to generate a transient contract for the length of stay. | Transient Slip Management. | BO | ||
| 1.53 | Provide functionality to calculate transient charges by day, week, month, ot recurring 30 billing and take payment in advance of the stay. | Transient Slip Management. | BO | ||
| 1.54 | Ability to issue an invoice for a transient customer. | Transient Slip Management. | Mob | ||
| 1.55 | Ability to take payment for a transient. | Transient Slip Management. | Mob | ||
| 1.56 | Provide functionality to apply promotional or discount rates to transient patrons. | Transient Slip Management. | BO | ||
| 1.57 | Provide transient dockage reservations . Ability to set internal only or both internal and external reservations with payment processing. | Transient Slip Management. | WEB | ||
| 1.58 | The system should offer the capability to view transient slip availability in real-time online. Transient patrons should be able to select a slip and premium rates should be charged. A modified GIS view showing vacancies could be made available. | Transient Slip Management. | WEB | ||
| 1.59 | Ability to schedule commercial landings & boat tours using designated docks, using a calendar view with time slots | Commercial Landings & Boat Tours Management | |||
| 1.60 | Commercial Landing user profile indicating approval status of permit | Commercial Landings & Boat Tours Management | |||
| 1.61 | Ability to calculate and process landing fees by vessel size | Commercial Landings & Boat Tours Management | |||
| 1.62 | Ability to calculate tour boat fees by the quantity of passengers as well as add-on miscellanous fees | Commercial Landings & Boat Tours Management | |||
| 1.63 | Ability to have patrons sign up for scheduled boat tours and provide payment. | Commercial Landings & Boat Tours Management | |||
| 1.64 | Provide Management a tour boat roster sheet for each scheduled event. | Commercial Landings & Boat Tours Management | |||
| 1.65 | Ability to efficiently update current pricing structure when rolling out a rate increase for all patrons | Billing & Security Deposit Functions | |||
| 1.66 | Provide flexibility to apply industry and county standards, such as changes to taxes, tax exempt , fees and rates. | Billing & Security Deposit Functions | |||
| 1.67 | Ability to process receipts, security deposits, refunds, wait list application fees, and have the ability to add other fees in the future. Including annual fee for waitlist, launch decals and vendors. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.68 | Ability to calculate monthly fee based on the larger of the two, vessel size or slip size during intiatial slip assignment or at any point of berth (example: patron on a 40' slip, sells a 39' vessel and buys a 41" vessel. Rate goes from 40' rate to 40' rate for that specific Marina. | Billing & Security Deposit Functions | Must Have | ||
| 1.69 | Provide functionality to maintain and calculate monthly fees and apply charges to the patron’s account on a monthly and/or prorated basis. And capability to apply different rates and/or fees to a patron’s account. Ability to track all rate changes on permits and slip assignments. Historical archive vessel changes. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.70 | Ability to assign general ledger account of at least 60 characters. | Billing & Security Deposit Functions | |||
| 1.71 | Application of payments to accounts with batch processing to post payments to appropriate general ledger account(s) according to site where received (abililty to include GL strings associated with each item fee for posting). | Billing & Security Deposit Functions | BO | Must Have | |
| 1.72 | Generate monthly credit card transactions in the amount of each patron’s monthly recurring charges for submission to the merchant payment processor or payment gateway. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.73 | Ability to process monthly credit card charges in batch mode with confirmation information and credit card batch information written to each transaction record (Autopay Patrons). Abililty to set date of batch transactions. Example 1st of the month on recurring monthly bill, or 11th on late fee charges. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.74 | Ability to enroll and remove patron accounts from AutoPay. Allow entry and maintenance of credit card information. | Billing & Security Deposit Functions | |||
| 1.75 | Ability to require patron to accept to terms and conditions when enrolling in AutoPay (check box & click accept). Achieve record of this agreement with date & time stamp. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.76 | Application should use the County's credit card processor, using existing County assinged Marina MID. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.77 | Ability to report on credit card transactions to facilitate reconciliation and audit trails. Including rejected or declined transactions. | Billing & Security Deposit Functions | BO | Should Have | |
| 1.78 | Ability to resubmit rejected credit card transactions in one or more subsequent batches. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.79 | Provide functionality to debit a patron’s credit card, as well as, to be able to process a batch of credit card payments in one single run (autopay patrons). | Billing & Security Deposit Functions | BO | Must Have | |
| 1.80 | Close-out process will enforce PROS policies for interface to ERP | Billing & Security Deposit Functions | BO | Must Have | |
| 1.81 | Close-out process will record cash and coin denominations and report over/under tils. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.82 | The system will make the appropriate entries to the general ledger when there is an over or under reporting of cash at close-out. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.83 | System will have robust and customizable close-out process. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.84 | System should be able to calculate & display the required security deposit, balance due and ability to generate bill for payment (Security Deposit requirement 2 months of recurring billing). | Billing & Security Deposit Functions | |||
| 1.85 | Provide functionality to refund a patron any charge including security deposits and provide receipt. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.86 | View security deposit balance on a dedicated ledger that tracks any transaction pertaining to security deposit transfering, refunding or appling to any upaid balances when terminating. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.87 | Provide functionality to record existing security deposit payments (historical payments). | Billing & Security Deposit Functions | |||
| 1.88 | Ability to refund security deposit and account balances via credit card or check refund request. | Billing & Security Deposit Functions | |||
| 1.89 | The ability to autofill documentation for the processing of a check refund request in accordance with departmental policies. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.90 | Ability to generate auto filled journal entry form with approvals by selected staff to validate. Form should be downloadabe to a PDF file format and the abilty to add to a task managment workflow. | Billing & Security Deposit Functions | |||
| 1.91 | Provide functionality to convert delinquent or non-complient patrons to transient status and rates if their vessel remains at the marina following a termination. Also the ability to reverse. | Billing & Security Deposit Functions | BO | Must Have | |
| 1.92 | Point of Sale (POS) module provides full cash register/point of sale functionality (e.g. system can fully replace cash register). Ability to use bar code scanner. | Billing & Security Deposit Functions | POS | Must Have | |
| 1.93 | Provide POS module which is fully integrated with other system modules. | Billing & Security Deposit Functions | POS | Must Have | |
| 1.94 | POS and other modules should provide access to the same account balance. | Billing & Security Deposit Functions | POS | Must Have | |
| 1.95 | Provide batch transaction processing for a set day or time. | Billing & Security Deposit Functions | POS | Must Have | |
| 1.96 | Ability for blind close outs. | Billing & Security Deposit Functions | POS | Must Have | |
| 1.97 | Ability to add a deposit number, with validation, to the batch of transactions for interfacing with the ERP Financial system. | Billing & Security Deposit Functions | POS | ||
| 1.98 | Ability to record and track a variety of sales transactions including gas sales, retail sales, ramp passes, rental charges, etc. | Billing & Security Deposit Functions | POS | ||
| 1.99 | Ability to supply customers with itemized receipts to include tax and/or other added fees. | Billing & Security Deposit Functions | POS | ||
| 2.00 | Ability to display cash transactions including balance owed and change to be returned. | Billing & Security Deposit Functions | POS | ||
| 2.01 | Cashiers have the ability to use different terminals in a given day and the transactions specific to a user are accumulated as one total for the day. Similarly, the number of users on a single register is not limited. | Billing & Security Deposit Functions | POS | ||
| 2.02 | Provide breakdown of method of payment used. | Billing & Security Deposit Functions | POS | ||
| 2.03 | Ability to accept/process, issue, and track gift certificates, coupons, vouchers. | Billing & Security Deposit Functions | POS | ||
| 2.04 | POS module accommodates multiple payment methods including cash, checks, ACH and credit cards. | Billing & Security Deposit Functions | POS | ||
| 2.05 | System manages locking cash drawers including automatically opening them when a particular transaction is completed. | Billing & Security Deposit Functions | POS | ||
| 2.06 | Ability to set retail price manually or based on percent mark-up based on cost or by margin. | Billing & Security Deposit Functions | POS | ||
| 2.07 | Associate vendors to inventory item. | Billing & Security Deposit Functions | POS | ||
| 2.08 | Update inventory counts when items is sold. | Billing & Security Deposit Functions | POS | ||
| 2.09 | Provide fuel dock management including FIFO to fuel sales inventory. | Billing & Security Deposit Functions | POS | ||
| 2.10 | Allow for item discount at time of sale. | Billing & Security Deposit Functions | POS | ||
| 2.11 | Capture and maintain fees, rates and merchandise inventory and inventory valuations. | Billing & Security Deposit Functions | POS | ||
| 2.12 | Ability to have the option of automatic generation and of bulk posting of late charges. System automatically calculates late fee with set percentage towards specific items. Bulk posting with the ability to "check all" boxes and ability to unclick individual patrons. Filtered by each Marina or All. | Billing & Security Deposit Functions | BO | ||
| 2.13 | Ability to for patron to choose between different payment options through online portal - Credit or ACH payment processing. | Billing & Security Deposit Functions | WEB | ||
| 2.14 | Ability to provide facilities rentals | Billing & Security Deposit Functions | WEB | ||
| 2.15 | Ability to conduct mobile dock checks. | Dock Walk Module | Mob | ||
| 2.16 | Ability to perform dock check per dock. Examples Dock A, B, C, D, E | Dock Walk Module | BO | ||
| 2.17 | Dock Walk Module should record which employee performed task and record day & time. | Dock Walk Module | |||
| 2.18 | Dock Walk should have the ability to see picture of vessel. | Dock Walk Module | |||
| 2.19 | Dock Walk should indicate if slip is occupied by a Transient or Recreational Berth vessel. | Dock Walk Module | |||
| 2.20 | Dock Walk should be able to quickly mark status: In, Out, Not Vessel Pictured | Dock Walk Module | |||
| 2.21 | Ability to add notes to dock check with text input for notes as well check boxes for vessel condition. | Dock Walk Module | Mob | ||
| 2.22 | Ability to contact vessel owner from dock check with one click and archive communication | Dock Walk Module | Mob | ||
| 2.23 | Archive Dock Walk Results | Dock Walk Module | |||
| 2.24 | Tracker/list to manage all pending terminations, SD deposit refund functions and add any necessary notes for historical reference. | Task Management. | BO | ||
| 2.25 | Ability to view termination requests made through customer profile. Provide a management tracking tool and have Marina Managers and Administration receive notifications. | Task Management. | BO | ||
| 2.26 | Provide approval paths for transactions such as check refunds request, security deposit returns, discounted rates, rebates and promotional considerations in accordance with departmental policies. | Task Management. | BO | ||
| 2.27 | Provide override capability for transactions such as imposition late or delinquency fees with appropriate approval paths in accordance with departmental policies. | Task Management. | BO | ||
| 2.28 | Abilility for Management and Staff to track internal work orders.Repairs/work orders get assigned to a group (Marina Techs) or individual. Once task is has been submitted, group or individual should receive notice. Status will is marked pending, until assignee marks completed. Bonus: Interactive map to be able to select a slip and have a drop down menu of the types of repairs needed (Pedestal replacement , Receptable, breaker, piling, etc) on the slip. | Task Management. | BO | ||
| 2.29 | System allows users to send termination request to marina office. Ability to terminate contract while enforcing a 30 day termination notice policy and allow for manager override. | Task Management. | WEB | ||
| 2.30 | Ability to mark status (Pending Submittle, Pending Approval, Completed) on termination functions including refunds and record voucher # | Task Management. | BO | ||
| 2.31 | Allow Marina Vendors to register and pay vendor fees online. | Vendor Management. | WEB | ||
| 2.32 | Vendor management module for private registered Marina vendors offering vessel repairs and services . Ability to provide vendor profile, employee list, request and upload required documention. Track expiration of such documentation and annual, monthly or daily pass. | Vendor Management. | BO | ||
| 2.33 | Provide ability to manage Vendor criteria such as active business registration. | Vendor Management. | WEB | ||
| 2.34 | Marina Vendors are able to schedule appointments with marina patrons. | Vendor Management. | WEB | ||
| 2.35 | Ability for users to search through Vendors by category, including prices and services available without favoring one vendor over another. | Vendor Management. | WEB | Must Have | |
| 2.36 | Manage multiple marinas and generate reports from one central location. | Reporting | |||
| 2.37 | Report tracking # of monthly and fiscal year terminations. | Reporting | BO | Must Have | |
| Ability to generate reports to marina staff and management by slip type, slip size and placement. | Reporting | BO | Must Have | ||
| 2.38 | Provide reports on new marina patrons. Ability to filter by revenue category - Recreational (wet, dry, mooring) transients (wet, dry, mooring) and Comercial Slips. | Reporting | BO | Must Have | |
| 2.39 | Provide slip utilization reports by marina for a specified time period. Utilization reports should have the ability to provide a breakdown of utilization per pier, type and size. Example: Wet Slips total, Wet Slip 30ft, 35ft. 40ft, 50ft, Dry storage, Mooring, Commercial, Transients. | Reporting | BO | Must Have | |
| 2.40 | Provide functionality to track Boat Ramp Pass information sold to patrons on a yearly basis. | Reporting | BO | ||
| 2.41 | Generate management reports showing loss of revenue, and outstanding fees due by delinquent patrons. | Reporting | BO | ||
| 2.42 | Generate daily check request and refund transaction reporting. | Reporting | BO | ||
| 2.43 | Provide a user-friendly interface to allow users to create custom reports. Example: transactions report for any item at any specific Marina or all Marinas for specified time period. | Reporting | BO | ||
| 2.44 | Ability to track inventory of physical goods sold from wholesale packaging to retail units. | Reporting | POS | ||
| 2.45 | Ability to track goods sold from inventory and create a COGS statement. | Reporting | POS | ||
| 2.46 | Ability to maintain inventory data such as quantity on hand, reorder point, normal stocking level and quantity on order | Reporting | POS | ||
| 2.47 | Track sales history and last sold date per item. | Reporting | POS | ||
| 2.48 | Track and transfer delinquent account balances to AR for reporting. | ||||
| Ability to track delinquent accounts by individual Marinas or all county Marinas. | Reporting | BO | |||
| 2.49 | Ability to provide account receivable aging reports (30, 60, 90 days) on over due items & abilility to select items included on report. Example view recurring montly billing only, excluding SD balances due. | Reporting | BO | ||
| 2.50 | Provide reporting to track changes patron profiles and billing, such as rates or slip #. | Reporting | BO | ||
| 2.51 | Provide reporting to track issuance of credits, adjustments, rebates, refunds and promotional discounts by user. | Reporting | BO | ||
| 2.52 | Generate daily summary reporting by site of transactions by type, general ledger account, sales tax status, payment type, credit card type and by customer. | Reporting | POS | ||
| 2.53 | Generate daily detail reporting by site of transactions by type, general ledger account, sales tax status, payment type, credit card type and by customer. | Reporting | POS | Must Have | |
| 2.54 | Once future possible KPIs and relevant industry benchmarks are agreed upon, the system should have the capacity to automatically calculate and present support graphics. Power BI is already capable of fulfilling this requirement. Revenue report at wet slip level. GIS and Power Bi integration | Reporting | BO | ||
| 2.55 | Annual boat ramp launch pass, track expiration and tag. Ability for attendent to verify by searching by tag. | Boat Launch Annual Pass, Parking Decals & Backfill Reservations | |||
| 2.56 | Annual patron parking decals, track expiration and tag. Ability for attendent to verify by searching by tag. | Boat Launch Annual Pass, Parking Decals & Backfill Reservations | |||
| 2.57 | The system should have the capacity to implement a Boat Launch Reservations system for back filling available parking at Boat Ramp and charge a premium fee through a web portal. Certain number of spots will be advertised, first patrons to provide payment will secure reservation spot. Sytem will store vehicle tag and reservation number and give Marina staff the ability to verify at gate. Expiration of reservation will be set and clearly indicated at checkout. | Boat Launch Annual Pass, Parking Decals & Backfill Reservations | WEB | ||
| 2.58 | The system have the capability to interface with a real-time boat ramp camera and display launch availability. Have a notification system to send email or SMS to all registered . This would provide trailered boat customers with the visual information they need to plan their launch, thus replacing the current ramp notification system with a more current and visually enhanced customer service tool. | Boat Launch Annual Pass, Parking Decals & Backfill Reservations | WEB | ||
| 2.59 | Ability to use software for our campground reservations at Larry & Penny Thompson Park, have maps designed specific to campground. Biscally Marina on land. | Campground Management | BO | Must Have | |
| 2.60 | Provide campground staffing a reservation system with the ability to book a complex extended stay reservations as follows: |
- 6 month limit on a reservation. In order to stay 6 months, patron may have to move to three different pods to find availability for an extended stay.
| Ability to displaying best possible path of booking multilple pods to fullfill reservation request. | Campground Management | BO | Must Have | ||
| 2.61 | Maximum Reservation 180 days | Campground Management | Must Have | ||
| 2.62 | Real-time updates on site availability | Campground Management | Must Have | ||
| 2.63 | Ability to set up parameters for seasonal rates | Campground Management | Must Have | ||
| 2.64 | Ability to set restrictions/parameters for patron self booking. | ||||
| Examples: Ability to allow patron to book reserverations for 30 days or under. Extended stay reservations will have to be booked by campground staff by request. | Campground Management | ||||
| 2.65 | Ability to block reservations pods/sites for low season | Campground Management | |||
| 2.66 | Ability to send text, patron portal inbox notifications and email reminders to all patrons or a subset of patrons (i.e. payment due reminders). | Customer Relationship Management | BO | ||
| 2.67 | Ability to send bulk text or emails for special events, bad weather conditions, Marina related information. | Customer Relationship Management | BO | ||
| 2.68 | Ability to create multiple email and contract templates. Templates must have the capabilties to mail merge relevant fields from the system to generate a customized email for each user. At minium these templates can be built by software developer in the implementation process and than maintained/altertered by request thereafter. | Customer Relationship Management | BO | Must Have | |
| 2.69 | System must log all notifications sent from system (email log). | Customer Relationship Management | |||
| 2.70 | Ability to create and maintain automated work flows for the different email templates. For example, a Past-Due Notice will include a "Pay Now" option with link to provide payment. | Customer Relationship Management | BO | Must Have | |
| 2.71 | Generate printer friendly statements of delinquent accounts to send to patrons via by mail/personal delivery and/or email. | Customer Relationship Management | BO | Must Have | |
| 2.72 | Notification alert for through internal staff and patron portal, informing of past due, document pending status, through a banner at Patron/vessel profile view. | Customer Relationship Management | BO | Must Have | |
| 2.73 | Generate email informing patrons of delinquent status, and termination notices as appropriate. | Customer Relationship Management | BO | Must Have | |
| 2.74 | Ability to notify selected users groups through SMS and internal messaging of boat ramp opening and closing. | Customer Relationship Management | BO | Must Have | |
| 2.75 | Ability to send email to customers based on parameters and ability to use custom templates (i.e. email every patron in dry storage) | Customer Relationship Management | BO | Must Have | |
| 2.76 | Ability to produce alerts notifications and reports for expiring credit cards. | Customer Relationship Management | BO | Must Have | |
| 2.77 | System should recognize when it is sending the 1st, 2nd, and/or 3rd notice and send the appropriate message to the customer. | Customer Relationship Management | BO | Must Have | |
| 2.78 | Ability Send email or text to Customer from the mobile device. | Customer Relationship Management | Mob | Must Have | |
| 2.79 | Ability to push notifications to users for any notices that are sent out through email, sms, or phone. | Customer Relationship Management | Mob | Must Have | |
| 2.80 | Ability to create patron survey, have system gather all responses and calculate scoring averages. | Customer Relationship Management | BO | ||
| 2.81 | Ability to view patron messages through a notifications center, during dock check and when viewing patron profile. | Customer Relationship Management | BO | ||
| 2.82 | Ability for Patron to send communications to Dock Office through application. | Customer Relationship Management | |||
| 2.83 | Patron should have a notification center with message inbox. | Customer Relationship Management | WEB | Must Have | |
| 2.84 | Ability for patrons to complete surveys created by Marina Staff | Customer Relationship Management | WEB | Must Have | |
| 2.85 | Ability to notify users of expiring documents, 10, 20, 30 days before they are due through SMS, Email or messaging within the system. | Customer Relationship Management | BO | Must Have | |
| 2.86 | Ability to notify customers of status changes (i.e. Permit has been approved). | Customer Relationship Management | BO | Must Have | |
| 2.87 | Notifications sent to patrons by email or SMS which provides links to portal regarding expiring documentations | Customer Relationship Management | WEB | Must Have | |
| 2.88 | Vendor must provide well-documented RESTful APIs (OpenAPI/Swagger preferred) exposing all relevant entities (customers, reservations, assets, invoices, payments, etc.) using JSON as the standard data format (XML/CSV optional). APIs must support OAuth 2.0 or Azure AD-based authentication for secure access. | Interface & IT Related | I | Must Have | |
| 2.89 | Vendor must provide either API or secure file transfer (SFTP/HTTPS endpoint) access enabling PROS/CITD to ingest raw and curated data into Azure Data Lake Gen2 using Azure Data Factory (ADF) pipelines. Vendor is not responsible for ADF configuration but must ensure stable data access endpoints. | Interface & IT Related | I | Must Have | |
| 2.90 | Vendor must deliver a complete data dictionary, ERD, and field-level definitions (data types, constraints, relationships). This documentation will allow CITD Data Engineering to perform schema mapping and ETL transformation. | Interface & IT Related | I | Must Have | |
| 2.91 | Vendor must expose financial and transactional data endpoints that can be consumed by County ADF/Logic Apps for synchronization with Oracle-based ERP. Vendor is not required to perform the ERP connection itself. | Interface & IT Related | I | Must Have | |
| 2.92 | Vendor’s platform shouldintegrate with County payment gateway to handle all payments through PCI-DSS-compliant tokenization. Sensitive data must never be stored or transmitted in plain text. | Interface & IT Related | I | Must Have | |
| 2.93 | Vendor must expose APIs or data views linking marina assets (slips, docks, pumps, etc.) to maintenance or work order records. PROS/CITD will consume these via ADF/Logic Apps to synchronize with EAMS. | Interface & IT Related | I | Must Have | |
| 2.94 | Vendor must expose customer, membership, and reservation APIs compatible with Dynamics 365 CRM integration through Azure Logic Apps. No direct CRM integration is required from the vendor. | Interface & IT Related | I | Must Have | |
| 2.95 | Vendor must ensure data is accessible and performant for analytics ingestion. County Data Engineers will design Synapse pipelines, datasets, and Power BI dashboards. Support for incremental queries, metadata exposure, and consistent primary keys is required. | Interface & IT Related | I | Must Have | |
| 2.96 | Vendor must support both scheduled and near real-time data pulls (≤ 5 minutes latency) via APIs, file exports, or webhooks. Event-driven mechanisms (e.g., push notifications) are preferred. | Interface & IT Related | I | Must Have | |
| 2.97 | Vendor must ensure compliance with County cybersecurity policies, PCI-DSS, GDPR, and relevant U.S. privacy frameworks. APIs must support TLS 1.2+, enforce role-based access, and store credentials securely (Azure Key Vault managed by County). | Interface & IT Related | I | ||
| 2.98 | Vendor must provide descriptive metadata for each dataset (table purpose, update frequency, lineage notes) to allow ingestion into Microsoft Purview for cataloging and governance. | Interface & IT Related | I | Must Have | |
| 2.99 | Vendor must provide access to audit logs and API usage logs (timestamps, endpoints, response codes) to enable monitoring via Azure Monitor and Application Insights. | Interface & IT Related | I | Must Have | |
| 3.00 | Vendor APIs must return standard HTTP response codes, structured error messages, and support idempotent retry mechanisms to allow reliable County pipeline orchestration. | Interface & IT Related | I | Must Have | |
| 3.01 | Vendor must follow semantic versioning (v1.0, v1.1, etc.) for APIs and provide a minimum 90-day deprecation notice for any breaking change. County CI/CD pipelines (in Azure DevOps) will handle deployment version control. | Interface & IT Related | I | Must Have | |
| 3.02 | Vendor APIs must support horizontal scaling and handle peak concurrent requests without throttling beyond published limits. Response latency should remain < 2 seconds for standard calls. | Interface & IT Related | I | Must Have |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .