4. Smart Contract Use Case Selection
Smart contracts don’t work for everything. Selecting the first few use cases to maximize return on investment (ROI) is critical to success. At the same time, companies should also consider use cases where they already have ready access to the required data. Indicators of a good use case for smart contracts include:
- The contract or situation requires transparency.
- Parties wish to only pay for what was delivered.
- The current system has many disputes or reconciliation issues.
- There is lack of trust – in data, in interpretation or perhaps the counterparty.
- There is a need for an auditable, immutable record with evidence.
- There is a suspicion of fraud.
- The contract is complex, lengthy or repetitive to bill.
- Multiple parties or companies involved in each transaction.
- A need to synchronize truth across multiple systems.
- The current system to create a final invoice is repetitive, highly manual and has non-value-add steps.
- Both sides desire to shorten the procure to pay cycle.
- The contract is practically automatable.
- The contract terms are executable based on data and definitions rather than opinion or judgement.
- Contract terms can be expressed in logical statements (if, then, else).
- The required data to execute is digital already or digitizable.
- The parties are already incentivized to share data required for automation.
Another way to judge the value of the use case is based on the numbers. Infrequent or one-off contracts likely lack the ROI to automate. In general, the higher the numbers of the below criteria, the better the fit for automated contract execution:
- Total spend per month
- Total billable events per month
- Total invoice line items per month
- Total time to approve events in the field and cost per hour
- Total time to approve events in the office and cost per hour
- How many discrete steps on both sides to create a final invoice?
- How many emails or excel spreadsheets required to construct a final invoice?
- Percentage of line items disputed – if it’s more than 2% then that’s an indicator
- Total cost of dispute resolution and reconciliation per incident
- How often does the business unit require earnings restatements
- How long in months after last delivery does it take to close the project budget / Authorization For Expenditure?
- Average days to final invoice (seller) / total days to pay (buyer)
- Percentage discount tied to faster payment terms
Additionally, some characteristics of a contract indicate poor suitability for smart contracts:
- Source data is handwritten notes or scans of paper documents
- The use case involves infrequent or wildly variable inputs and outputs. For instance a product line that is only sold once every few years may not be worth automating
- The use case requires true human judgement on every transaction to execute.
- Smart contracts are deterministic, executing only pre-agreed rules with pre-defined inputs
- The smart contract can’t judge the quality of a weld, but can take a digital sign off from an inspector as an input
Sometimes with a bit of analysis and unsuitable use case or contract clause can become suitable through reframing. For example, while supporting a logging while drilling use case that involved a manual engineering review, we discovered:
- The elaborate review described in the contract was not occurring and perhaps had never occurred
- Field personnel were reviewing raw data trends on a laptop and signing off on the spot
- The standard for data quality could be expressed as a logical statement such as "One sample per channel per meter" and the channels could be mapped to the service levels in the purchase order
- The parties agreed on a data source for the channel data, which the smart contract could then consume and automatically judge what services were delivered and whether they met the standard without requiring an additional human review of the data
In summary, for a particular use case to be worth the effort it needs to be relatively high value, relatively high volume, expressible in logical terms, and the source data must be digitized or digitizable with reasonable effort.
In the next section we’ll look at the plethora of ways to collect contract data available today.