Preparing an RFP can be a difficult task. 
You know what you want...but now you have to put it in writing...

WindoWare has been asked on many occasions to
provide "boilerplate" language to make this task easier.



 Download this document (MS Word Format)
The (City/County/Town) desires a software program already designed (“off-the-shelf”) to perform these and other
specified functions. It is not the intention of the City to have software specifically created for these purposes in
response to this request for proposal.
 
The software package (specific version proposed) must be completely “real-time” and should have a verifiable
history of success in the management of municipal permitting and inspections processing. The City/County/Town
has identified the following issues and system features as being important and should be addressed thoroughly
in your proposal.  The software must be a “real-time” package where all files affected by transactions are updated
at the time the transaction is entered.  The system must be capable of simultaneously processing multiple
transactions (inquiry, update, report generation) from multiple users.  The system must be able to accommodate
the addition of workstations simply and cost effectively without significant increase in response times.
Software Features - General:

 
1. The proposed request for service software should make use of the following features:

 
Windows NT 4.0, Windows 95/98, Windows 2000 & Windows XP compatibility

Graphical user interface

Pull-down menus, scroll bars

Edit screens for the files should allow additions, edits and deletions
 

Browsing capability should be built into the system to allow easy search and retrieval

 

2. User maintainable tables that can be accessed when entering or updating permit
applications to eliminate redundant data entry.

 
3. Describe how the proposed system would allow for additions, deletions and changes
to data elements.

 
4. Movement among screens should be simple.  A maximum of 3 screens per permit
record is desired.

 
5. Print screen capability is desired.

 
6. Provide samples of the standard reports/screens available with the system you propose.
Discuss the procedures for generating ad hoc reports.
7. The databases(s) must be ODBC compliant.

The software should be designed to include the following specific features:

 
1. The system should allow for entry of historical (closed) permits and active permits issued
prior to installation. The system should allow for relating trade permits to a building permit.
The user should be able to look up permits by permit number, tax map number, owner name,
or contractor.

 
2. The system should track permits through the following phases:

 
a) Application and approvals

 
b) Issuance without conditions

 
c) Issuance with conditions

 
d) Work in progress

 
e) Work completed – final inspection has been done and was approved

 
f) Certificate of Occupancy (when applicable)

 
3. The system should print all permits on standard letter size paper. The user should be
able to specify the number of copies required.  The system should be able to reprint a
permit at any time.

 
(If your department does not receive payment in your office:)

 
The system should also print a payment “coupon” with the appropriate data for the
applicant to present to the Finance Department when making payment.

 
(If your department does receive payments in your department:)

 
The system should automatically track payments, allowing for payment by cash, check,
and credit card or any combination.  The system should allow for payments for any reason
and create revenue reports on demand.  The revenue report must summarize payments by
account number and show payment detail, including Date Received, Received From,
Payment Method, Purpose of Payment and Transaction Number.

 
4. The system should calculate the fee based on user input and automatically calculate
any additional fees imposed by another agency (i.e. state/county imposed fees) that the
City/County/Town must collect.

 
5. The system should include the following user maintainable tables:

 
a) Contractor database – Including company name, address, voice & fax phone numbers,
email address, contact name, type of contractor, up to 6 municipal and/or state licenses
with expiration dates, accumulated YTD value of permits issued, bond number and
amount, alert fields and general remarks.

 
b) Parcel database – including owner(s) name and address, parcel address, tax map
number, tax account number, and any features of existing structures.

 
c) Inspection Types database – including the ability to define inspection sequences.

 
d) Architect/Engineer database – names and addresses of professional firms who
submit documents to this department.

 
(For Virginia jurisdictions)
e) Mechanics’ Lien Agents database – names and addresses of firms who place
mechanics’ liens on various construction projects.

 
f) Inspector database – names and ID’s of inspectors.

 
g) Neighborhood/District database – name and ID to define specific areas
of the jurisdiction.

 
h) Project Code database – description and ID to categorize various type of permits
according to the type of work.

 
i) Account Codes database – to define the general ledger account numbers required
by Finance so that funds generated by this department can be properly credited.

 
j) Fee Table database – Separate fee tables for each type of permit.  The fee tables
should be flexible and allow for any type of fee structure.

 
6. The permit application process should allow for routing to departments that must approve
applications prior to issuance.  The system should allow for the department to view, approve
or deny, and enter comments for those applications that have been routed to it.  The system
should also allow for the Inspections department to enter approvals received from any
department.

 
7. The system should allow for both permit-related inspections and code enforcement
inspections (trash, weeds, junk cars, zoning violation complaints).  The system should
allow for scheduling on any date desired and by any inspector.  The system should
provide for resolution of failed inspections.

 
8. The system must print out inspection tickets for any inspection requests on a specific
day, in total or by inspector and be capable of downloading inspection request records
to a hand-held PC (running Windows CE) or laptop computer.  The system must also have
the capability of uploading from an H/PC and automatically update the inspection master
database.

 
9. Reporting functions should include the following:

 
a) Daily and periodic (user defined date range) revenue reports with summary
by account number and payment detail.

 
b) Monthly activity report – including subsections by major groups or permit type
(new residential, residential alternations, new commercial construction, etc.).
The report should also include a summary by project type including work values
and number of permits, number and detail of any certificates of occupancy issued
during the month and summary totals of revenue generated.

 
c) Periodic reporting (user defined date range) for a specific permit type or
all permits including number of permits, inspections and revenue generated.

 
d) The system should generate the required data to complete the Bureau of
Census and Dodge reports.

 
e) The system should be able to generate inspection histories for any permit
or set of related permits.

 
f) The system should be able to generate a report for all activity for a
specific address.

 
g) The system should be able to generate a report for all failed inspections
that have not been resolved.

 
h) The system should be able to generate a report for all permits that have had
no activity for at least six (6) months.

 
i) The system should be able to generate a report for a specific contractor or
all contractors, with detail or summary totals only, for a specific year.

 
j) The system should be able to generate a bill for charges incurred for re-inspections.

 
k) The system should generate listings for any user-maintainable database.

 
l)The system should generate a list of contractors by qualification.

 
m) The system should allow for all reports to be printed on screen or
directed to the appropriate printer.

 
10. The system should allow for lookups (read-only) of permits and cases by permit number,
owner name, address, and tax map number.
Download this document (MS Word Format)


 


©2008 WindoWare! Inc. All Rights Reserved  Questions or comments about this site? Contact webmaster@windowareinc.com