Tidio and Lyro: prepare support knowledge and a human escalation path

An AI support deployment begins with approved answers and a route for questions those answers do not cover. A fluent response is not evidence that a refund, compatibility statement or delivery promise is correct. The store must decide which information can be used confidently and which decisions require a person or an authoritative account record.

This fictional homeware store is evaluating Tidio and Lyro for recurring product questions. It has published care information and shipping explanations, but individual orders can involve changing circumstances. The intended result is useful support: a correct answer when the approved material is sufficient, or a clear continuation when it is not.

Tidio’s human-support, Flows and Lyro-related requirements should be evaluated separately in the current account. This workbook does not assume every integration or account-specific action is available in every package. It defines what the store should demonstrate before releasing the chosen configuration to visitors.

Design the work around the actual completion event

1. Create an answer inventory with named owners

Group common questions into product information, policy explanation and individual-account decisions. Identify the approved source and an editor responsible for keeping each general answer current.

An answer copied from an expired promotion can remain persuasive long after its business meaning becomes wrong.

2. Keep missing knowledge visibly missing

Define the expected behavior when the source material does not establish an answer. Preserve uncertainty and the route to a person instead of instructing the system to complete every conversation.

A plausible invented compatibility statement can create a customer promise the business cannot fulfill.

3. Review overlapping and conflicting sources

Inspect whether policy pages, product descriptions and old help material disagree. Resolve the source conflict before expecting the customer-facing assistant to interpret business intent.

Two individually reasonable passages can imply incompatible delivery or return conditions.

4. Make the human route continue the actual question

Record the customer’s goal, relevant page or product, answer already provided and missing decision. Confirm which configured route reaches the support person and when it is staffed.

A transfer can create a new conversation that loses the question the visitor already explained.

5. Inspect the widget in the purchase journey

Review the support entry on a phone, including product options, cart controls and relevant page content. Keep a usable contact route for a visitor who cannot complete the automated path.

A helpful assistant can still interfere with the store when its controls cover a purchase action.

6. Review answers after a policy or product change

Use a small set of stable evaluation questions to inspect material changes. Include an unknown question and an account-specific request alongside the normal cases.

An initial successful setup can drift when the store updates its catalog but not the approved support material.

A worked batch: distinguish clean work, repaired work and unresolved work

Use the following fictional batch for a small homeware store answering product questions while preserving order-specific support. Its purpose is to make the operating definitions inspectable before a live rollout. It is not a Tidio benchmark. The batch contains 120 candidate resolved or usefully escalated support cases; 90 satisfy the agreed criteria on the first review. The remaining 30 need clarification, correction or a decision. After controlled repair, 15 of those held cases become usable and 15 remain unresolved.

The first-pass share is 90 / 120, or 75.0%. The final usable share is 105 / 120, or 87.5%. Those figures describe different things. A report showing only the final number would conceal the intervention needed to get there. A report showing only first-pass work would overlook the value recovered through a legitimate correction. Keep both, with the reason each held case entered or left review.

Rehearsal measure	Fictional input or calculation	Interpretation for this task
Candidates inspected	120	Every candidate remains in the starting denominator
Accepted without repair	90	The agreed conditions were met at first inspection
Initially held	30	Work needing a separate decision or correction
Released after repair	15	A subset of held work, counted once after approval
Still unresolved	15	Visible work awaiting an owner or missing evidence
Final usable output	90 + 15 = 105	Approved resolved or usefully escalated support cases, not all candidates

For this example, one resolved or usefully escalated support case is an operating outcome, not automatically a customer, sale or financial return. Define its completion evidence from the playbook above. If a later commercial result matters, track it in a separate column and follow the same reference into the next system. Changing the unit halfway through the report can make a larger count look like an improvement when it merely answers a different question.

Put review and repair into the operating cost

Assume 2 minutes to inspect each candidate, 12 additional minutes for each successfully repaired case, and an internal labor rate of $35 per hour. These are invented workload assumptions. Initial inspection takes 120 × 2 / 60 = 4.00 hours. Successful repair adds 15 × 12 / 60 = 3.00 hours. Keep any investigation of the 15 unresolved cases as a separate estimate; the present calculation has not priced that unknown work.

With a hypothetical $60 allocation for supporting tools, the scoped batch cost is $60 + (4.00 + 3.00) × $35 = $305.00. Dividing by 105 approved outcomes gives $2.90 per resolved or usefully escalated support case. The $60 allocation is not a quoted Tidio subscription. Replace it with the actual incremental charges appropriate to your configuration, and avoid allocating the full same shared subscription to several batches without a consistent rule.

For a small homeware store answering product questions while preserving order-specific support, the $305.00 estimate answers a bounded process question. It excludes unspecified recovery work, broader project setup and a downstream commercial result. The 105 approved resolved or usefully escalated support cases need their own completion evidence; they should not be relabelled as customers or profit. Decide whether that defined output and the remaining 15 unresolved cases justify the next controlled stage with the available staffing.

Test sensitivity before deciding that volume is the answer

Hold the scoped cost constant and suppose ten fewer candidates meet the final acceptance criteria. Approved output would fall to 95, and the cost per usable outcome would rise to $3.21. This is a sensitivity exercise, not a prediction about Tidio. It shows why the acceptance definition and the treatment of exceptions matter when comparing a clean-looking dashboard with the work performed outside it.

