Conversation and Action retention

Plan history limits#

Choose the period around an actual review process. If support staff review conversations daily and finish follow-up in three days, a shorter setting may be enough even when the plan permits thirty. If staff routinely investigate older cases, explain the maximum and assign a timely review owner. Increasing plan capacity does not mean every old transcript receives a new expiry. The selected retention belongs to the workspace and the conversation records created under it. Do not use an analytics chart as evidence that message text is still available: aggregate reporting and readable support content have different purposes and lifecycle controls.

Change the selected period deliberately#

The current menu is Privacy & Anti-fraud. In Transcript retention, use Keep full transcripts for, select a permitted number of days, and choose Save retention. The saved notice explains that new conversations use this period. Communicate the effective change date to anyone who investigates customer issues. For an older conversation, inspect its stored-until date instead of calculating expiry from the setting currently visible on screen. A period reduced today is not an instruction that every old item was retrospectively rewritten, and a larger number tomorrow cannot recover yesterday's deleted text.

What happens when a conversation expires#

The customer-facing conversation view checks expiry even before the scheduled cleanup has processed every row. A page not opening after its deadline is therefore expected, rather than proof that your team lost permission to an otherwise available archive. Cleanup removes transcript text and attached context, clears descriptive fields and invalidates continued use of that conversation. Internal human-handoff payloads associated with it are scrubbed too, while limited delivery metadata can remain. If you need material for a live complaint, arrange its legitimate handling before expiry. Do not repeatedly reload or upgrade a plan expecting maintenance to rebuild removed content.

Actions follow their conversation#

Keep the distinction between operational configuration and customer payloads clear. The saved Action definition describes an endpoint, input schema and permitted result mapping; it can remain useful for future customers. A particular run's submitted personal values and returned results belong to its conversation and are scrubbed when that conversation is invalidated. The verified identity proof is also removed at that boundary. Retained status metadata must not be mistaken for a readable old request. If a business process needs a long-lived case record, store its necessary authorised data in the system responsible for that process and apply that system's retention policy.

Short-lived test and verification records#

These clocks answer different questions. A proposal timeout means the customer must review a current proposal before execution. A verification timeout means mailbox control must be established again when required. A test-record timeout limits administrative test history. A transcript deadline controls retained customer content. Reaching one deadline does not extend another. In particular, refreshing a card's status does not renew its proposal or create proof of delivery. If an interrupted write becomes unknown, inspect the connected system before proposing a replacement operation. A retention deadline cannot prove that an external request was undone; it controls the stored service data.

Keep permanent business records in your own system#

For example, a return request received during a chat may require a case in your returns system while staff inspect the parcel. Creating that case is a separate authorised business step, not a reason to leave unrelated chat content indefinitely. An email already delivered to your support mailbox is likewise an external copy managed by your business. Its presence does not mean Reesponder retained the expired transcript. Tell the team which system is the operational record and which is the temporary conversation view. Limit exports to the necessary facts and protect them through your normal access and deletion procedure.

Build a review calendar that fits retained history#

Turn the selected retention period into a review routine. Assign someone to inspect recent unresolved support before its stored-until deadline and decide whether business follow-up is needed. Include weekends, holidays and staff absence when choosing the period; a team checking chats once every ten days cannot depend on a seven-day full-history setting. The review should focus on the issue and necessary facts, rather than automatically copying every conversation into a permanent archive. Record who takes over if the usual reviewer is absent.

For an ongoing case, distinguish the temporary chat from the durable operational record. A returns system can hold the authorised case reference, decision and required customer details while the original conversation expires. Link that case through a safe reference rather than spreading private transcript copies across personal inboxes. Tell staff where to look after expiry and what access controls apply to the case. If the selected period changes, update the calendar and handover date. A longer plan maximum is useful only if the business actually needs and maintains that review window; it should not substitute for an organised follow-up process.

Identify the copies outside the conversation view#

Make a small record-location register for each support workflow. A conversation can have message text and context inside Reesponder, linked Action payloads, an internal handoff summary, a delivered support email and a case created in your provider. Write which system owns each copy and which control governs its deletion. This is especially helpful when staff receive a handoff and copy it into a ticket. Expiry of the source chat does not automatically remove the ticket or recall the delivered email.

Use the register when a customer asks about retained information. Locate the relevant record instead of assuming all the visible copies share one deadline. Limited delivery metadata and usage totals are also different from full personal content, so describe the record type precisely. Review mailbox access, ticket exports and attachments under the business's own procedure. Avoid telling staff to save full transcripts as a default defence against expiry. If a particular case needs longer handling, keep only its necessary authorised facts in the proper system, with its own access and review policy. The conversation setting is one part of that operational map, not a universal timer for every downstream system.

Respond usefully when the original chat is no longer readable#

When staff open a case after the original transcript expired, check the legitimate operational record and any appropriately retained correspondence. Do not repeatedly refresh, switch plans or create a new conversation expecting the original text to reappear. If the customer needs current help, collect the minimum facts needed through the normal verified business process and continue from the case record. Explain that the old chat is unavailable without implying that every related business record has necessarily been destroyed.

For a suspected lifecycle fault, provide the creation time, stored-until time, effective workspace plan and safe record reference. Say exactly what remains visible: a chart total, an Action status, a delivered email or readable messages. A usage total surviving is expected to be a different kind of record; readable expired personal payloads require a specific investigation. Use synthetic or redacted evidence rather than sending an entire private case merely to illustrate the screen. This approach lets support assess the relevant cleanup boundary while the business continues its customer service through the correct operational system.

Example: follow up before transcript expiry#

A team with a seven-day setting receives a complex complaint on Monday. It should review the conversation promptly, verify the customer's identity through its business procedure and move only necessary operational facts into its case system if continued work is needed. Waiting until the next month to open the chat can fail even if the complaint remains open elsewhere. The business may still have a legitimately retained case or delivered email, but those copies need their own access and deletion review. Staff should not promise the customer that changing a billing plan restores the original exchange or erases every external copy.

Verify the outcome and keep safe evidence#

Record the selected period, its effective change date and the review owner. For a sample retained conversation, check creation and stored-until dates without creating unnecessary personal test content. Review where handoffs are delivered and which external systems hold case data. Verify that staff understand the difference between an expired transcript, surviving accounting totals and an independently retained business record. If a personal-data request arrives, identify its scope and responsible controller rather than treating a plan switch as a deletion tool. Use the Data Processing Agreement together with the published Privacy Policy for the processing responsibilities.