Most marine software RFPs fail before the first vendor replies. They list features as nouns ("offline mode", "PMS", "reporting"), leave the answer format open, and ask for pricing "in the vendor's preferred format". Every vendor then answers yes to everything, in a different structure, with a different cost model, and the evaluation team ends up comparing six brochures. A useful RFP does the opposite. It describes what the software must do on your ships, as behaviour someone can observe. It forces every vendor into the same response codes and the same pricing sheet, and it publishes the scoring weights before anyone replies. This guide gives you that structure section by section, with sample requirement wording for inspections, planned maintenance, record books, offline use and data ownership. If you would rather see how one platform answers it first, open a free Marine Inspection account and test it against your own draft requirements.
Eight sections that get answers you can compare side by side. Use it as the skeleton for your own tender document.
Where the RFP sits in the buying process
An RFP works best as the middle of the process, not the start. A short request for information narrows the field first, and a scripted demo and a single-vessel pilot follow the written answers. Sending a full RFP to fifteen vendors produces fifteen responses nobody has time to read properly.
Two pages: fleet size, vessel types, must-haves.
Drop anyone who fails a must-have.
One clarification round, with answers shared with all bidders.
Same scenarios for each finalist.
One vessel, agreed success measures.
For the demo stage, use our 20 questions to ask on a marine software demo call.
Fix the response codes before you write a single requirement
Open text answers make comparison impossible. Give vendors a fixed set of codes, allow nothing else, and require evidence for every code above "not supported": a documentation link, a screenshot reference or a demo step. Never count roadmap items as available capability. If a requirement is critical, it must work in production today.
Illustrative data. With open answers, all three vendors would have claimed near-full coverage. Coded answers show that Vendor B depends on 19 items of custom work or future releases, while Vendor C's four gaps need checking against your must-haves.
The eight sections of the RFP
Each section below lists what to include and gives sample requirement wording. Every requirement is written as behaviour a vendor can demonstrate, not as a feature name. Copy the wording, then adjust it to your fleet.
- Number of vessels by type, flag and class society
- Trading areas and typical connectivity on board
- Current systems being replaced, and why
- Number of users ashore and on board, by role
- Inspections and checklists, including vetting and PSC preparation
- Defects to work orders, planned maintenance, spares
- Certificates and survey due dates
- Deck and engine logbooks
- Which functions work with no connection
- Sync conflict handling
- Bandwidth use and upload controls
- Supported devices on board
- Flag approvals for MARPOL electronic record books under IMO guidelines MEPC.312(74)
- Class acceptance of the maintenance module for an approved PMS scheme
- Audit trail on closed records
- Who maintains regulatory checklist libraries
- Systems to connect: procurement, crewing, accounts
- Data import from your current platform
- Full export on exit, including media
- Data ownership and hosting location
- Certifications and penetration testing
- Encryption at rest and in transit
- Role-based access matching your SMS roles
- Fit with your cyber risk management, and IACS UR E26/E27 for newbuilds
- Implementation plan and named team
- Training approach for rotating crews
- Support hours by time zone and response times
- Languages available to crew
- Your pricing sheet, which vendors must use
- Contract length, notice period, renewal caps
- Trial or pilot terms
- Price for adding or removing vessels
Write requirements as behaviour, not features
A feature name invites a yes from any vendor with a roadmap. A behaviour, paired with an evidence field, makes the vendor either show the capability or name the gap. Here is the same requirement written both ways.
Send your own pricing sheet
If pricing is left to the vendor, you get per-user, per-vessel, per-module and enterprise models that cannot be compared. Send one sheet with fixed lines and a fixed currency. Our pricing breakdown guide explains how to normalise quotes that arrive anyway, and our hidden costs guide lists what vendors leave out.
| Line | Unit | What the vendor must state | Why it is on the sheet |
|---|---|---|---|
| Subscription | Per vessel per year | Price and modules included | Normalises per-user and per-module models |
| Shore users | Per user or included | Any user cap and overage price | Office headcount grows faster than fleets |
| Implementation | One-off | Data import, configuration, days on site | Often priced separately after signature |
| Training | One-off and recurring | Initial training and cost for new crews | Crew rotation makes training continuous |
| Integrations | Per integration | Build cost and yearly maintenance | The most common source of change orders |
| Support | Included or tiered | Hours, response times, premium tiers | 24/7 cover is sometimes an add-on |
| Exit | One-off | Full data export cost, if any | Should be zero, and written into the contract |
| Renewal | Percentage | Maximum yearly increase | Protects the business case beyond year one |
Publish the weights before responses arrive
Deciding weights after proposals arrive invites a challenge from the losing bidder and lets the best presentation win. Put the weights in the RFP itself. These are suggested starting weights for an inspection and maintenance platform, so adjust them to your fleet.
Suggested weights. Any must-have scored "not supported" disqualifies the vendor before weighting.
Common RFP mistakes to avoid
Each of these has the same effect: vendors look more alike on paper than they are on a ship. If you are replacing a current system, read how to switch marine inspection software safely alongside this guide.
Frequently asked questions
Long enough to cover the eight sections, with around sixty well-written requirements. Longer documents tend to get bulk yes answers rather than careful ones.
Three to five, after a short request for information has removed vendors that fail your must-haves.
Three to four weeks with one clarification round is a common allowance for a requirement set of this size. Rushed deadlines favour vendors with canned answers.
Not as available capability. Score only what works in production today, and treat roadmap items with a release date as a separate note.
Send us your requirements and we will answer them in your format, with fixed response codes, evidence for each one, and pricing on your sheet.
