Start with one state disagreement

I start with one specific disagreement and leave my theory about the cause out of the description. Something like: a user completes an action, gets a confirmation, and an authorised staff member still sees the item as pending. That's two roles, two views and one business state, which is narrow enough to reproduce.

I'd avoid opening a broad ticket like "fix portal synchronisation". A ticket like that invites a tour of the whole codebase and encourages several plausible fixes at once. It also hides the question the reviewer is going to ask sooner or later, which is what observable behaviour actually changed?

So I write the disagreement down as a short trace:

1. The starting identity, role and account or tenant boundary.
2. The action taken and the data entered.
3. The immediate response, including any identifier that came back.
4. What each affected portal shows for that state.
5. Any queued work, integration records and error state.
6. A repeat with the smallest variation that might change the outcome.

Keep timestamps in one declared timezone and hang on to the raw values where you can. A sequence can look impossible when the browser, the application server and the external service each render the same instant differently, and you want to be able to tell a genuinely late event apart from a display conversion error.

Keep the trace as a test case even if your first guess at the cause turns out to be wrong. Without it, every handoff tends to start another attempt at recreating the failure from a different slice of the workflow.