Planning your Customer Support approach

Use Customer Support Plan to agree how your business answers questions, handles requests, and brings in the right person when more help is needed. The result should be a practical reference your team can use for consistent, accurate replies.

This guide uses an illustrative bicycle-repair business. Adapt the examples to your actual services, policies, people, and support channels.

Open the plan and choose your starting point

Open Assistant → Strategy → Plans → Customer Support Plan. Choose Fill it in myself for an empty plan, or Add details, Edit, or Review suggestions on a section. Select Save after editing each section; you can save work in progress.

Your Customer Profiles and Brand Guidelines must be ready before the support plan can show Ready to use. Use them to understand who needs help and how the business should speak to them.

The five essential decisions are Questions & how to handle them, Trusted sources, Allowed actions & required approvals, Who handles each issue?, and Never request. Start there, then add the details your team needs for everyday situations.

For saving sections and reviewing suggestions, see Setting up your business strategy in Cedros. Saving this plan records your decisions; it does not enable support chat, change its instructions, or grant access to customer accounts.

Define what support covers and where it is available

In Purpose & Access, describe the service customers can actually expect:

• What support helps with: the questions and problems your team handles, such as choosing a repair service, understanding an estimate, or reporting a problem after collection.
• Where support is available: the channels your business has set up and monitors. Mark planned channels separately so nobody directs customers to an unavailable service.
• Who support prioritizes: how you prioritize requests and why, such as a customer unable to use a recently repaired bicycle before a general service inquiry.
• Authentication and account context: what information each channel can access and how identity is verified before discussing a customer's private details or changing a booking.
• Main support outcome: what better support should achieve, such as resolving common questions and getting unresolved repair issues to the right person with useful context.

For the repair business, public questions about service availability may be answerable from the service page. A question about a particular repair needs the appropriate verified record and someone able to check it. Do not assume that a chat has access to those records merely because a customer provides a name or booking number.

Map questions to trusted answers

In Questions & Trusted Answers, give the team a repeatable way to handle each topic:

• Questions & how to handle them: for each topic, record common questions, whether to answer, clarify, hand off, or decline, the trusted source, any permitted action, and when to involve another person.
• Trusted sources: list the source name, location or link, topics covered, priority, and whether it is official, draft, outdated, or missing.
• Which source wins when answers conflict?: decide which approved source takes precedence. If the conflict cannot be resolved, state who checks it.
• When to answer, clarify, or hand off: explain what evidence is sufficient for an answer, when a focused question would help, and when someone else needs to decide.
• Out-of-scope topics: identify requests support cannot resolve and give the appropriate next step where one exists.

A topic entry might read: “Repair prices: explain the published pricing basis from the current service page. Clarify which service the customer means if needed. Refer a job-specific estimate or disputed charge to the workshop team.” Use that only if it matches your pricing process.

Keep source descriptions specific. “Use the website” is less helpful than naming the current service page and explaining which questions it answers. Check links and remove outdated references when the service changes.

Define allowed actions and privacy boundaries

In Actions, Privacy & Boundaries, describe what support may do and what it must avoid:

• Allowed actions & required approvals: list each action, whether it is permitted, the conditions, any identity check, the person who must approve it, and how completion is confirmed.
• Never claim: record statements that require evidence, such as saying a booking has changed, a refund is approved, or a repair will be ready at a particular time.
• Never request: list information support should not ask customers to share, such as passwords, full payment card numbers, private keys, API secrets, or authentication tokens.
• Privacy and data handling rules: specify the minimum information needed for each issue, why it is needed, and the appropriate channel for sharing it.
• Sensitive topics & policy rules: for topics such as billing, cancellations, privacy, or complaints, name the approved policy, what can be explained, and when a person must take over.

For example, answering a general booking question and changing a customer's booking are different actions. Record the verification and approval needed for the change, and who can perform it. A rule in this plan does not grant application permissions or create a new support capability.

Keep proposed replies honest about the result. “Here is how to request a refund review” does not mean a refund has been approved or issued. Claim a completed action only when it has actually succeeded and the result can be checked.

If a customer shares sensitive information, avoid repeating it in a reply or copying it into examples. Record a safer next step in your guidance and use only the details needed to resolve the issue.

Make human handoffs specific

In Human Handoffs, make it clear when and how another person should help:

