Extending Fin to a legal-heavy email channel at Palisade Freight
Palisade Freight runs Fin on chat with a 52% resolution rate and stable CSAT. Email is a different world: 2,800 inbound messages a month, median first response 6 hours, and agents write long, careful replies because roughly a third of the senders are enterprise accounts with contractual SLAs. Inbound mail routinely contains screenshots of damaged cargo, forwarded threads with five parties copied, and signatures with legal disclaimers.
Fin's chat answers are short, use bullets, and end with a clarifying question and a quick-reply button. The support manager wants to switch Fin on for all email immediately to cut the 6-hour response time, arguing that email customers are 'more patient'. Legal has asked what happens if Fin comments on a liability claim. Nobody has measured email reopen rates, because agents simply reply again in the same thread.
1. What must change about Fin's answer style and format for email, and how would you enforce those changes rather than hope for them?
Read the worked answer
The chat style will fail in email for structural reasons. Email has no quick-reply buttons, so any answer that depends on a click is a dead end. A one-line answer reads as dismissive in a channel where the customer wrote three paragraphs. And a clarifying question that arrives six hours later, with no partial answer, feels like being ignored twice.
Required changes.
- Front-load the answer. State the resolution in the first two sentences, then context. Email readers skim and often forward.
- Self-contained replies. No references to 'the option above', no components, no dependence on an earlier message in the thread.
- Plain-text formatting. Headings, tables, and rich layout degrade or look broken across mail clients. Short paragraphs and simple lists.
- Greeting and sign-off consistent with the brand, and a clear statement of what happens next and when.
- Honest limitation on attachments. If the customer sent a photo of damage, Fin cannot assess it; it should say so and route rather than pretend.
Enforcement. Style instructions live in channel-level guidance, not in the agent's memory, so they apply to every email answer. Add email-specific templates for the top intents. Then verify by sampling 50 live email replies a week against a one-page rubric - front-loaded, no dead-end references, no forbidden topics - until the sample passes consistently.
2. Which email conversations should be out of scope at launch, and what should the handoff look like so the 6-hour wait does not simply move downstream?
Read the worked answer
Out of scope at launch.
- Anything from contract-holding enterprise accounts. They pay for named humans and SLAs; a wrong AI reply here has commercial consequences. Scope by account segment, not by topic alone.
- Liability, damage, and insurance claims. Legal's question is the right one: Fin must not characterise fault or coverage, and the topic is too variable for content.
- Messages whose substance is an attachment. Cargo damage photos, signed documents, scanned paperwork.
- Multi-party threads where the customer is coordinating several stakeholders - the reply must address each, and context is spread across the thread.
- Cancellation, refund, and contract-change requests. Route to a human with authority.
Handoff design for email specifically.
- Fin should still send a substantive first reply - acknowledge, answer what it can, state that a specialist will follow up, and give a realistic window. Silence plus a queue is worse than chat, because the customer has no widget telling them someone is there.
- Set an explicit state and owner at handoff; email has no live presence, so the queue is the only signal an agent gets.
- Show the SLA clock from the customer's send time, not from handoff.
- Never let Fin send a second reply after a human has joined the thread - duplicate replies in email look chaotic and get forwarded internally.
Measure the right thing: time to first substantive response, not time to first automated acknowledgement.
3. How should email resolution be measured differently from chat, and what is the specific risk in reading 'no reply' as success?
Read the worked answer
Three measurement differences matter.
- Time horizon. Chat resolution is judged in minutes; an email conversation can legitimately pause for days while the customer checks something. Evaluate at 7 and 14 days, not at 24 hours, or you will classify slow-but-fine conversations as failures and push the team toward premature closure.
- Thread structure. Reopens in email are not a distinct event - agents reply again in the same thread. You must define resolution operationally: a conversation is resolved when the customer's issue is closed and no further inbound message arrives within the window, confirmed by state and close reason. Without that definition, everything looks resolved.
- Different denominators. Email traffic is more enterprise-weighted and more complex than chat at Palisade. Comparing the email resolution rate directly to the 52% chat figure will produce a misleadingly negative read and pressure the team into over-broad scope.
The 'no reply' trap. In email, silence is ambiguous. The customer may be satisfied; they may have given up; the reply may have landed in spam; or they may be waiting on their own customer. Treating non-response as automatic resolution inflates the metric and hides real dissatisfaction - and in a freight context, an unresolved damage claim that goes quiet for two weeks comes back as a legal complaint.
Mitigation: require an explicit close reason, track a 14-day follow-up inbound rate as a quality check, survey a sample of quiet conversations, and never let a materially negative sentiment or claim thread auto-close on silence. Report email and chat separately, with scope and segment stated alongside each number.