Useful tuning feedback starts with context, then data.

Start with what the workshop observed and when. State whether it was present before the file was written, first appeared afterwards or followed another change to the vehicle. Separate a running concern from a new customer preference; those may need different next steps.

A useful opening is: Submission reference, delivered version, date written, current hardware and fuel, followed by the observed condition. Add what has already been checked. A request that only says the file is not right leaves the recipient to guess which part of the result you want reviewed.

Before recording a large set of data, agree which information is relevant to the question and what your equipment can provide. AutoTuner describes datalogging as recording live ECU values, with available measurements depending on the supported ECU. Its examples include load, boost, torque, air/fuel and exhaust-temperature values.

Follow the equipment documentation and the workshop's appropriate test procedure. AutoTuner recommends a dyno for its logging workflow. This guide does not prescribe a gear, speed, engine-speed range or load test: the suitable procedure depends on the vehicle, equipment, condition and question being investigated.

Where possible, provide the original export or an accessible log link rather than only a cropped screenshot. Retain the parameter names, units and time context. Explain which part of the recording relates to the observation and whether a comparable baseline is available.

Name the files by job reference and version, with a date or sequence that makes their order clear. If a link needs a login, confirm the recipient can access it. If the logging tool makes the link public, check that the recording does not expose unnecessary customer information before sharing it.

The workshop may need to replace a component, change a setting or test a revised file. Record each change and its timing. If several things changed before the next observation, say so instead of attributing the result to only the latest file.

Keep previous versions clearly archived. A revised delivery should not be confused with an older attachment that has a similar name. Before writing, check the submission, version and completion notes; afterwards, record the version actually used so follow-up remains tied to the correct file.

Open a support ticket and include the submission reference. Add the evidence and the specific question you need answered. Customer and administrator notifications link back to the conversation, so subsequent messages can build on the same facts.

Clarify the scope of any further work rather than assuming every new request is the same revision. A correction query, a different customer preference and a new hardware configuration are different situations. Describing which one applies helps establish the appropriate next step without losing the original job history.