Open Negotiations

​

Real-World Example

ABC Collections sends Jane a settlement offer for $800 on a $1,000 balance. The offer was generated from the group-level payment terms that applied when the creditor sent the offer. Jane responds with a $600 settlement counteroffer. Before the counteroffer is routed to ABC Collections, the system should validate Jane’s counteroffer against the group-level terms that were actually delivered to her. If Jane’s counteroffer needs manual review, it should appear in Open Negotiations and the sidebar badge counts should increase. If the counteroffer qualifies for auto-approval or auto-decline rules, it should bypass Open Negotiations and move through the correct automatic outcome.

​

Visual Flow

​

Purpose

Open Negotiations manages digital consumer counteroffers submitted in response to creditor-initiated settlement or payment plan offers. This section only applies to:

• Creditor-initiated digital offers.
• Consumer counteroffers to those offers.

This section does not handle:

• Written notice responses.
• Disputes related to written notices.
• Independent consumer settlement or payment offers.

Those items should route to Notice Responses or their respective workflows.

​

Workflow Overview

​

Creditor Sends Offer

The creditor sends a settlement offer or payment plan offer. The delivered offer may be based on:

• Master payment terms.
• Sub-account payment terms.
• Group payment terms.

​

Consumer Submits Counteroffer

The consumer may submit a settlement counteroffer or payment plan counteroffer. Example:

• Balance: $1,000.
• Creditor offer: $800.
• Consumer counteroffer: $600.

​

Validation Engine

Before routing the counteroffer to the creditor, the system validates the consumer’s counteroffer against the specific offer terms originally delivered to that consumer. The counteroffer is not checked against all available term sets. It must be validated only against the offer level applied when the creditor’s original offer was sent. Possible delivered offer levels:

• Master payment terms.
• Sub-account payment terms.
• Group payment terms.
• Phase 2: auto-approval threshold.
• Phase 2: minimum allowable threshold.

Examples:

• If the consumer received a group-level offer, validate only against group terms.
• If the consumer received a sub-account offer, validate only against sub-account terms.

This prevents counteroffers from being compared against unrelated creditor configurations.

​

Validation Flow

​

Validation Outcomes

​

Auto-Approved

If the counteroffer meets auto-approval thresholds:

• The offer is automatically accepted.
• The consumer is notified.
• The negotiation is marked resolved.
• The offer does not enter Open Negotiations.

If a payment method is present, a settlement should auto-process or a payment plan should auto-activate. If a payment method is missing, the status should become Needs Payment Method, and the consumer must add a payment method before expiration.

​

Auto-Declined

If the counteroffer is below minimum thresholds:

• The offer is automatically declined.
• The consumer is notified.
• The offer does not enter Open Negotiations.

​

Manual Review Required

If the counteroffer is not auto-approved or auto-declined, it should route to:

• Negotiations -> Open Negotiations.
• Dashboard -> Performance -> Open Negotiations.

The Negotiations badge and Dashboard > Performance badge counts should increase when the manual-review item becomes active.

​

Creditor Actions

• Accept.
• Decline.
• Counter.

No term editing is allowed in Open Negotiations. This is a review and respond workflow only.

​

Action Flows

​

Accept Flow

If a payment method exists:

• Settlement processes automatically, or the payment plan activates.
• Negotiation is marked resolved.
• Open count decreases.

If a payment method is missing:

• Consumer is notified.
• Status becomes Needs Payment Method.
• Consumer must add a payment method before expiration.
• Negotiation remains pending until resolved or expired.

​

Decline Flow

• Consumer is notified.
• Negotiation is marked declined.
• Open count decreases.

The consumer may restart negotiations or submit another counteroffer only when the business rules allow it.

​

Counteroffer Flow

• Consumer receives the creditor counteroffer.
• Negotiation remains active.
• Badge remains active.

The consumer can accept, reject, or counter again.

​

Creditor Review Flow

​

Visibility And Badge Rules

• Creditors only see their own negotiations.
• Resolved negotiations are hidden from Open Negotiations.
• Expired negotiations are hidden from Open Negotiations.
• History must be preserved.

Badge count should increase when a new negotiation arrives or a new counteroffer arrives. Badge count should decrease when the item is reviewed, resolved, declined, marked read, or expired.

​

Status Definitions

​

How It Should Work

• Only digital counteroffers to creditor-initiated offers should appear here.
• Counteroffer validation should occur before routing to Open Negotiations.
• Auto-approved and auto-declined counteroffers should bypass this queue.
• Badge counts should reflect real unread or unresolved activity.
• Accepted offers should trigger the correct settlement or payment plan execution flow.
• Missing payment methods should create a Needs Payment Method state.
• Completed, resolved, declined, or expired negotiations should be removed from Open Negotiations while preserving history.

​

How It Should Not Work

• It should not show notice responses, written-notice disputes, or independent consumer offers in this queue.
• It should not show negotiations from another creditor.
• It should not allow term editing in Open Negotiations.
• It should not leave stale badge counts after activity is handled.
• It should not route invalid offers to manual review.
• It should not create duplicate negotiation threads for the same active offer.

​

Developer Notes

• Badge updates must be real-time and accurate.
• Preserve the full audit trail for every offer, counteroffer, status change, read state, expiration, and resolution.
• Do not allow term updates from Open Negotiations.
• Validation must use the delivered offer level, not every available creditor term set.
• This page is a review and response workflow only.

​

Architecture Recommendation

Each negotiation should be represented as a persistent thread tied to:

• Consumer.
• Creditor.
• Account.
• Original offer.

The thread should include:

• All offers and counteroffers.
• Status history.
• Read and unread state.
• Expiration.
• Resolution.
• Payment method state.

This model helps prevent duplicate records, badge inconsistencies, lost history, and broken workflow transitions.

​

Related App Areas

• app/Livewire/Creditor/ConsumerOffers
• app/Livewire/Creditor/Dashboard
• app/Livewire/Creditor/Dashboard/Stats