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 settlement and payment-plan offers that require manual creditor action after system validation. This section applies to:

• Consumer counteroffers to creditor-initiated digital offers.
• Settlement or payment-plan offers converted from a Notice Response after the creditor adds the account and the offer does not qualify for automatic approval.

This section does not handle:

• Notice Response intake, routing, or account creation.
• Written-notice dispute or no-pay intake.
• Consumer offers before the creditor has validated and added the account.

Those intake items remain in Notice Responses until an account exists and an offer requires manual negotiation.

​

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.

​

Notice Response Exception

When a creditor selects Add Account for a Notice Response, settlement and payment-plan offers are evaluated against the creditor’s Master Pay Terms. Qualifying offers are handled automatically. Offers that do not qualify become active Open Negotiations items after the account is created.

​

Validation Engine

Before routing a digital counteroffer to the creditor, the system validates it 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. An offer converted from a Notice Response has no previously delivered creditor offer. It is evaluated against the applicable Master Pay Terms during account creation before manual review is considered.

​

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 only when an active unresolved negotiation’s latest offer requires creditor attention. Auto-approved, auto-declined, resolved, and other non-actionable offers should not remain in the count. Badge count should decrease when the item is reviewed, resolved, declined, marked read, or expired.

​

Status Definitions

​

How It Should Work

• Only validated digital counteroffers and added Notice Response offers requiring creditor action 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 unprocessed Notice Response intake, written-notice disputes, or no-pay intake 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.

​

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.