The short answer: do not send a USB-C docking station OEM a port list and ask for a price. Send a host matrix, display matrix, power budget, shared-bandwidth map, test conditions, and pass criteria.

Here, OEM refers to a brand commissioning a supplier to manufacture a dock against an agreed product specification. This is not a guide to buying a laptop maker's branded replacement dock.

That difference matters. A request such as “four displays, 100 W PD, 10 Gbps USB, and 2.5GbE” looks specific, but it leaves the engineering questions unresolved. Which four displays can run together? On which host and operating system? Is 100 W the adapter input or power delivered to the laptop? Which ports share one upstream link? What happens after sleep, hot-plug, or a firmware change?

This checklist draws on two PURPLELEC project packets. Together, they include engineering specifications, test requests, production test instructions, and structured validation records for power, data, display, network, audio, host compatibility, and thermal aging. Both test request forms state that the supplied sample represents only the current validation result. In practice, a result must stay attached to its sample revision and recorded test conditions; it cannot be generalized to every host or later revision.

1. Start with the workload, not the connector count

Before selecting a dock architecture, describe the system in which it must work. At minimum, the project brief should name:

The host-port field cannot be reduced to “USB-C.” USB-IF states that USB Type-C is a connector specification, not a synonym for USB 3.2, USB4, or USB Power Delivery. Manufacturers may implement those capabilities, but the connector alone does not require them. The distinction is explicit in the USB-IF Type-C language and packaging guidance.

For video, confirm whether every target host supports DisplayPort Alt Mode, USB4, or Thunderbolt as required by the proposed dock. VESA explains that DisplayPort, USB data, and power can share a USB-C connection when the source, dock, and cable support the required functions. It also advises checking the device documentation rather than assuming that every Type-C port carries video. See the VESA DisplayPort FAQ.

2. Specify the architecture before assigning ports

Require the proposal to name the upstream protocol and include a functional block diagram. Mark every path that shares bandwidth, power, or a display pipeline.

Ask the supplier to classify the proposed design:

• Native DisplayPort Alt Mode dock
• USB4 dock
• Thunderbolt dock
• DisplayLink-enabled universal dock
• Hybrid design using more than one display path

A DisplayLink-enabled design adds a software deployment path that a native DP Alt Mode dock does not. Synaptics provides DisplayLink Manager to enable supported DisplayLink docks and displays on macOS, so an enterprise RFQ should state who packages, approves, updates, and supports the required software. The current software is available from the official DisplayLink macOS download page.

Part numbers alone are insufficient. Topology, firmware, and thermal design define the implementation; product-level validation and compliance evidence bound the claims that can be published.

3. Make the display matrix the source of truth

“Two HDMI plus two DisplayPort” does not necessarily mean four independent video streams. A connector may be an alternative output for the same display group. The host GPU, operating system, DP lane allocation, DSC support, MST behavior, conversion path, and cable can also change the result.

For each supported combination, record:

One reviewed PURPLELEC specification maps multiple DisplayLink HDMI and DP connectors to shared display groups. Within each group, HDMI and DP are alternatives, not simultaneous outputs. A buyer who copied only the connector count could overstate the number of independent displays. The RFQ therefore needs an activation rule for every video connector.

4. Write a power budget with three separate numbers

Do not use one PD wattage to describe the whole dock. Keep these values separate:

1. Power accepted from the external adapter
2. Guaranteed host-charging output under the defined simultaneous load
3. Power available to each downstream port, including the simultaneous-load condition

USB PD 3.1 can deliver up to 240 W over an appropriate full-featured USB Type-C cable and connector, according to USB-IF's Power Delivery overview. That is a protocol ceiling, not evidence that a particular dock, adapter, cable, or host supports 240 W.

In one reviewed PURPLELEC packet, the engineering specification records DC adapter input, host charging with a project-specific power-reservation condition, and per-port downstream current as separate values. They describe different points in the power path and cannot be collapsed into one marketing number.

In the other packet, the Type-C auxiliary input has its own minimum requirement. The engineering notes require auxiliary power when all interfaces are loaded or a high-power USB device is attached because display output or device recognition may otherwise fail. That limit applies only to the recorded design, but it exposes the RFQ question every project must answer: what remains stable under full simultaneous load?

For acceptance, define the adapter, cable, host battery state, connected peripherals, measured host power, downstream loads, test duration, and allowed temperature or performance change.

5. Treat bandwidth as a shared topology

Peak labels on downstream ports cannot simply be added together. Several 10 Gbps ports, Ethernet, card readers, audio, storage, and a display path may share one upstream link or controller. Protocol overhead, host behavior, and simultaneous traffic affect application throughput.

