A reply with evidence. A person in control.
Turn a support request into a draft grounded in company sources. Inspect what supports it, decide what should be said and approve the reply before it is sent.
Early-access requests are open. Product onboarding opens later.From a request to an approved reply.
How it works- 1
Read the request
Work out what is being asked and which evidence the recipients may see.
- 2
Draft with sources
Build a reply from permitted passages and check the cited claims.
- 3
Review and approve
A person inspects the draft and evidence before approving the reply.
The default decision point - 4
Recheck and deliver
Check recipient access again, then track the delivery outcome.
Drafting, checking, approval and delivery are separate steps, with the source evidence carried through.
Draft for the people receiving the reply.
The draft draws on evidence the requester and recipients are permitted to see. The staff member handling the ticket does not lend their wider access to the answer.1
Read the request in context
The ticket keeps the request, conversation and working draft together, so the reviewer can see what the reply is addressing.
Show the supporting passages
Citations travel with the draft. Review the relevant words instead of accepting a fluent answer on its own.
Hand uncertain work to a person
A missing usable draft or a hard policy override sends the case for human attention.
Make the decision visible.
Drafts are checked against their cited passages. Reviewers can inspect the reply and supporting evidence before approving it.2
Check supported claims
The verification step checks whether the cited material supports the draft and whether referenced provisions can be resolved.
Keep private details out
Outbound checks remove certain third-party contact details, internal links and account-number patterns. These checks support a reviewer; they are not a promise to catch everything.
Review is the default
Automatic sending is off by default. An owner can enable it only for chosen categories, and the required evidence, confidence and recipient checks still apply.
Approval and delivery are different states.
A reply is checked again before delivery. If a recipient can no longer see the supporting sources, the queued reply is blocked.3
Recheck access at send time
Changes between drafting and delivery matter. Approval does not freeze a recipient’s permissions.
See what happened
Delivery state distinguishes a queued, sent or failed reply so a failed send is not presented as completed work.
Use it for repeat questions
Policy queries, internal service requests and questions about documented procedures are useful starting points for this workflow.
Questions, answered.
Will Radcliffe automatically answer every incoming ticket?
No. Review is the default, and cases without usable evidence or with policy overrides need human attention. Automatic sending requires explicit category configuration and all of its checks to pass.
Does connecting a support tool turn on ticket replies?
No. Reading a support system as a knowledge source and configuring a reply channel are separate actions. The workspace’s channel and delivery setup must be completed before replies can be sent.
Product details
- Ticket retrieval uses the effective access shared by the sender and recipients, rather than the handling employee’s wider access. Draft context is limited to readable source passages.
- Verification checks cited claims, references and defined outbound patterns. Automatic sending also requires an allowed category, explicit enablement, sufficient confidence, fully supported claims, live hybrid retrieval and recipient checks.
- Queued delivery recalculates recipient access and checks supporting citations before sending. Delivery outcomes are tracked separately from approval.
What would your team ask first?
Tell us about the work and the information behind it.