A successful sample test should approve a defined configuration, not just a model name. Record what was tested and how future production will be matched to it. Otherwise, a sample can perform well while an undocumented component or software change creates uncertainty in the bulk order.

Create an approved configuration record

Identify the model code, voltage, controller version, installation kit and relevant component specifications. Include photographs of labels, connectors and the supplied accessories. Record the manual revision and any agreed deviations from the standard package. Store the record so that production, quality and service staff can retrieve it by model code without asking who has the latest copy, because an approval record that cannot be found functions as if it never existed. Name an owner for the record too, so updates during the program have somewhere to land instead of accumulating in individual inboxes.

The level of component detail should match the purchasing risk and the supplier agreement. The objective is traceability, not collecting proprietary information without a purpose. Specify which changes require notification and revalidation. Put that list in the supplier agreement or order terms rather than in an email, so it survives personnel changes on both sides and applies to every order without renegotiation.

Connect every acceptance result to that record

Document the sample serial number, vehicle, installation and test conditions. Include the required cooling period, electrical energy, occupied-zone temperature, observed noise and any interruptions. Retain unresolved issues alongside the results rather than hiding them in a separate email chain.

Separate cosmetic approval from functional approval. A preferred housing color or logo does not establish thermal performance, electrical compatibility or acceptable packaging for transport. Record cosmetic decisions separately with their own date and approver, so a color choice made in March is never cited as evidence about cooling performance tested in February.

Agree how production changes are handled

Ask the supplier to explain how changes to components, controls, firmware or assembly methods are communicated. Define which changes require a new sample, updated documents or a targeted test. Confirm that the order and inspection records identify the relevant revision.

If a proposed substitution occurs after approval, evaluate the affected requirements before release. Similar advertised ratings do not establish identical installed behavior. A change may be acceptable, but the decision should be visible and supported. File the evaluation with the change notification, so the next person reviewing the program can see why the substitution was accepted rather than having to defend or reverse it from memory.

Make incoming inspection practical

At receipt, verify the order identity, quantities, packaging condition, labels and agreed accessory set. Apply the agreed inspection and functional checks using trained personnel. Preserve a clear path for reporting discrepancies with photographs and serial numbers.

Do not treat an incoming inspection as a substitute for engineering validation. Its role is to verify the delivered order against what was approved and identify observable issues promptly. Train at least two people on the checklist, so absence or turnover at the dock does not suspend the check that the whole approval process depends on. Keep the inspection checklist to one page and review it after the first production shipment; checks that always pass can be simplified, and checks that caught something deserve a written example for the next inspector.

A well-managed sample phase produces three useful outputs: an approved configuration, a repeatable acceptance record and an agreed change process. Together they make the move from one vehicle to a fleet or distributor shipment more predictable.

Which acceptance criteria should be fixed before the sample ships?

Write the pass and fail conditions before the sample leaves the factory, not after it arrives. A criterion defined in advance protects both sides from a moving target, because a test that is redesigned after a disappointing result measures the relationship rather than the product. Each criterion should state what is measured, with what instrument or observation method, at what ambient condition, and what result counts as acceptance. Where a value depends on weather or site conditions, state the fallback: either a controlled test venue, a postponement rule or a documented deviation note. Ambiguity about conditions is the most common reason two people read the same test differently.

  • Required engine-off cooling period at a stated ambient temperature.
  • Target temperature in the occupied zone after that period.
  • Electrical consumption per operating hour under the agreed duty.
  • Noise observation method and the location where it is judged.
  • Installation time recorded by a trained crew on the test vehicle.
  • Behavior after repeated start-stop cycles within one shift.

Circulate the draft criteria to the supplier for comment before the sample is built. A supplier who sees the acceptance thresholds early can state honestly whether the proposed configuration meets them, which prevents the far more expensive discovery of a mismatch after installation on your vehicle. Invite comments in writing and set a reply deadline; a criteria list that silently changes after installation has failed at its only real job.

Attach the final criteria list to the purchase order for the sample itself. The document then travels with the shipment, and the receiving crew knows exactly which checks to perform without waiting for instructions that may arrive later than the freight. Keep the criteria short enough to be used on a workshop floor; a document nobody reads during unloading protects nothing, however thorough it looks in the file. If a criterion must change after the order is placed, issue the revision formally and label the sample results with the criteria version they were judged against, so the evidence stays interpretable.

How do you keep a sample log when testing more than one candidate?

When several suppliers or configurations are under evaluation, keep a single sample log rather than scattered reports. Record for every unit the supplier, model code, serial number, firmware version, arrival date, test conditions, results and final disposition. Photograph the delivered packaging of the first candidate as well, because packaging differences between suppliers explain a surprising share of transit damage claims that would otherwise be blamed on the product. A comparison built from one log survives scrutiny; a comparison rebuilt from separate emails does not. Number the entries and keep the log in one controlled location with dated updates, because an uncontrolled log invites selective quotation when the selection discussion becomes contested.

