How to use this guide
A Procurement Room turns Marintel's maritime data room into a competitive tender. If you buy — newbuild slots, drydock and repair, bunkers, spares, crewing, or any package where several suppliers compete — you are the Issuer. Each supplier you invite is a Bidder, and the load-bearing rule of the whole product is that no bidder can ever see, count, or infer another.
- New to Marintel procurement? Read What is a Procurement Room and The RFx Lifecycle, then follow the stages in order.
- Running a tender now? Jump to the stage you are in from the table of contents.
- Deciding whether to seal bids? Read Sealed Bids before you create the room — sealing is a decision made at room creation.
Table of contents
- What is a Procurement Room
- The RFx Lifecycle
- Roles & Isolation
- Stage 1 — Setting up the tender
- Stage 2 — Inviting bidders
- Stage 3 — Questions & Answers
- Addenda — formal package changes
- Stage 4 — Submission & deadlines
- Sealed Bids
- Stage 5 — Evaluation & Award
- The Audit Trail
- What Marintel gives you
- Common failure modes
What is a Procurement Room
A Procurement Room is a Marintel room whose type is procurement. It runs a competitive tender in one of three modes:
- RFI — Request for Information, to shortlist capable suppliers.
- RFP — Request for Proposal, where technical approach matters as much as price.
- RFQ — Request for Quotation, where a defined scope competes primarily on price.
You pick the opening mode when you create the room; the room then moves through a fixed lifecycle. Every bidder you invite gets a hard-isolated section — their own private workspace inside the room. Isolation is enforced on the server for every single request, not hidden in the browser: a bidder's credential can never enumerate, count, or even confirm the existence of another bidder. Access failures return the same "not found" a stranger would get, so nothing can be probed.
Because it is a Marintel room, everything the data room already does — AI document classification and extraction, Marintel IDs, dynamic watermarks, and the append-only signed audit chain — applies to the tender too.
The RFx Lifecycle
A procurement room advances through five working stages. You control the transitions; Marintel enforces what each stage allows.
| Stage | What happens | Who acts |
|---|---|---|
| Publish | The package is issued to every invited bidder at once. Questions open. | Issuer |
| Q&A | Bidders ask; the Issuer answers privately or publishes anonymised to the whole field. | Bidder & Issuer |
| Submission | Bidders upload and lock their responses before the deadline. | Bidder |
| Evaluation | The Issuer scores each bid against a weighted rubric and compares side by side. | Issuer |
| Award | The winning bid is recorded with a written rationale on the audit chain. | Issuer |
Two deadlines drive the tempo: a question deadline (after which no new questions are accepted) and a submission deadline (after which bids are flagged late rather than refused — see Submission & deadlines). Marintel reminds bidders automatically as each deadline approaches.
Roles & Isolation
There are two audiences — Issuer and Bidder — and each has an admin and a member tier.
| Role | Sees | Can do |
|---|---|---|
| Issuer Admin | Everything: all bidder sections, all questions, all submissions. | Create the room, invite bidders, publish, answer, set deadlines, unseal, score, award. |
| Issuer Evaluator | All sections (read) and the evaluation matrix. | Score bids against the rubric. |
| Bidder Admin | Only its own section, plus the Issuer's published package and anonymised Q&A. | Upload, ask questions, acknowledge addenda, submit-and-lock, manage its own users. |
| Bidder User | Only its own section. | Upload, ask questions, acknowledge addenda. |
The isolation guarantee is absolute and worth stating plainly: bidder-facing responses, notifications, and error messages never reveal another bidder's existence, identity, count, documents, or activity. A bidder that mistypes a section ID, or tries a URL it should not know, receives the identical "not found" an outsider would — there is no signal to distinguish "exists but not yours" from "does not exist".
Stage 1 — Setting up the tender
An Issuer Admin creates the room and makes three decisions up front.
Opening mode (RFI / RFP / RFQ)
- What it does: Sets the tender's framing and the label bidders see. You can run an RFI first to shortlist, then a follow-on RFP or RFQ with the qualified field.
Document classification scope
- What it does: Chooses whether Marintel's AI reads submissions against the full maritime taxonomy (vessel tenders, class and statutory documents, yard forms) or a general procurement taxonomy for non-vessel packages. Data rooms are always maritime; this switch exists only for procurement.
Sealed bids (optional, and permanent for the room)
- What it does: When on, every bidder submission is sealed at the moment it is uploaded — no one, not even a workspace admin, can open it until two administrators jointly unseal the room. This is a decision made at creation because it changes the meaning of every document uploaded afterwards. See Sealed Bids.
Stage 2 — Inviting bidders
You invite a bidding organisation first, which creates its isolated section, then invite named users into that section by email.
Bidder sections
- What it does: Each organisation you add gets a private section keyed to its name. Documents, questions, and submissions that organisation creates are stamped to its section and are visible only to it and to the Issuer.
- Why it matters: A bidder is never given ordinary room membership — that would make it Issuer-side and able to see the field. Bidder access flows only through section membership, which the server checks on every query.
Section-pinned invites
- What it does: A bidder invite is an email invite pinned to one section with a role (bidder admin or bidder user). Accepting it grants section membership only — the invitee lands on their bidder home, sees the rooms they are invited to, and opens a sanitised room view that shows the stage, the deadlines, and their own section.
Issuers can also upload a document on behalf of a bidder — for a bid that arrived by email or courier. Marintel badges it "Loaded by Issuer" so provenance stays honest.
Stage 3 — Questions & Answers
Once the package is published, bidders can ask questions. Q&A is the most confidentiality-sensitive surface in a tender, and Marintel is built to protect it.
Room-wide numbering
- What it does: Every question gets a sequential, room-wide number (Q-001, Q-002…) allocated the instant it is posted, in submission order across all bidders. Numbers never collide and never leave gaps that need explaining.
Three ways to answer
- Publish (anonymised): The answer, and a re-authored version of the question, go to every bidder. The whole field benefits from one clarification without learning who asked.
- Private: The answer goes only to the asking bidder.
- Decline: The question is closed without an answer, on the record.
The verbatim-quote guard
- What it does: When you publish, Marintel checks that your re-authored question does not quote the bidder's original wording verbatim — because distinctive phrasing can identify the asker to competitors. If it detects a verbatim quote it warns you and blocks the publish until you re-author it or explicitly accept the risk.
Triage & assignment
- What it does: Pull a fresh question into "under review" and assign it to a colleague, so a busy Q&A queue shows who is working what before answers go out.
Addenda — formal package changes
When the package itself changes — a revised spec, a corrected drawing, a moved deadline — you issue a numbered addendum rather than an informal note.
Numbered, simultaneous, acknowledged
- What it does: Addenda are numbered (ADD-001, ADD-002…) and publish to every bidder section at the same moment — no bidder gets early sight. You can attach a notice document from the package area, and optionally extend the submission deadline in the same action. Each bidder acknowledges receipt, and you see acknowledgement status per section so you can chase anyone who has not confirmed.
- What bidders get: A notification when an addendum lands, and a one-click "Acknowledge receipt". A bidder only ever sees its own acknowledgement state, never another section's.
Stage 4 — Submission & deadlines
Submit & lock
- What it does: A bidder assembles its documents, then submits and locks its response. After locking, no further uploads land in that section — the response set is fixed. The Issuer sees which organisations have submitted.
Audited reopen
- What it does: If a bidder needs to correct a genuine error, an Issuer Admin can reopen its submission. The reopen is recorded on the audit chain with the timestamp of the lock it lifted, so any post-deadline change is attributable.
Late bids — accepted and flagged
- What it does: A submission or upload after the deadline is never silently refused. It is accepted and flagged
lateso the Issuer sees the flag on every late document and a post-deadline lock is marked late in the audit trail. Whether to consider a late bid remains the Issuer's decision — Marintel records the fact rather than making the call.
Sealed Bids
For tenders that demand it, sealed bids give you a provable "no early access" guarantee — the digital equivalent of a locked bid box opened in front of witnesses.
How sealing works
- At intake: In a sealed-bid room, every bidder-section upload is sealed the moment it arrives. Marintel does not classify, extract, render, or index a sealed document — so no derived data about a bid exists before it is opened. The Issuer's own package area is never sealed.
- Access: While sealed, only members of the owning bidder section can open the document. This is the one place in Marintel where a workspace admin does not have access — the seal check runs before the admin bypass, on both the document and the raw file routes.
The two-administrator unseal
- What it does: Opening the bids requires two different Issuer Admins. The first records an unseal request; a second, distinct admin confirms it. Only then are the documents unsealed — atomically — and released into the AI pipeline for classification and extraction.
- Why it matters: Because nothing is classified, viewed, or indexed while sealed, "no access before the opening" is provable from the absence of any such event between the seal and the unseal on the audit chain — not merely asserted.
Stage 5 — Evaluation & Award
Evaluation is Issuer work product. Bidders can never see scores, the rubric, the comparison, or even that an evaluation surface exists.
The weighted rubric
- What it does: Define your criteria and their relative weights — for example Technical (weight 2) and Price (weight 1). Weights are relative, so 3/2/1 and 30/20/10 score identically.
Independent scoring, reconciled
- What it does: Each evaluator scores each bidder against each criterion, 0–100. Marintel averages across evaluators per criterion and computes a rubric-weighted total, so a panel's independent judgements become one comparable number per bid. Re-scoring updates in place; the audit chain keeps the history.
The comparison matrix
- What it does: A single grid of bidders against criteria — average score per cell, weighted total per bidder, and each section's document count — so you compare like for like at a glance.
Recording the award
- What it does: Record the winning bid with a written rationale. There is one award per room; recording it moves the room to the Award stage. The decision — and every action that led to it — is written to the tamper-evident audit chain.
The Audit Trail
Every consequential action in the room — publish, invite, upload, question, answer, addendum, acknowledgement, submission, reopen, seal, unseal, score, award — is written to an append-only, cryptographically chained audit log. That record is what lets you answer a regulator or a losing bidder with evidence rather than recollection:
- Fairness: The package published to every bidder at the same moment; addenda reached the whole field simultaneously.
- Confidentiality: No cross-bidder access occurred; on sealed tenders, no bid was opened before the two-admin unseal.
- Diligence: Who scored what, when, and the rationale on which the award rests.
What Marintel gives you
| Capability | What you get |
|---|---|
| Hard bidder isolation | Server-enforced private sections; no bidder can see or infer another. |
| Sealed bids | Seal at intake, no derived data pre-unlock, two-administrator opening. |
| Anonymised Q&A | Room-wide numbering, publish/private/decline, verbatim-quote guard, triage. |
| Numbered addenda | Simultaneous publish, acknowledgement tracking, deadline extension. |
| Submission control | Submit-and-lock, audited reopen, accept-and-flag late bids, deadline reminders. |
| Weighted evaluation | Rubric, multi-evaluator averaging, weighted comparison matrix. |
| Auditable award | One award per room, written rationale, tamper-evident chain. |
| AI on every submission | Maritime or general classification and extraction the moment bids open. |
Common failure modes
A question reveals who asked
An Issuer publishes a clarification using the bidder's own distinctive wording, letting rivals guess the source.
How Marintel prevents it: The verbatim-quote guard blocks a publish that quotes the original, forcing a re-authored, anonymised question first.
A bid is seen before the opening
On a sealed tender, someone with admin rights peeks at a submission early, tainting the process.
How Marintel prevents it: Sealed documents are inaccessible even to admins, and generate no derived data, until two different administrators jointly unseal — provable from the chain.
A late bid causes a dispute
A bid arrives after the deadline and the parties disagree on whether it counts.
How Marintel prevents it: Late submissions are accepted and clearly flagged rather than silently dropped, so the fact is on the record and the Issuer's decision is documented.
A bidder misses a package change
A supplier bids against a superseded spec because it never saw the revision.
How Marintel prevents it: Addenda publish to every section at once, notify bidders, and require acknowledgement — with per-section status so the Issuer can chase anyone who has not confirmed.