ODR Best Practices for Court-Connected Programmes from Our Experiences with Court-Based ODR Design Processes

As a judicial officer and court administrators tasked with creating and implementing online dispute resolution (ODR), we have found it both challenging and rewarding to operate at the nascent stage of this brave new world for courts. There is no standard set of best practices clearly tailored for this unique task. Instead, we draw on the wisdom of similarly situated programmes and standards to guide us. Specifically, we have consulted the National Standards for Court-Connected Mediation Programs,¹xCenter For Dispute Settlement & The Institute Of Judicial Administration, The National Standards For Court-Connected Mediation Programs (1999), available at https://s3.amazonaws.com/aboutrsi/59a73d992959b07fda0d6060/NationalStandardsADR.pdf. Resolution Systems Institute’s Guide to Program Success²xResolution Systems Institute, Guide to Court ADR Program Success, www.aboutrsi.org/dme/dme-overview. and the National Center for State Courts’ many articles on ODR.³xNational Center for State Courts, Online Dispute Resolution, www.ncsc.org/Topics/Technology/Online-Dispute-Resolution/ODR.aspx. From these resources, and our own experiences, we recommend that court administrators charged with designing ODR systems consider the following questions:

1. What problem are you trying to solve? What are the pain points, and how do you think ODR might be part of the solution? Identifying a clear purpose for ODR helps guide how the ODR system is designed. It also helps avoid ODR being created as a solution in search of a problem. A programme designed to address the challenge of people not showing up for court hearings should look different from one designed to save court staff time. While achieving more than one goal may be possible, designers should also note where goals might be in tension with one another. For instance, a goal of closing more cases within the 45-day recommended window may be in tension with a goal of reducing the default rate.

2. How will you know when the problem you are trying to solve is improved? When you identify an ideal outcome, you can identify the metrics you will use to evaluate success. Metrics could be quantitative, qualitative or some combination thereof. If the information is not easily collectable, determine what the barriers are to collecting it. If the barriers are too much to overcome, it might not be worthwhile to create a programme if you cannot determine whether it is successful. Work out how you will collect data before moving forward.

3. Who needs to be engaged in the design? Identify the key stakeholders who will need to make a decision or decisions about ODR design. Consult those who will implement an ODR design: court personnel knowledgeable about IT infrastructure, programme management and alternative dispute resolution. Think about how to engage potential users, perhaps through legal services offices, the Bar, social service organizations or libraries. This engagement may reveal unexpected barriers in terms of legal prohibitions, technology challenges and opposition by needed partners. Understanding these barriers may then lead to work-around strategies, pauses in design or a decision not to move forward.

4. What does the system currently look like for these cases? Identify each of the steps in the current system and who is involved in each step. Review the system to see what changes need to be made to optimize the ODR implementation. Is the notice for the initial hearing simple and understandable? If not, change it before implementing ODR. Are there three different times people have to come to court before their case moves forward? Consider reducing or eliminating the number of court appearances required, before implementing ODR. It will be hard to demonstrate that ODR caused improvements if you also change other system components at the same time as implementing ODR.

5. Where would ODR fit in a new system? Consider where people are already engaged in a similar process, e.g. where they are already online or already engaged in negotiation or mediation. People are more likely to participate in an activity if it seems like a logical continuation of something they are already doing.

6. What standards, if any, need to change to allow for ODR? Identify what statutes, rules or policies specifically prohibit the type of engagement ODR promotes. Also consider technology procedures or protocols that might need to change (hint: this is why it is necessary to involve IT at the outset with ODR development). What additional ethical or procedural rules might need to be added before implementing ODR?

7. What specifications do we require to address the problem we are trying to solve and other obligations we have? Consider creating a rubric of functionalities that an ODR system should have if it were to fit in your court system. Consider also what features you might want, what might be desirable but not necessary and what you might want in the future but do not need now.

8. Who can best meet our specifications? Consider releasing a request for information (RFI) to learn more about what available vendors offer. Coordinate demonstrations with potential vendors to see how they function in an ideal situation. Realize vendors will present examples from functioning ODR programmes that may be very different from your system. View demos critically; vendors have an interest in presenting you with a very positive product. You may need to have a second demo as you develop your proposed ODR process and have additional questions about the ODR platform’s potential to meet your needs.

9. How might we refine our specifications to better address the problem? Engage potential users – including court staff, judges, mediators and end-users – to provide feedback on what they would need to engage in an ODR system. This is not the user-testing phase but rather the specifications phase.

10. Which vendor should we use? Consider releasing a request for proposal (RFP) to receive more specific vendor information, pricing, integration specifics, etc. If you have a single vendor choice, ensure your vendor can adapt to your minimum requirements for the system and is willing to work with you to improve as usage needs change.

11. With all we have seen, is there enough value here to move forward with this solution? If so, you will likely engage in a contracting stage with the vendor. If not, you have successfully completed a process designed to help you come to this very decision fully informed.

12. How will people engage with the system? Test everything multiple times before releasing the solution. Check your notice and other written information, the ODR technology, and support structures you provide for users (e.g. telephone support, in-person kiosks, online chat).

13. How will we receive feedback on and review the system? Create surveys for quantitative and qualitative feedback. Test your case management data collection methods. Set timelines for any workgroup to review feedback and make suggestions for changes.

Noten

• 1 Center For Dispute Settlement & The Institute Of Judicial Administration, The National Standards For Court-Connected Mediation Programs (1999), available at https://s3.amazonaws.com/aboutrsi/59a73d992959b07fda0d6060/NationalStandardsADR.pdf.

• 2 Resolution Systems Institute, Guide to Court ADR Program Success, www.aboutrsi.org/dme/dme-overview.

• 3 National Center for State Courts, Online Dispute Resolution, www.ncsc.org/Topics/Technology/Online-Dispute-Resolution/ODR.aspx.