Most disputes between terminals and port automation companies trace back to a requirement nobody wrote down. Accuracy gets defined loosely, exception handling is never specified at all, and acceptance criteria are negotiated after deployment when the terminal has lost all leverage. This checklist gives you the clauses that matter, in the order they should appear in a tender.

Key Takeaways

• An accuracy percentage means nothing without a defined measurement method, sample size and adjudication process supplied by you rather than the vendor.
• Exception handling deserves as much specification as recognition itself, because a system that refers too much traffic to humans has not automated anything.
• Acceptance criteria must be agreed before signature. Afterwards, the terminal has no leverage left to negotiate what counts as success.

Section One: Scope and Physical Requirements

Open the tender by fixing scope, because every later section depends on it and because unfixed scope is the reason quotes arrive incomparable.

State lane count, capture points required per lane, and exactly which data elements must be read, covering container code, ISO code, size and type, and vehicle plate where required. Be explicit that these are separate captures rather than one, since that assumption is where quotes most often diverge.

Specify your existing camera inventory and state whether vendors may assume reuse. Require each vendor to declare what camera hardware their proposal assumes, because this is the single largest cost swing between bids and it is frequently buried. The nine cost variables provide the full scoping structure to attach as an appendix.

State clearly whether the scope is fixed or indicative, and if phased deployment is intended, say so and describe the phases. Vendors price risk, and a vendor who suspects the scope will expand will either pad the quote or accept it knowing a variation is coming. Neither serves you well, and both are avoided by describing the full intended programme even where only phase one is being bought.

Section Two: Accuracy and Measurement

This section prevents more disputes than all the others combined. The critical move is counterintuitive: do not ask vendors for an accuracy percentage.

Instead, supply the measurement method yourself and ask each vendor to state their accuracy against it. This way every bid is measured identically and the numbers become comparable for the first time. Specify the test sample size, the period over which it is collected, whether the sample includes night traffic and adverse weather, how a disputed read is adjudicated, and what remedy applies if the target is missed.

Require separate figures for read accuracy and for exception rate, because the two can be traded against each other and a vendor quoting only the first is telling you half the story. Docker Vision publishes more than ninety five percent accuracy, and the useful conversation with any vendor begins by pinning down what such a figure means in your conditions. The accuracy service level guide covers how to construct this section properly.

Include a worked example of the calculation you intend to apply so there is no ambiguity about method. Two parties can agree on whole code accuracy and still disagree about whether a container presented twice counts once or twice, or whether a read corrected within seconds counts as a failure. Ten lines of worked example prevent months of argument later.

Section Three: Integration and Data

State your terminal operating system and its version, then require vendors to describe the integration method rather than simply confirming compatibility. Compatibility is a claim. A field list is a commitment.

Ask which fields are written back, in what format, at what frequency, and what happens when the operating system is unavailable. Require a description of the exception workflow covering who sees a low confidence read, what they see alongside it, and how the correction is recorded and fed back into retraining.

Ask whether images are retained and for how long, because this determines whether you can support a damage claim raised months after a container left. The TOS integration overview shows what a complete answer to this section looks like in practice, including how a read travels from camera to operating system.

Ask specifically what happens to data if the relationship ends. Who holds the images, in what format can they be exported, and how long does the vendor retain anything after termination. This is straightforward to agree at tender stage and awkward to negotiate afterwards, particularly with port automation companies whose platform stores operational history you may later need.

Section Four: Deployment, Security and Acceptance

Require the deployment model to be stated explicitly, covering whether processing happens on site or externally and where operational data comes to rest. Many terminals have a hard requirement that data stays inside the perimeter, and specifying it upfront costs nothing while retrofitting it later costs a great deal. The on premise deployment analysis covers the reasoning.

Close with acceptance. Define the criteria, the test period, who signs off, and what happens if criteria are not met. This is the clause terminals most often leave until after deployment, and it is the one they most regret leaving.

Ask vendors to state their implementation timeline and, far more usefully, what must be true on site before that clock starts. Docker Vision states two days to implement and go live, and the same question should be put to every bidder so the answers are comparable rather than rhetorical. The existing guide to questions to ask a port automation company complements this section well.

Define what happens between conditional and final acceptance as well. Many disputes occur in that gap, where a system is live and being used but has not formally passed, and payment milestones are unclear. State whether operational use constitutes acceptance, because if you do not, a vendor may reasonably argue that it does.

How to Run the Evaluation Itself

A good document still produces a poor outcome if the evaluation process is loose. Three practices make the difference.

Invite enough vendors for genuine comparison, typically three to five, and require all of them to price against an identical fixed scope. More bids against loose scope produce less useful information rather than more. Score the responses against written criteria agreed before the bids arrive, so that a persuasive presentation cannot displace a weaker technical answer.

Ask every vendor the same set of probing questions and compare the answers side by side. How is accuracy measured. What is the exception rate separately. What must be true before go live. How are low confidence reads handled. Which fields are written back. Where is data processed. How long are images kept. How is the model retrained. Vague answers to any of these indicate limited real deployment experience, which is far more informative than any reference list. Industry publications such as Port Technology International and the PEMA member directory are useful for building a credible longlist before you start.

Keep a written record of every clarification issued and ensure all bidders receive the same information at the same time. Beyond fairness, this protects the comparability you worked to establish in the scope document. A single clarification given to one bidder informally can invalidate the like for like comparison the entire process was designed to produce.

Finally, involve the people who will operate the system in the evaluation itself. Gate supervisors spot practical problems that procurement teams miss, such as an exception screen that cannot be read in daylight or a workflow that assumes staffing you do not have. Port automation companies presenting to an audience that includes actual operators tend to give more grounded answers, and the resulting decision carries far more support once implementation begins.

Conclusion

A good tender does not simply collect prices from port automation companies. It defines the terms so precisely that the prices become comparable and the obligations become enforceable. Fix scope, supply your own accuracy method, specify exception handling, and agree acceptance criteria before signature rather than after. To discuss how a proposal maps to this structure, contact the Docker Vision team.

Frequently Asked Questions

What should a port automation RFP include?

Scope and physical requirements, an accuracy definition with measurement method, integration and data requirements, deployment and security terms, and acceptance criteria agreed before signature.

How do we compare accuracy claims between vendors?

Supply your own measurement method rather than accepting each vendor’s. Specify sample size, conditions including night and weather, and adjudication so every bid is measured identically.

What is an acceptable exception rate?

It depends on your traffic, but require it quoted separately from accuracy. A system hitting a high accuracy figure by referring much of the traffic to humans has not automated the task.

Should we specify where data is processed?

Yes, explicitly. On site processing keeps operational data inside the terminal perimeter and reduces latency. Specifying it upfront is far cheaper than changing it after deployment.

When should acceptance criteria be agreed?

Before signature, always. Once a system is deployed the terminal has very little leverage to negotiate what counts as successful delivery.

What questions reveal a weak vendor?

Ask what must be true on site before their timeline starts, and how low confidence reads are handled. Vague answers to either indicate limited real deployment experience.

Should the RFP require image retention?

Yes, with a stated period. Retained gate images are what allow a terminal to defend a damage claim raised months after the container left the facility.

How many vendors should be invited?

Typically three to five, provided all price against an identical fixed scope. More bids against loose scope produce less useful information, not more.

Does the RFP need to specify camera models?

Specify requirements and your existing inventory rather than models. Requiring vendors to declare their hardware assumptions exposes the largest cost difference between proposals.