Request these items before sample approval:

• Upstream link type and negotiated rate
• Controller and hub topology
• Ports that share the same downstream controller
• Display paths that consume or tunnel across the upstream connection
• A simultaneous-load test using the peripherals that matter to the project
• Pass criteria for sustained storage, network, video, and device-enumeration behavior

If the project requires a minimum file-transfer or network result, define the test tool, file size or traffic profile, storage device, host, OS, cable, duration, and acceptable range. “Up to 10 Gbps” is a signaling label, not a measured file-copy promise.

6. Specify Ethernet, audio, storage, and thermal behavior

A dock can pass its headline display and charging checks while failing the buyer's actual workflow. Define these supporting functions when they matter:

• Ethernet: controller, advertised link rates, driver source, sleep/wake behavior, PXE or MAC-address requirements, and sustained traffic test
• Card reader: SD or microSD standard, supported media, simultaneous access behavior, and target workload
• Audio: input/output routing, sample format, headset standard, mute and volume behavior
• Storage: NVMe or SATA support, key type, drive sizes, capacity boundary, RAID or enclosure behavior, and safe-removal handling
• Human interface: power button action, LED states, cable orientation, port labels, and recovery after power loss
• Thermal behavior: sensor location, fan policy if used, surface-temperature limit, throttling rule, and the agreed full-load condition

Treat an ambiguous label as an open engineering question. Confirm the standard, unit, component documentation, and sample behavior before putting it in the RFQ or product page.

7. Lock firmware, identity, and change control

Two samples with the same enclosure can behave differently when the controller revision, firmware, EEPROM, cable, or power design changes. The approved configuration should therefore include:

• Bill-of-material boundary and approved alternates
• Controller and firmware versions
• USB VID/PID, product string, serial-number behavior, and required branding permissions
• Firmware update and recovery method
• Version-readout method for incoming inspection and support
• Notification and revalidation rules for component, PCB, firmware, cable, adapter, or enclosure changes

If remote firmware update, signed packages, fleet deployment, or rollback is required, state it as a requirement. Do not assume it exists.

8. Ask for product-level compliance evidence

Compliance must be mapped to the final SKU, target market, adapter, cable, enclosure, labeling, and brand owner. A chipset certificate or a company-level management-system certificate does not prove that the shipping product passed a product test.

For USB branding, USB-IF states that a company may use certified USB logos only when the product is listed on the Integrators List under that company's name and the company has a current Trademark License Agreement. Its compliance program page also describes the permitted OEM arrangement process. Ask which pathway, listing, and license holder apply to the final SKU.

Thunderbolt uses the USB-C connector, but Intel states that Thunderbolt certification imposes mandatory minimum performance and capability requirements for shipping computers, accessories, and cables. See Intel's Thunderbolt technology overview. If a dock will carry Thunderbolt branding, request evidence that applies to the final product and commercial arrangement. A Thunderbolt controller on the BOM is not enough.

For each applicable regime, record the evidence type and exact scope. Depending on the program, this may include a declaration, listing or TID, test report, or certificate, together with the responsible company, exact model, standard version, date, issuer or lab where applicable, and derivative-model coverage.

9. Convert every promise into an acceptance row

A usable validation plan has five columns:

Add sample size, test owner, revision, and failure-disposition process. A pass on one engineering sample does not define volume-production sampling by itself.

10. Copy this checklist into the RFQ

• Project market, channel, order forecast, and target schedule
• Host, OS, display, cable, peripheral, and adapter matrix
• Upstream protocol and required backward-compatibility modes
• Port list with direction, protocol, peak rate, power, and simultaneous-use rules
• Display matrix for every promised output combination
• Adapter input, host charging, dock reserve, and downstream power budget
• Shared-bandwidth topology and simultaneous-load tests
• Firmware, VID/PID, strings, update, recovery, and version control
• Mechanical drawing, port placement, cable, materials, finish, labels, and packaging
• Product-level compliance plan and evidence owner
• Engineering sample, approved sample, pilot, and production acceptance gates
• BOM, firmware, PCB, adapter, cable, and enclosure change-control rules
• Required reports, logs, drawings, manuals, and release records

Compare price only after the scope is fixed

An OEM quote is useful only when every supplier is pricing the same product and the same acceptance scope. Otherwise, a lower quote may reflect a different display architecture, a smaller power reserve, fewer validation combinations, a different cable, or missing compliance work.

PURPLELEC's OEM/ODM docking station development page outlines the project-review and sample-validation process, while the USB-C docking station range provides reference configurations. When your matrix is ready, send the RFQ for engineering review. Use that review to settle feasibility, test boundaries, and open assumptions before comparing unit prices.