Building A Transaction Workflow - Cases For Service Marketplaces

NEW YORK - June 6, 2017 - PRLog -- Which transaction workflows are best for service marketplaces?
 When it comes to service marketplaces, classical transaction workflows just don't work. In e-commerce marketplaces, managing stock is relatively easy, since it's controlled by a single management team. In contrast, service marketplaces require availability dates and times to be dynamically maintained by service providers often made up of many individuals. As a result, those tasked with maintaining such marketplaces face uncertain provider reliability – and this calls for a new approach to the transactional workflow.

 The models first proposed by service marketplaces presented the following workflow:

• Customer makes a request to the provider.

• Provider accepts the request from the customer.

• Customer receives an acceptance message.

• Customer pays for the services.

• Provider receives the payment.

• Provider fulfills the request.

 A workflow along these lines is used by the majority of service marketplace solutions.

 But this workflow has many flaws, not least the lack of a trusted third party to help prevent fraud and create an atmosphere of confidence. It also has the inconvenient aspect of requiring the customer to be involved twice: first creating a request, then, only later once acceptance has been received, making payment (steps 1 and 4).

 Roobykon Software (https://roobykon.com/) has discovered the optimal solution earlier found by Cocolabs (http://www.cocolabs.io/en/), who tested a variety of different transaction rearrangements that are in use on different platforms, serving different types of customer group.

The transaction workflow which delivered the best results in terms of conversion rate, acceptance by the provider and fraud prevention was the following:

• Customer makes a request to the provider by entering his credit card details, with only pre-authorization performed at this stage.

• Provider accepts the customer's request and triggers completion of the payment transaction.

• Platform receives the payment to escrow.

• Provider fulfills the request.

• Platform releases the payment to the provider – after the service completion date and provided the customer hasn't filed a dispute.