Dispute Mediation
Grievance Redress

Mediate disputes between consumers and regulated entities with AI resolutions

Workflow purpose

This guide demonstrates how to use Proto's platform to mediate a dispute once a complaint has already been referred to a regulated entity and a response is on file. Not every dispute needs a human mediator from the start – many can be resolved by drafting a proposed settlement from the complaint history and the entity's response, then simply confirming both sides accept it. This workflow picks up after "Refer complaints to regulated entities and monitor redress" and only escalates to a human mediator when either party disagrees with the proposed resolution.

Who can benefit from this guide:

  • Central banks and financial regulators handling consumer disputes
  • Consumer protection agencies mediating between citizens and regulated entities
  • Regulators wanting a faster, consistent first pass at routine disputes
  • Mediation teams who want to focus their time on genuinely contested cases

Mediate a consumer dispute

This workflow drafts a proposed resolution from the existing complaint record and only escalates to a human mediator if either party disagrees. See how to mediate disputes between consumers and regulated entities with AI resolutions.

Just starting with the platform?
For initial setup of your AI agent – including workspace setup, agent training, and channel deployment – please start here. This workflow guide assumes your AI agent is set up and ready for more advanced configurations.

1. Create a trigger

Purpose: Start the flow when a dispute is ready for mediation.

  • Navigate to the Actions tab in the AI agent settings.
  • Click “+ Add Trigger” and select the Message Received trigger type.
  • Name the trigger “Dispute Mediation”.
  • Add a description such as “Triggers when a complaint has a regulated entity response on file and is ready for mediation.”

2. Survey – dispute reference

Purpose: Identify which complaint this mediation applies to.

  • Add a Survey action titled Dispute reference.
  • Field complaint_referenceTextWhat’s the complaint reference number?Required: On.

3. Send API request – pull the case history

Purpose: Ground the proposed resolution in what was actually said, not a generic template.

  • Add a Send API request action to the case system with {complaint_reference}. Map the response to case_history.

4. LLM action – proposed resolution

Purpose: Draft a fair, specific resolution from both parties’ positions.

  • Add an LLM action named Mediation proposal. Input: {case_history}. Output variable: proposed_resolution.
  • Success branch: first action is Set chat variableproposed_resolution = _.json_parse(proposed_resolution).
  • System prompt fields: summary (string), proposed_remedy (string), basis (string, cites which facts from the case support the remedy).

5. Confirm with both parties

Purpose: Get explicit acceptance before treating the case as resolved.

  • Add a Send message action to the consumer: “{proposed_resolution[“summary”]} Proposed resolution: {proposed_resolution[“proposed_remedy”]}. Do you accept?“ with quick replies Accept, I disagree.
  • Add a Set chat variable action to capture the reply as consumer_response – quick reply selections aren’t captured automatically, so this step reads _user_input into the variable.
  • Send the same proposal to the regulated entity through its own AI agent or portal, and capture its reply the same way as entity_response – this may run as a parallel flow on the entity’s own agent, with the result written back to this case record.

6. Branch on the outcome

Purpose: Close accepted cases automatically and route contested ones to a person.

  • Add a Branch action. Condition: _.lower(consumer_response) == "accept" and _.lower(entity_response) == "accept".
  • If true: Send API request to close the case with the agreed remedy, then Send message confirming closure.
  • If false: AI Agent Network handoff to the human mediator’s AI agent, passing {complaint_reference}, {case_history}, {proposed_resolution}, {consumer_response}, and {entity_response} in the transferred context.

7. Test the flow

Purpose: Confirm both the accepted and contested paths behave correctly.

  • Test a case where both parties accept, and confirm the case closes with the agreed remedy recorded.
  • Test a case where only one party accepts, and confirm it escalates rather than closing.
  • Test with an incomplete case history (missing entity response) and confirm the LLM action asks for more information rather than proposing a one-sided remedy.