• Escalation triggers: list situations that require a person, such as a request for human help, a disputed charge, an unresolved repair problem, missing information, or an exception to policy.
• Who handles each issue?: name the responsible person or team, the contact route, priority, necessary context, and any information that should not be collected.
• Handoff message rules: provide wording that explains why another person is needed and what the customer should do or expect next.
• Availability & response promises: record the actual monitored hours and approved response wording. Promise a specific response time only when the business can support it.

For the repair business, a disputed charge might go to the workshop manager with a short issue summary and an appropriate booking reference. Confirm that the route is monitored and the manager can make the decision before recommending it.

Use wording that matches what happened. If support only gives the customer a contact link, say where they can request help. Say “I've passed this to the workshop manager” only after the handoff has actually succeeded. Do not describe a planned route as a live transfer.

Write useful replies for common situations

In Replies & Common Situations, show what good support looks like:

• Support voice: adapt your brand voice to helping someone. For example, be calm, specific, and respectful, especially when the customer is frustrated.
• How to structure a reply: give a simple pattern, such as acknowledge the issue, answer what the evidence supports, and give a clear next step. Ask a focused question only when needed.
• Common situations & example replies: record the question, intended behavior, source, clarifying question if needed, handoff point, and sample wording.
• Approved public links and resources: list the pages customers can use, explain when to share them, and check that they are current and accessible.

For example, a customer asks whether a bicycle is ready for collection. If the responder cannot check the repair record, a useful reply could be: “I can't confirm the repair status here. Please contact the workshop through the support route shown on our contact page so the team can check before you travel.” Replace this with your actual route and approved wording.

Include examples for an ordinary service question, an ambiguous request, a complaint, a policy exception, and a request for a person. Show how the answer changes when the necessary information is missing. Avoid filling examples with fictional customer records or unsupported assurances.

Practice the approach and track missing information

In Quality Checks & Review, define how you will check and improve the guidance:

• Practice questions & expected responses: write realistic questions and the behavior you expect, including the required source and whether someone should take over.
• Knowledge gap handling: explain what to do when the answer is missing: acknowledge the gap, avoid guessing, offer an appropriate route, and record the question for follow-up.
• Known knowledge gaps: list missing or weak sources, such as unclear collection instructions or an outdated cancellation page. Give each gap an owner and next step.
• Guidance for the support assistant: summarize the approved rules for answers, clarification, actions, privacy, tone, and handoffs. Keep it consistent with the detailed sections.
• Review cadence and triggers: choose a review schedule and events that need an earlier update, such as new services, changed policies, repeated incorrect answers, or support incidents.

Start with a manual review of the practice questions. Check both a straightforward question with a clear source and a difficult case with missing information or a requested exception. The expected response should show what the responder can confirm and what still needs checking.

Some fields offer Review suggested starting point. Read and adapt that text before choosing Accept reviewed answer, then Save. Suggested wording is a starting point, not an approved policy.

Guidance for the support assistant may offer Draft from my decisions. This opens a prepared Strategy prompt for review before sending. AI replies can add to your usage and costs. Check any proposed wording before accepting and saving it.

Review the saved plan and apply the decisions

1. Reopen the plan and check that the topics, sources, actions, handoff routes, and response promises agree with one another.
2. Ask the people responsible for each support route to confirm the process and the information they need.
3. Walk through the practice questions. Correct unsupported answers, unclear next steps, or promises that the team cannot meet.
4. If the plan shows Needs decisions, check the five essential decisions and the Customer Profiles and Brand Guidelines prerequisites. Unknowns and unreviewed suggestions remain unresolved.
5. Apply the approved decisions to the support instructions, public help content, and operating procedures that customers actually encounter.

For public support chat, follow Teaching support AI about your business to align its configured instructions, business details, and published sources. Saving the plan does not automatically apply those changes. Cedros also uses the plan as a reference when reviewing support conversations and when it is selected as a source for content work.

Use Not known yet for an open decision and explain the next step. Use Not applicable with a reason when a question does not apply. Ready to use means the plan's readiness checks are satisfied; it does not confirm that a support channel, permission, or handoff has been configured.

If a save reports a conflict, preserve your intended edits, use Reload latest plan when offered, and compare the newer version before saving again. For an unresolved editor problem, ask for help with the section name and visible error.