Skip to main content
Glama

client_complaint_response_email

Write professional email responses to client complaints with three approaches: acknowledge and fix, dispute fairly, or follow up after resolution. Protects client relationships without over-apologizing or getting defensive.

Instructions

Write a professional email responding to a client complaint or serious dissatisfaction — distinct from creative feedback on deliverables. This is for relationship-level issues: missed expectations, process frustrations, quality concerns, or a client who is genuinely upset. The hardest email to write under pressure — most freelancers either over-apologise (which signals guilt and invites further demands) or get defensive (which escalates). Three routes: acknowledge (own what's warranted, propose a concrete fix — the default for most complaints), dispute (professionally push back on a complaint you don't agree is fair, without burning the relationship), resolve (follow-up once the issue has been addressed, closing the loop and resetting the tone). Required: client_name, complaint_summary. Optional: project_name, what_went_wrong (for acknowledge), proposed_fix, your_response (for dispute — your position in 1-2 sentences), resolution_summary (for resolve), route, your_name. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesThe client's first name
complaint_summaryYesA brief description of what the client is unhappy about (e.g. 'missed the agreed deadline by four days', 'the final design didn't match the brief', 'communication was slow during the project', 'the invoice was higher than expected')
project_nameNoOptional: the project name — helps ground the email (e.g. 'the brand identity project', 'the website build')
what_went_wrongNoOptional (used with route=acknowledge): a brief honest explanation of what happened — not an excuse, but context that shows you understand the issue (e.g. 'a dependency on the third-party API took longer than anticipated', 'I misread the brief on the colour palette'). If omitted, the email acknowledges without detailed explanation.
proposed_fixNoOptional (used with route=acknowledge): the concrete step you're taking or proposing to resolve it (e.g. 'an additional revision round at no charge', 'a partial refund of $200', 'a call this week to realign'). If omitted, the email offers to discuss the best path forward.
your_responseNoOptional (used with route=dispute): your position in 1-2 sentences — what you disagree with and why, framed as clarification not confrontation (e.g. 'the timeline was extended at your request on March 12', 'the brief specified a dark background and the design followed that exactly'). Keep factual.
resolution_summaryNoOptional (used with route=resolve): what was done to resolve the issue (e.g. 'delivered the revised designs', 'applied the partial credit to the invoice', 'we got on a call and realigned on the scope'). If omitted, the email references the resolution generically.
routeNoacknowledge: own what's warranted and propose a fix (default — right for most complaints). dispute: professionally push back on a complaint you disagree with. resolve: follow-up once the issue has been resolved, resetting the relationship.
your_nameNoOptional: your name for the sign-off
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It mentions the tool generates an email, explains the routes, and notes it does not count against a draft limit. However, it doesn't disclose that the output is a draft requiring user action, or describe any side effects, which would be helpful for a generation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured: purpose first, then routes, then parameters. Every sentence adds value. Minor redundancy exists in repeating the three routes in both the overview and parameter section, but overall it is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, multiple routes, and no output schema, the description covers purpose, usage guidelines, parameter semantics, and a behavioral note (draft limit). It lacks an explicit statement about the output format (a draft email), but the tool's nature is well implied. It is sufficiently complete for an AI agent to use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining how each parameter maps to the three routes (e.g., what_went_wrong for acknowledge, your_response for dispute), integrating them into the usage narrative beyond the schema's individual descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('write a professional email responding') and clearly identifies the resource (client complaint email). It distinguishes from creative feedback, which is a sibling tool, and outlines three distinct routes (acknowledge, dispute, resolve), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (client complaint/serious dissatisfaction) and distinguishes from creative feedback. Provides context on the three routes with default recommendation. However, it could be more explicit about specific scenarios where other sibling tools are preferred over this one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jabbawocky/proposalcraft'

If you have feedback or need assistance with the MCP directory API, please join our Discord server