Bring the sequence that made someone stop and ask

The most useful first conversation often starts with one moment of doubt. A customer sees two offer documents. A colleague cannot tell whether a revision was approved. A payment reference cannot be matched. Describe that sequence before deciding which technology needs replacing.

Separate observation from explanation

Write what the person did, what appeared and what was expected. “The request timed out, then an invoice appeared” is an observation. “The API failed” is a diagnosis that may conceal an operation that completed without a visible response.

Use fictional identifiers and describe the fields rather than sharing private records. Include the order of events and any retry or manual correction. A public URL can illustrate an interface, but it does not by itself establish the underlying account permissions or stored data.

Bring the people who own the meaning

Identify who can decide which offer is current, which language version is approved and which system owns billing. Another reviewer may need to settle a professional question or confirm a provider interface. Development can investigate behaviour while those responsibilities remain explicit.

End with a question an assessment can answer

For example: can the current tool preserve a decision against an offer edition, or is a separate workflow needed? Agree the evidence, access boundary and useful output before turning investigation into implementation. A first message does not need a full specification or confidential attachments. Use contact to bring the sequence and the decision it prevents.