Alternatively, examine the incremental repair work. At the assumed labor rate, one 12-minute repair costs $7.00 before any extra charge. That is a useful boundary for deciding which corrections deserve attention. A correction that preserves an important relationship or prevents an incorrect release may be worthwhile even when it is slower. A low-value case that repeatedly consumes review time may belong in a held or excluded category instead.

Capacity also has a denominator. The scoped 7.00 hours must fit into the actual coverage available for a small homeware store answering product questions while preserving order-specific support. If the team has eight hours allocated to this task, it cannot promise unlimited same-period processing merely because the software accepts more inputs. Schedule the remaining review visibly, reduce the batch or assign additional qualified coverage. A queue hidden in a spreadsheet is still part of the operation.

Run the six acceptance exercises with a second operator

For a small homeware store answering product questions while preserving order-specific support, run the exercises against the exact selected Tidio configuration. The accepted unit is a resolved or usefully escalated support case, so a successful screen or integration connection alone does not settle the result. Keep safe source records and separate demonstrated behavior from a requested capability. Retain the unexpected case because it may reveal why one of the 15 unresolved outcomes cannot yet be approved.

Exercise 1: Create an answer inventory with named owners

Compare a current care instruction, a retired delivery offer and a question about one delayed customer order.

Only approved current information supports a general answer; individual decisions follow the appropriate route. Record the input reference, the observed result and the responsible next operator. If the result depends on a manual convention, retain that convention with this exercise so the next person can repeat it.

Exercise 2: Keep missing knowledge visibly missing

Ask a controlled question whose answer is intentionally absent from the supplied knowledge.

The response acknowledges the limit and preserves enough context for the next operator. Record the input reference, the observed result and the responsible next operator. If the result depends on a manual convention, retain that convention with this exercise so the next person can repeat it.

Exercise 3: Review overlapping and conflicting sources

Give the reviewer a product page and a policy passage with a controlled mismatch.

The authoritative answer is documented and the conflicting material is corrected or excluded deliberately. Record the input reference, the observed result and the responsible next operator. If the result depends on a manual convention, retain that convention with this exercise so the next person can repeat it.

Exercise 4: Make the human route continue the actual question

Have a colleague continue a controlled uncertain question without participating in its original exchange.

The colleague can identify the unresolved issue and the limits of any answer already given. Record the input reference, the observed result and the responsible next operator. If the result depends on a manual convention, retain that convention with this exercise so the next person can repeat it.

Exercise 5: Inspect the widget in the purchase journey

Open the widget while selecting a product option and while reviewing an intended checkout route.

The shopper can continue the purchase or contact support without an obstructed essential control. Record the input reference, the observed result and the responsible next operator. If the result depends on a manual convention, retain that convention with this exercise so the next person can repeat it.

Exercise 6: Review answers after a policy or product change

Change one controlled policy statement, update its source and repeat the affected support questions.

The current information and the escalation boundary remain understandable in the chosen configuration. Record the input reference, the observed result and the responsible next operator. If the result depends on a manual convention, retain that convention with this exercise so the next person can repeat it.

Keep an operating record someone else can continue

For a small homeware store answering product questions while preserving order-specific support, keep one reference for each resolved or usefully escalated support case. Use that reference across the input, the accepted result and any exception record. It allows a reviewer to follow the work without relying on a customer’s name, a screenshot title or the memory of the person who first handled it. Where the destination system assigns its own identifier, retain both references and explain the relationship.

Record field	What to put in it	Why it belongs in this workflow
Input reference	The original request, item or approved brief	Connects the result to the actual starting point
Configuration version	The relevant rule, template or account arrangement	Makes an observed result reproducible
Completion evidence	What establishes an accepted resolved or usefully escalated support case	Keeps the outcome definition stable
Exception reason	The missing fact, conflict or failed requirement	Directs repair toward the cause
Current owner	The person or queue that accepted the next action	Makes continuation visible
Review point	When the case or configuration needs another decision	Prevents unfinished work from disappearing

For one resolved or usefully escalated support case, write what the evidence establishes before proposing an explanation. In a small homeware store answering product questions while preserving order-specific support, the note needs the starting reference and the accepted next responsibility as well as a visible result. Keep the supporting source small enough to inspect. A large screenshot collection should not replace an explicit decision about this particular outcome.

Before increasing the workload for a small homeware store answering product questions while preserving order-specific support, review the held resolved or usefully escalated support cases by their actual cause. Use the six exercises to locate an input, configuration or responsibility gap, then repeat the affected route after its repair. The first ordinary resolved or usefully escalated support case does not establish that a different unresolved case has become acceptable.

Make the next decision from the evidence

Release the bounded support arrangement when the store can explain its sources, uncertainty and continuation. Keep material corrections tied to the owner who can approve them. Where the exact configuration does not support an essential action, record the manual route or compare a different arrangement rather than assuming the gap away.

The useful measure is resolved work or a useful escalation. A shorter conversation, a larger automated share or an attractive answer is not sufficient by itself. Tidio and Lyro should make the store’s support promise easier to maintain for both the visitor and the person who handles the exception.

Keep a short decision note for this specific Tidio use case: the work approved, the conditions still outstanding, the owner of each outstanding decision and the next review date. A conditional approval is useful when its boundaries are visible. It becomes misleading when an unresolved requirement is presented as an observed capability.