Prior to activating a contract, there is a Final Data Capture step to perform. This is ultimately to ensure that the contract data in the system is correct, providing certainty when users review contracts in the system.
In addition, this step also enables additional data points to be captured as well as removing any “stale data” from the contract. (Removing stale data ensures that reporting data is accurate).
- What current process ensures that the contract data in the system is accurate?
- How accurate is your current contract data? What percentage would you rate the accuracy level?
- Does signed contracts get processed by a back-office function? Do they collect additional data on the contract to support reporting requirements?
For any contract drafted on the system, the Final Capture step should be a mandatory step, as data could have changed during negotiation. This is also the final opportunity to ensure you have a complete/full set of data to support all downstream activities on that contract, including Reporting and Search.
From a design perspective, the options are:
Should Final Capture apply for each Contract Type?
This is an easy one. Only when uploading signed contracts (created off platform), does it make sense to skip this step (else the user will perform the initial capture and immediately afterwards the final capture). For all other use cases, it is recommended to perform Final Capture.
How extensive should the data model be?
On the face of it, the more data you have, the better. However this can have a negative impact on the user needing to capture all this data. This is even more true for 3rd party paper contracts where it is not possible for the template to default a number of the data points. Ensure you have the data points you need to support further processes, but not any more than that.
Who should perform Final Capture?
Where there is a high demand for additional data, it might make sense to push this activity to low cost resources. However bear in mind that depending on the type of data being captured, it might still require resources with a background in legal (e.g. paralegals). So this will come down to whether the additional data is worth the additional cost/complexity of involving another set of resources.
Consider the impact on user adoption. In most cases, this step will be viewed as an additional step to the current process. Ensure that the impacted users understand the need for it as well as the benefits.
Things to avoid
Avoid making this step optional. Once users no longer trust the data in the system, it is very hard to come back from this point.