# How to use a Righthand with Crisp

Prepare a Crisp conversation review with website and session IDs, message fingerprints, verified identity context, and reviewed replies.

By Righthand Team · 2026-10-10

Source: https://www.righthand.ai/blog/how-to-use-righthand-with-crisp

## Keep the website and conversation together

Use Righthand with Crisp to prepare a website-support conversation review. The useful output connects the latest visitor question to a particular website and session, with a proposed source-backed answer. A visitor name or short preview is not enough to establish identity or complete context.

Crisp's [REST reference](https://docs.crisp.chat/references/rest-api/v1/) identifies conversations through website_id and session_id and messages through fingerprints. Preserve those relationships. Conversation state and verification evidence should remain distinct from any claim that the visitor is authorized to request an account change.

## Define website and knowledge scope

Give the website, approved session list, relevant product documentation, and escalation policy. For an illustrative signup-support queue, use the current public setup guide and selected conversations about onboarding, excluding unrelated visitor data.

Inspect Crisp's actual tools through [integrations](/integrations). If complete message reads are absent, provide an approved transcript or authorize a browser review. A provider action that changes state or sends a message does not prove that the selected Righthand connection exposes that operation.

## A worked brief

> At 2 PM America/Los_Angeles on Monday, review the approved Crisp signup-support sessions for the named website. Produce a private reply packet with website ID, session ID, source link, latest visitor-message fingerprint and time, current state, available identity-verification evidence, and a source-backed draft. Flag missing messages and unsupported account requests. Do not send, resolve, block, or change verification state. Deliver to me for support-owner review and reconcile each draft to its latest retrieved message.

This example is illustrative. A verified email signal is evidence about that identity channel; it does not automatically authorize a sensitive account operation.

## Define the expected packet

An example item could say: “Visitor asks why signup is pending; public guide explains prerequisites; account-specific state unavailable; draft offers the documented check and requests owner verification.” The assistant should not claim that a backend change occurred or that the visitor's account is fixed.

Keep internal notes separate from visitor-facing text. An unavailable original message or attachment should be named as a coverage gap. Do not infer unseen content from a preview or a colleague's shorthand.

## Reconcile new messages and state changes

On repeat runs, match website and session identity, then compare message fingerprints and timestamps. A new message can supersede the previous draft while the session remains the same. Update the existing packet rather than generating a duplicate queue item.

Permissions, website selection, and partial history reads can hide evidence. Return a partial review with its missing interval. If a supported send is later authorized, verify the resulting message fingerprint and conversation context separately from the draft's approval.

Use [Righthand connection permissions](https://docs.righthand.ai/guides/add-a-connection) to keep support authority narrow. Check [pricing](/pricing) for recurring visitor-support preparation and keep sensitive identity decisions with the support owner.