Give each candidate the same installation treatment wherever possible. A unit installed by your most experienced crew on your best-maintained test vehicle has an advantage over a rival installed under time pressure in a busy yard, and the log should show who installed what, so the comparison can be adjusted honestly rather than argued about. Record the ambient conditions on the test days too; two candidates tested in different weather are not automatically comparable, and the log should make that visible before a decision relies on the difference.

Log the failures as carefully as the successes. The way a sample fails, and how quickly the supplier responds with analysis and a corrective proposal, is itself evaluation data that the final selection will depend on. A clean pass from a supplier who never had to respond to a problem is a weaker signal than it looks. Note the response time and the quality of the analysis alongside the failure itself, because both will repeat at production scale.

Close each entry with a disposition: approved, rejected, returned for retest or withdrawn. An open-ended log without dispositions invites every candidate to be described internally as promising, which is exactly the ambiguity the log exists to remove. Review dispositions at a fixed weekly point during the evaluation so that no candidate sits in limbo while the program calendar quietly slips. Publish the dispositions internally at the same cadence, because a selection process whose status is known stops attracting repeated status inquiries from every stakeholder.

What does an approval decision record need to contain?

End the sample phase with a written decision, not a meeting consensus. The decision record should state which configuration is approved, against which acceptance criteria, with the test evidence referenced by document and date, and any conditions attached to the approval. Three outcomes are possible: approved, approved with defined conditions, or rejected with reasons. A rejection with clear reasons is a useful output; it tells the supplier what to change and tells your own team what evidence the next submission must carry.

List the conditions in a way that can be closed. A condition such as revised harness routing to be verified on the first production unit can be checked and signed off; a condition such as improve packaging cannot, and will quietly become a permanent disagreement between buyer and supplier if left in that form. Review the open conditions at a fixed date rather than waiting for someone to remember them, and close each one in writing with the evidence that satisfied it.

Name the approvers. The decision should carry the signatures or written confirmations of the engineering, quality and purchasing representatives who reviewed the evidence, so that later staffing changes do not reopen a settled question. Distribute the record to everyone who will handle the production order, including the receiving and service teams. When the receiving and service teams see the record at handover, they stop treating the sample phase as a purchasing formality and start treating it as the reference document it is. Where a condition remains open at order release, state it on the order documents as well, so the factory, the freight forwarder and your own warehouse all work from the same status rather than from assumptions.

File the record with the sample test data, the agreed configuration photographs and the accepted deviations. When a production issue appears months later, this package is the reference against which the delivered goods are compared, and its completeness at approval time determines whether that comparison is quick or painful. Store the package where production and service staff can find it without asking, because an approval record that only the purchasing team can locate protects nobody during a field issue.

What should a pilot batch validate beyond the sample?

A sample proves one unit built with unusual care. The pilot batch proves that ordinary production, ordinary packaging and ordinary installation produce the same result. Keep the pilot small enough to be affordable and large enough to cross at least two production runs, because consistency between runs is precisely what a single sample cannot demonstrate. Draw pilot units from the same production line and packing process that will serve the series order, because a specially prepared pilot validates a preparation process rather than your supply chain.

  • Whether units from different production dates match the approved configuration.
  • Whether packaging survives the planned transport route without damage.
  • Whether the supplied manuals and labels match the delivered units.
  • Whether a normal installation crew can complete the work within the expected time.
  • Whether the first service questions from the field are answered by the supplied documentation.

Agree with the supplier what happens if the pilot reveals a deviation: is the pilot extended, is the affected unit replaced, or does the order pause until the configuration is revalidated? Deciding this before shipment keeps a disappointing pilot from becoming an improvised negotiation while vehicles are already waiting for installation.

Treat the pilot as the last cheap opportunity to change the program. After full-scale release, every correction costs more, touches more vehicles and involves more people, which is why the pilot deserves the same discipline as the sample phase even though the pressure at that stage is to move faster. Write down what the pilot must demonstrate before it ships, in the same style as the sample criteria, so the pilot has an end defined by evidence rather than by fatigue.

How are labels, manuals and documentation controlled in production?

The documents delivered with production units are part of the approved product. Confirm that the label content, manual revision, quick-start sheet and any market-specific paperwork correspond to the approved configuration, and that the supplier states the document revision on the order confirmation. A correct unit with an obsolete manual generates the same support calls as a defective unit.

