Reread the feedback
Review the relevant question and the choice, value, or comment actually available.
Limit: an isolated element does not automatically prove a cause or urgency.
A reviewed response can sometimes justify a separate recovery case. First check whether separate follow-up is useful, retrieve the available information, then record the next action without confusing priority, case status, and the customer’s actual outcome.
A reviewed response does not automatically become a case. When the available information indicates that separate follow-up may be useful, the team can check whether a case already exists or open one if that function is offered in the flow. Before proceeding, reread the context actually displayed and check whether similar follow-up is visible. The case content, fields, status, last-action information, and level of detail may vary. Priority and the action to take remain later decisions made according to internal rules, visible options, and available permissions. Finally, an unprocessed, processed, or marked as recovered status describes only the declared progress when it exists; it proves neither resolution, satisfaction, nor actual retention.
Before formalizing follow-up, check what was actually observed and why a separate review may be useful.
Review the relevant question and the choice, value, or comment actually available.
Limit: an isolated element does not automatically prove a cause or urgency.
Confirm that the feedback has already been reviewed as potentially requiring a separate human check.
Limit: a assessment does not automatically create a case.
Carefully separate the information actually observed from the interpretation proposed by the team.
Limit: a rating or comment should not be turned into a proven cause, automatic urgency, or a necessary case.
When the flow offers this function and separate follow-up appears useful, open a new case or resume a case already visible.
Review only the information actually displayed. Its presence, name, and level of detail may vary.
Reread the progress, choose a priority or authorized action, then check the displayed result before continuing.
A separate follow-up area when available in the flow.
Limit: opening it proves neither urgency, cause, nor a future outcome.
The operational handling order assigned or confirmed by the team.
Limit: it organizes the work and remains human, contextual, and revisable.
The declared follow-up stage when a status is available, such as unprocessed, processed, or marked as recovered.
Limit: it proves neither resolution, satisfaction, nor a business outcome.
An action selected from the functions available and authorized in the flow.
Limit: an action does not guarantee the expected effect, that any communication will be received, or that a favourable outcome will follow.
A customer response, new booking, or other outcome actually verified.
Limit: it should never be inferred from the case status alone.
Use the guides that precede or follow the opening of a recovery case.
Learn how to reread a response in context before considering separate follow-up.
Read the articleLearn how to organize the handling order when separate follow-up has been considered.
Read the articleView the overview of documented functions for organizing and tracking recovery cases.
View the pageLearn about the documented functions for preparing surveys, collecting responses, and reviewing feedback.
View the pageSpecify the page and flow used; the relevant feedback or response without unnecessary personal data; whether a similar case or follow-up is visible and how it was found; the displayed question, response, and relevant contextual information; available status and last action; priority or action attempted; exact result or message observed; approximate date and time; and a sanitized screenshot if useful and sent according to support instructions. Never send a password, authentication code, key, token, technical secret, full payment number, or unnecessary personal information.