Reverse Vending Machine Tender Specification Guide

Build an RVM request for proposal that compares tested packaging, site fit, software, service, acceptance and commercial exclusions on the same basis.

Illustrated RVM procurement scope covering equipment, software and service

An RVM tender becomes hard to compare when one bidder quotes a cabinet, another includes software, and a third assumes the site will handle collection. Give every supplier the same packaging samples, site conditions and response format. Require each answer to identify assumptions and exclusions.

State the project’s boundary

Describe the number and type of sites, accepted container programme, expected users and material destination. Include floor plans, available utilities, operating hours and named collection owner. Label unknowns as questions to be resolved in a survey, not as facts suppliers can silently assume.

A useful brief also says why the return point exists. A retailer may want a convenient customer journey; an operator may need a standard network record; a brand may need programme-level evidence. These goals can coexist, but each changes the acceptance criteria. State which decisions are already fixed and which bidders may propose alternatives for. Otherwise a lower price may simply reflect a narrower interpretation of the job.

Ask for evidence in six sections

Tender section Request from each bidder
Equipment Exact proposed configuration, drawings, service clearances and options
Packaging Tested sample list, acceptance conditions, rejects and change procedure
Site Utility requirements, environmental limits and installation responsibilities
Software Roles, data fields, offline behaviour, export and interface boundary
Operations Collection, cleaning, training, spare parts and fault escalation scope
Commercial One-time and recurring items, exclusions, dependencies and support term

Ask for performance or capacity figures with their container mix, test method and configuration. A supplier may legitimately propose different options for different sites; require the reason and the operational consequence of each option.

Require an exceptions schedule

Give bidders a place to list deviations from the brief line by line. Ask them to mark a requirement as included, offered with a named option, dependent on the customer or not supported. A statement such as “integration available” is incomplete until the systems, data fields, authentication and test responsibilities are named. Likewise, “service included” should identify the geography, hours, response route and tasks covered by that service.

Request a versioned packaging acceptance list with sample IDs and conditions. If a new bottle format appears after installation, the tender should say how it will be assessed and who approves an update to signage and rules. This turns future change into a manageable process rather than an argument about what “bottles and cans” originally meant.

Make acceptance observable

Specify a test with representative accepted, rejected and damaged packaging. Include a full-storage event, a network interruption where relevant, collection handover and staff training. Define what constitutes pass, correction or unresolved exception, who signs the record and what evidence will be retained. The pilot acceptance guide turns these headings into a site test.

Run the acceptance plan with the proposed operating team present. A supplier can demonstrate a normal return in isolation while a store manager discovers later that no one can remove the full container through the agreed route. Include a visitor-facing instruction check, a collection exchange and a fault escalation exercise. For connected projects, compare a physical accepted item with the record received by the customer system; do not rely only on a screenshot of the supplier dashboard.

Compare the whole operating responsibility

Put each proposal’s inclusions and exclusions in a common matrix. Where a subscription or service price is quoted separately, record which tasks it covers. Do not turn a blank line into a zero cost: ask who will do the work and under what term. The cost-scope guide helps build a comparable budget.

Evaluate answers, not adjectives

Before bids arrive, decide how the review team will score site fit, accepted packaging, operational workload, software evidence, service scope and total cost. Give a reviewer the source for each score: a drawing, test record, contract schedule or demonstrated workflow. Words such as “intuitive” and “future-proof” are not evidence until they are tied to an observable user task or a defined upgrade boundary.

If two proposals differ materially, arrange a clarification round using the same questions for both. Record the revised assumption and price alongside the original response. That small discipline protects procurement from comparing unlike offers after the evaluation has started.

If you want RECYNEX to respond, send the site pack and sample list with the requested response date and decision criteria. Request a scoped proposal for equipment, Cloud and support that can be evaluated together.

Related stories

Turn your site brief into a configuration

Share the location, container stream, operating team and systems already in place.