Decide who owns translation and adaptation of documentation for your market. Where you adapt the supplier's manual, record which revision it was based on, so a supplier-side update can be checked against your adaptation instead of silently drifting apart from it over successive orders. Where the supplier adapts documents for you instead, review the adapted version against the source revision before accepting it, because translation errors in safety instructions are rarely caught in the field.

Check documentation at incoming inspection with a short, repeatable step: verify the manual revision against the purchase order, confirm the label matches the serial number record and spot-check one unit against the packed accessory list. This takes minutes per shipment and catches the most common documentation failures before they reach installation teams. Assign the documentation check to a named person per shipment; shared responsibility for a five-minute check reliably becomes nobody's responsibility by the third delivery.

Keep the approved document set in one controlled location with a revision history. When the supplier announces an update, compare it against the approved set, decide whether it requires action, and record the decision. Uncontrolled document drift is invisible until a warranty dispute makes it suddenly very visible. Archive superseded revisions with a note of when and why they were replaced, so the history of the documentation can be reconstructed without contacting the supplier.

When should an approved product be reviewed again?

Approval is a decision with a shelf life. Define in advance which events trigger review: a notified component or firmware change, a production interruption at the supplier, a change of assembly location, a run of field failures with a shared symptom, or simply the passage of an agreed interval. A written trigger list keeps the review scheduled rather than reactive. Date the trigger list and review it annually; suppliers change factories and firmware more often than buyers change specifications, so the triggers need the same maintenance as the approved configuration itself. Assign each trigger to an owner who is responsible for recognizing it; a trigger list without owners is a wish list, because the events that require review rarely announce themselves to the document's author.

Between triggers, review the service record periodically against the approved configuration. The question is narrow: does what arrived in the field still match what was approved, and are the deviations recorded and justified? If the answer is yes, confirm and continue; if not, the change process agreed during the sample phase provides the route for correcting it.

Use the review to retire what no longer applies. Accessories that proved unnecessary, acceptance tests that always pass identically and conditions that have been closed can be simplified, which keeps the approval record a working document rather than an archive nobody reads before placing the next order. Summarize each review in one page: what was checked, what changed, what was confirmed. Short reviews that actually happen protect a program better than exhaustive reviews that keep being postponed.

Close each review with the same three outputs as the original approval: a confirmed configuration, an updated acceptance record and a confirmed change process. A program reviewed on this rhythm stays predictable, and the predictable programs are the ones that scale from one vehicle to a fleet without surprise. If the program later extends to a second supplier, start them at the sample stage rather than at the pilot stage, because production control documents from one factory never transfer as evidence to another. Set the next review date before closing the current one, because a review schedule that ends at each meeting has a way of not resuming.

Next step

Compare the available configurations in the Vethy product catalog, then request the current model-specific documentation before selecting a unit.

Sources and method

Original procurement or diagnostic guidance. This is a proposed method, not a report of a product test or a certification standard.

Frequently asked questions

How many samples are enough before approving a parking AC for production?

One well-instrumented sample is enough to approve a configuration; it is not enough to approve a supplier's production consistency. Most programs therefore follow one sample with a small pilot batch drawn from ordinary production. If the configuration is close to something already approved from the same supplier and platform, the pilot can be smaller; if the voltage, controller or installation kit is new to your program, keep the pilot large enough to cross at least two production runs before release.

What belongs in a parking AC sample approval record?

The record should contain the approved configuration with model code, voltage and controller version; the sample serial number and the vehicle it was tested on; the acceptance criteria used; the measured results with test conditions; photographs of labels, connectors and accessories; the manual revision accepted; and the written decision with any conditions and named approvers. Filed together, these items let anyone reconstruct months later exactly what was approved and why, which is the practical test of whether the record is complete.

Which supplier changes should trigger a new sample?

Changes that affect fitment, thermal performance, electrical behavior or installation method should trigger at least a targeted retest: a different compressor or refrigerant circuit, a revised controller or firmware, a new harness or connector family, changed mounting hardware or a different assembly location. Cosmetic changes generally need only confirmation and an updated photograph. The practical rule is to classify every notified change against the approved acceptance criteria, and let the affected criteria decide the depth of retesting rather than negotiating each case separately. Record the classification decision for each notification, even when the answer is that no retest is needed, because an empty decision trail looks identical to an ignored notification.

Is incoming inspection a substitute for engineering validation?

No. Incoming inspection verifies that the delivered order matches what was approved: identity, quantities, packaging, labels, accessories and observable condition. Engineering validation established that the approved configuration meets the duty on the vehicle. The two activities answer different questions and neither can cover the other. Skipping validation because incoming checks pass is the most expensive shortcut in this process, because it defers discovery of a configuration problem to installed vehicles in customer service. When a validation step has to be deferred for schedule reasons, record the deferral and the compensating check, because an undocumented shortcut and a documented risk decision are different things entirely.