For an OEM parking-equipment order, approve more than the logo. Define the changes, the software and documents to be delivered, the uses your business needs permission for, and the exact sample configuration that bulk production must follow. Then agree how later substitutions and software updates will be reviewed.
A cabinet can look identical while carrying a different controller, firmware build or interface behaviour. A demonstration account can work while leaving branded distribution or independent maintenance unresolved. A useful OEM approval therefore connects three things: a defined scope, an identifiable sample baseline and a controlled route for changes.
Turn “customized” into a deliverable list
Start with the base product and the markets where it will be sold. State whether the request covers a barrier, ANPR camera, display terminal, payment station or a combination. Separate existing options from new development, and ask the supplier to mark each item as included, optional, unavailable or supplied by another party.
Use this matrix as a starting point. Add a reference file or revision, an approval owner and a quotation status to every requested change.
| Scope | Define before sample production | Approval evidence |
|---|---|---|
| Cabinet and branding | Model, colour reference, finish, artwork, logo position and permitted use of the brand assets | Approved drawing or artwork revision and an identified physical sample |
| Screen and language | Translation file, fonts, screen states, error messages, units and who supplies the wording | Approved files and screenshots from the agreed software build |
| Functional behaviour | Required workflow, settings and exceptions; distinguish a changed function from a changed label | Agreed scenarios, expected results and recorded sample results |
| Interfaces | Protocol, API or SDK version, event fields, supported configuration and integration owner | Versioned documents and results with the intended counterpart system |
| Packaging and labels | Carton artwork, model naming, serial traceability, contents and destination-specific label responsibilities | Approved artwork, packing list and sample packaging |
| Documents and service | Manual language, diagrams, spare-part references, update information and support handover | A versioned delivery-file list with a named owner for missing items |
Record tooling, one-time development, sample charges, recurring licence charges, minimum quantities and lead times against the agreed scope. Ask who controls the tooling and design files, whether any exclusivity is offered, and which products, markets or period it covers. Do not leave these decisions inside a general phrase such as “OEM service included.”
Confirm software deliverables and permitted uses separately
A software file, an administrator account and a permission to distribute software answer different questions. For each application, firmware package, SDK and required runtime, ask for the applicable terms and the deliverables needed by your own team and downstream customers.
- Operate and install: which products, customers and deployment arrangements may use the delivered version? Who provides activation, recovery and replacement-device access?
- Brand and distribute: may you use your name in the interface, installer, manuals and customer package? Which files may be passed to customers or local installers?
- Integrate: what SDK, API documentation, examples and runtime files are supplied, and which of them may be redistributed? Who maintains the integration when either side changes?
- Modify and maintain: is source code included, what may be changed, and who can build and support the modified version? If independent maintenance is required, identify the agreed build instructions, dependencies and handover materials.
- Third-party components: request the relevant component/version and licence information, notices and any required source material or offers. Confirm restrictions and delivery duties for the actual components used.
Receiving source code does not itself make a product open source. The Open Source Initiative’s definition also addresses redistribution and modification permissions. Establish the actual terms for the delivered package rather than assuming that a customization payment, source access or a new logo settles every permission.
Keep the supplier’s existing technology, buyer-supplied artwork and newly commissioned work identifiable in the agreement. If ownership, exclusivity or independent future development matters to the business, specify the deliverables and intended rights for review before approving development. For the wider discussion of licence limits, upgrades and recurring charges, use the parking software licensing checklist.
Approve a reference set, not just a showroom sample
Give the sample a unique reference and record its physical identity. Link it to the approved drawings, artwork, hardware configuration, firmware/software build and settings. Include the versions of interface documents, manuals, labels and packaging that belong with it. Keep a dated approval record linking these files to the sample identifier. Where a detailed bill of materials cannot be shared, agree which critical component identifiers and changes must remain traceable.
Keep the results beside that configuration. A video showing a cabinet opening or a translated screen is useful evidence of that demonstration, but it does not describe every required workflow or prove that every production unit will match. Select checks from the agreed customization: for example, long translated messages on the actual screen, the specified event fields with the intended software, and the approved model naming across labels and manuals.
Make the release decision explicit: approved for production, approved with listed conditions, or not released. Each open item needs an owner, required evidence and a closure point. A cosmetic deviation accepted for one sample should not silently become permission to change the entire order.
This compact record can be added to the purchase documentation. The entries below are fields to complete, not a finished approval.
OEM sample approval record Order / product / sample identifier: Hardware and critical components: Firmware / application build / settings: Artwork / interface documents / manual / packaging revisions: Agreed checks and result-file references: Open items / permitted deviations / closure owners: Release decision / approvers / date: Bulk order or lots covered by this approval:
Give changes a route from request to release
Freezing a baseline means keeping an agreed reference, while managing later updates. It should not prevent necessary security fixes or make an unavailable component impossible to replace. Agree which changes need notification, which need approval before production, and how urgent updates will be handled.
For a proposed change, record the reason, old and new identifiers, affected products or lots, and the effect on function, fit, interfaces, branding, documents and service. Name the person who decides whether a new sample or a narrower check is needed. Record the resulting decision and the first delivery to which it applies.
For example, a proposed replacement controller may leave the cabinet appearance unchanged while affecting event timing, configuration recovery or a service procedure. Check the affected behaviours with the intended configuration before accepting it as equivalent. A carton spelling correction usually needs an artwork and packing-document review, rather than repeating unrelated functional tests. The evidence should follow the consequence of the change.
Record an accepted deviation with its specific scope, affected quantity or lots and conditions. Keep it separate from a permanent baseline revision. Otherwise, a one-order exception can become an undocumented standard on the next shipment.
Connect bulk delivery to the approved version
Agree how incoming units will be traced to the released configuration. Match order references, serial or lot records, relevant hardware/software identifiers, labels and delivered files. Set the incoming inspection or sampling plan with the supplier according to the order and its risks; one approved sample is not a substitute for that plan.
If there is a mismatch, identify and hold the affected scope while the responsible parties decide whether to correct, replace or accept it under a documented deviation. Record what was actually delivered and approved before releasing those units for the next stage. Keep the final configuration information available to the service team, including compatible spares and the route for future software updates.
Prepare a focused OEM enquiry
SHUNJIE publicly offers OEM/ODM customization across appearance, functions, language, software and system integration. Treat that offer as the starting point for a product-specific discussion: the ANPR camera range, for example, lists housing and colour customization. The requested software deliverables, permissions, sample process, cost and schedule still need to be agreed for the order.
Send the base product, sales markets, quantities, branding files, languages, required workflows and integration versions, together with the uses your software agreement must cover. Ask for a response against the scope matrix and a proposed sample-approval and change process. You can then discuss an OEM project with SHUNJIE using one defined reference for the quotation, sample and bulk delivery.
Featured image: AI-generated OEM planning scene. The generic equipment and review materials do not depict a SHUNJIE factory, approved sample, audit or test.
Featured image: AI-generated OEM planning scene. The generic equipment and review materials do not depict a SHUNJIE factory, approved sample, audit or test.
