Security Camera Sample Approval Checklist for Brands and Distributors

A sample is evidence, not yet an order specification

A desk test is not an order specification. Before a U.S. distributor, private-label buyer or system integrator approves a security camera sample, tie the physical unit, complete model, software, accessories and test evidence to the same version. That record makes the next quotation or pilot discussion easier to review—and makes later changes visible.

Use this guide as a buyer-side sample record for a quotation or pilot discussion. It does not replace the supplier’s written confirmation of model, firmware, accessories, commercial terms or project responsibilities.

1. Freeze the complete model identity first

Record the full orderable model and every suffix shown on the sample, label, public product page and RFQ. Keep a sample ID or serial number beside that model. A photograph of the housing, ports and included accessories is useful evidence, but it does not replace the model label or the software information.

Similar names should remain separate until the selling version is matched. Do not combine fields from a sibling model because the housing looks similar. If a hardware revision is not visible, ask the supplier how it is identified and leave the revision as an open item until the answer is documented.

For a multi-lens camera, record lens count, per-view resolution and simultaneous-view behavior as separate fields. A lens count alone does not prove a combined resolution or a particular recording mode.

2. Record hardware and software as different evidence

Use one row for each value and attach the evidence file and test date. The following headings work well in a sample sheet.

Physical identity

Record the complete model and suffix, sample ID or serial number, hardware revision where available, label photographs, visible connectors, mounting parts and included accessories. Note which items were physically present rather than assuming that a family page lists every accessory.

Power and network

Write the device input rating, connector and the actual adapter output separately. Record the network used in the test, such as 2.4 GHz Wi-Fi, RJ45/LAN or another documented option. A plug that fits is not evidence that the adapter is the correct output for the ordered device.

Imaging and movement

Write the resolution and lens or view used in the test. If the model supports pan, tilt, zoom or a manually adjustable lens, record the control method and the condition under which it was checked. Keep a fixed view separate from app-controlled movement in the record.

app, platform and recording

Name the app or platform listed for the supplied version, its build or version if visible, the phone operating system used, account role, recording destination and playback method. Record cloud or subscription conditions only when they are documented for the configuration. Keep passwords and access tokens out of the shared evidence folder.

Packaging and documents

List the specification revision, quick-start material, manual language, packaging artwork and accessory list that were actually supplied. Mark branding, firmware, app identity and packaging changes as project discussion items until the selected scope is confirmed in writing.

3. Turn “looks good” into a repeatable check

Write the condition and acceptance criterion before testing. “The video looks good” cannot tell a supplier what passed or what another reviewer should repeat.

• View: identify the scene, camera position, lighting and video settings. Save a representative clip or still and state the detail the buyer needed to see.
• Movement and audio, where supported: identify the control used, expected response and observed response. Separate manual lens adjustment from app-controlled movement.
• Recording and playback: identify the destination and account or service condition. Check retrieval as well as live viewing; one does not prove the other.
• Network recovery: document the agreed reconnect or restart check and its result. Do not infer long-term reliability from a short desk test.
• Accessories: match the supplied adapter, cable, mount and packaging list to the version being quoted.

Choose a test duration and sample quantity appropriate to the project. A successful check on one unit does not establish a production defect rate. Keep pilot or shipment-inspection acceptance criteria separate from the individual sample record.

4. Match compatibility evidence to the version tested

If a project requires integration or interoperability, name the receiving recorder or software, its version and the exact functions required. A generic compatibility label is not a substitute for checking the requested combination.

For an ONVIF conformance claim, the official ONVIF process ties conformance to a registered product firmware or software version. Use the ONVIF conformance guidance and official conformant products database to check the exact product and profile. This is a verification method; it is not a claim that a SightSys model has that conformance.

Axis documentation is a useful industry example of keeping product number, hardware ID, serial number and software version as separate device properties. It should be read as an example of record structure, not as a claim about SightSys interfaces: Axis device setup documentation.

If a required function, supported version or document is unclear, make it an open acceptance item. Avoid writing “compatible with everything” into an order specification or product page.

5. Use a scoped acceptance decision

The decision should name the exact configuration it covers. These labels are practical recordkeeping choices, not a certification scheme.

1. Accepted for the recorded configuration. The agreed checks passed and evidence is attached. Name the model, suffix, sample ID and software condition.
2. Accepted with a named exception. State the exception, its effect, the person accepting it and any restriction. Keep the exception visible in the RFQ and sample record.
3. Hold for correction or evidence. State what must change or be supplied, who will respond and which checks must be repeated.

If the buyer and supplier use an approved reference unit, record its keeper, sample ID and linked specification revision. Agree separately whether sample acceptance permits a pilot order, a production order or neither. A sample sign-off should not silently become shipment approval.

6. Reopen affected checks after a change

Ask for a change list before accepting a substitute or revised sample. Compare it with the recorded configuration and agree the affected retests.

• Firmware or app change: review release information and repeat setup, permissions, recording and playback checks that could be affected.
• Adapter, cable or connector change: confirm the device requirement and replacement accessory specification before use.
• Lens or imaging change: revisit field of view and image checks under the recorded scene and lighting.
• Label or packaging change: recheck model, accessory list and artwork against the orderable configuration.
• Platform or service change: identify which account, cloud or support condition applies to the ordered version.

Retain the earlier result under its original build and sample ID. Open a second record for a revised sample, note what changed and attach the retest. This prevents an accepted historical result from being mistaken for evidence about an untested version.

7. Copy this practical checklist into your RFQ file

For every line, record the observed result (pass, exception or hold), the evidence file or link, the responsible owner and the date. If a field is not available, mark it open instead of filling it from a similar model or family page.

• Complete model and suffix, sample ID and hardware revision
• Label, housing, ports, mount and accessory photographs
• Device input, connector, adapter output and cable details
• Network used in testing and the expected installation network
• Resolution, lens/view, movement control and lighting conditions
• App/platform name, build, account role and recording destination
• Playback/retrieval result and representative evidence file
• Manual, packaging, artwork and language requirements
• Required interoperability profile and the receiving recorder/software version
• Open exceptions, owner, response date and affected retests
• Specification revision and decision status
• Target market, buyer type, project quantity and timing for the RFQ

Keep the decision status, exceptions, evidence references and retest owner with the record. This lets a second reviewer tell what passed, what remains open and which version the result applies to.

Bring the record into a SightSys project discussion

Start with the exact model page rather than a shortened family name. The public SHM-MQ81M13EA product page is one model-specific starting point; confirm the proposed sales configuration in the inquiry instead of assuming a page captures every project option. Buyers can also compare the Indoor Security Cameras collection and the Outdoor Security Cameras collection before selecting a sample.

For branding or project requirements, review the SightSys OEM / ODM process and the OEM / ODM discussion page. In the request for a quote, include the complete model, destination market, intended use, requested sample quantity and the questions your evaluation needs to answer. Sample availability, customization scope, commercial terms and approval responsibilities remain specific to the project and should be confirmed in writing.

References

This guide links to public SightSys category, OEM / ODM and RFQ pages, plus external ONVIF and Axis documentation used as verification references. ONVIF and Axis are examples of source documentation and record structure; they do not establish a SightSys certification, interface or compatibility claim. Model-specific specifications, commercial terms and project responsibilities remain subject to written confirmation.