Negotiation process

Sharetribe has a default-negotiation transaction process that includes price negotiation dynamics. The same process enables both regular and reverse transaction flows.

Regular transaction flow

A regular transaction flow refers to a traditional marketplace transaction flow. This happens on a marketplace when the provider posts a listing and a customer can initiate a transaction against that listing.

A transaction process supports the regular flow when it has one or more initial transitions defined for the customer. When a transaction is initiated using a customer transition, it follows a regular transaction flow.

The default-negotiation process has one initial transition defined for a customer:

  {:name :transition/request-quote,
   :to :state/quote-requested,
   :actor :actor.role/customer,
   :actions [{:name :action/update-protected-data}]}

Reverse transaction flow

A reverse transaction flow on a marketplace happens when the customer posts a listing and a provider can initiate a transaction against that listing. This means that the initiating transition for the transaction is made by the provider.

A transaction process supports the reverse flow when it has one or more initial transitions defined for the provider. When a transaction is initiated using a provider transition, it follows a reverse transaction flow.

The default-negotiation process has two initial transitions defined for a provider: transition/make-offer and transition/inquire:

  {:name :transition/make-offer,
   :to :state/offer-pending,
   :actor :actor.role/provider,
   :actions
   [{:name :action/privileged-set-line-items}
    {:name :action/update-protected-data}
    {:name :action/privileged-update-metadata}],
   :privileged? true}
  {:name :transition/inquire,
   :to :state/inquiry,
   :actor :actor.role/provider,
   :actions []}

In both regular and reverse flows, the provider provides the product or service in question, and the customer pays for the transaction.

The default negotiation process is best suited for use cases where the customer and provider negotiate both the scope and the price of the transaction, such as a custom built item or a complex project.

The negotiation process has four main phases:

1. Transaction initiation
2. Negotiation loop
3. Change request loop
4. Reviews

In addition to transitions that process in a linear manner, it is also possible to build loops in a transaction process. A loop in a transaction process means that the same state may be entered multiple times. Loops make it possible for the participants to go back and forth in the process, or for either participant to take the same action multiple times.

The default-negotiation process has two main loops: the negotiation loop and the change request loop.

In addition, the negotiation loop contains a sub-loop where a provider can update their offer multiple times before the customer has accepted it.

Transaction initiation

First, either the customer or the provider initiates the transaction. Transaction initiation does not have looping logic.

In a regular flow, a customer can start the transaction against the provider’s listing by requesting a quote. The provider can then submit an offer from the request, and submitting an offer adds line items to the transaction. Alternatively, the provider (or operator) can reject the quote request. The customer can also withdraw their own quote request.

In a reverse flow, a provider can start the transaction against the customer’s listing in two ways:

• the provider can inquire, which does not add line items to the transaction
• or the provider can submit an offer, which does add line items to the transaction.

Negotiation loop

After the transaction has been initiated and the provider has submitted an offer, both regular and reverse transactions proceed in the same way. The negotiation phase loops between two states:

• state/offer-pending
• state/customer-offer-pending

From state/offer-pending, there are multiple paths for both the customer and the provider.

When there is a pending offer from the provider (state/offer-pending), the customer can continue the transaction in two ways: either

• accept the offer and make a payment, which exits the negotiation loop
• or make a counter-offer and suggest new line items for the transaction.

The customer or operator can also end the transaction by rejecting the offer from state/offer-pending.

The provider can withdraw or update their offer from state/offer-pending. If the provider updates their offer, the transaction goes to state/update-pending. From this state, the provider can re-update their offer or withdraw it.

The customer can either accept the update or reject the new offer from state/update-pending. The operator can also accept an update to the offer. Accepting the offer transitions the transaction back to state/offer-pending and the main negotiation loop.

If a customer makes a counter offer from state/offer-pending and moves the transaction to state/customer-offer-pending, the provider can continue the transaction in three ways, all of which transition the transaction back to state/offer-pending:

• they can make a new counter offer
• they can accept the customer’s counter offer
• or they can reject the customer’s counter offer

The customer can withdraw their counter offer, which also transitions the transaction back to state/offer-pending. The only way to end the transaction from state/customer-offer-pending is the operator transition operator-reject-from-customer-counter-offer

When the customer and provider are both happy with the offer, the customer can initiate payment with the current quote, i.e. the line items set for the transaction. Once the payment has been confirmed, the transaction moves to the second main loop, which is the change request loop.

Change request loop

After the payment step, the transaction now moves on into the delivery and change request phase.

When the provider delivers the order, or the operator marks the order as delivered, the transaction transitions to state/delivered.

The transaction can now loop between two states:

• state/delivered
• state/changes-requested

The customer and operator can now

• accept the order, and transition the transaction to state/completed
• or they can request changes by transitioning the transaction to state/changes-requested

The details of the change request will need to be discussed in messages, since the change request transition does not have any actions to store the change request information.

Once changes have been requested, the provider has only one transition available – to deliver the changes and transition the transaction back to state/delivered.

In addition, there are multiple operator transitions and automatic transitions at play.

• If the provider doesn’t deliver the order in 75 days from the payment, the transaction is automatically canceled with auto-cancel. The operator can also manually cancel the transaction before the order is delivered with operator-cancel. This ends the transaction.
• Once the order has been marked as delivered, the operator can cancel the transition with operator-cancel-from-delivered.
• Once a customer has requested changes, the operator can cancel the transaction with operator-cancel-from-changes-requested. If the change request is still pending in 75 days from the payment, the transaction is automatically canceled with auto-cancel-from-changes-requested.

All of these paths transition the transaction to state/canceled

If the customer doesn’t request changes, and the transaction has remained in state/delivered for 14 days, the transaction automatically transitions to state/completed.

Reviews

After the transaction is in state/completed, the participants can then review each other similarly to other transaction processes. The review phase does not have looping logic.

Both parties are invited to post a review once the transaction completes. Whoever posts their review first, the other participant is notified that they still need to post their review. Reviews are only published once both parties have posted their review, or once the review period expires and the participants can no longer submit a review.