Contents: Introduction | Our innovative solution highlights | Our approach | Domain definition | Rules, goals and observations | DMS solution design | Hindsight observations | In closing | Where to get more information
Introduction
It's a common existential question to wonder who we are as individuals and how to best align ourselves with the external world. Maybe you have had points in your life where you've asked yourself questions like:
What core abilities give me a natural advantage?
What core interests naturally motivate me?
What are my core behaviors and what environments best suit them?
What core beliefs do I use to determine right from wrong?
What are the core goals I want to achieve with my finite life?
These can be difficult questions to answer.
You may know of someone that figured this out early, but for most of us this personal clarity is hard-fought. It requires real-world experience, deep analysis of past experiences, regular honest introspection, and a critical evaluation of our stated beliefs (our ego-driven thoughts) vs the reality of what we regularly choose to do (our real actions).
Self awareness is also just the beginning - it needs to be reflected in our actions and choices. Living truer to our core selves means making hard decisions to change our circumstances, taking external self-directed actions even when unsure of the outcomes, being honest and consistent with others to allow them to understand us, and separating areas of choice from mandatory obligations. It also means staying resolute in the face of judgements and resistance from an outside world that often wants different things from us than we want for ourselves.
It takes work, but the investment has great long-term payouts. Without it, we risk a life of missed opportunities and unrealized potential.
Public and private sector organizations also have a core - it's just defined differently. Organizations have core values, core services, core processes, core competencies and core goals and objectives.
The path to greater success in our organizations is also highly dependent on core alignment and investment - without it, organizations also risk lost opportunities and unrealized potential, and even an early demise.
Proof can be found in highly-focused startup organizations that dethrone established organizations with their core focus (WestJet vs Air Canada), or that relentlessly invest in technological leadership and dominate where others stagnate (Uber vs Traditional Taxis).
A good example of the power of combining core focus and core technology innovation is the fall of Sears and the rise of Amazon.com. Both had similar core focuses and technologies at one point. Sears even had a century-long head start in shipped product sales and a very dominant brand when Amazon appeared as a narrowly focused online bookstore. As Sears became lost and unfocused and allowed their technologies to stagnate, Amazon maintained a laser-like focus on shipped product sales and invested relentlessly in technological innovation and advancing their systems.
Today, the dominance of Sears is a fading memory (maybe you are old enough to remember childhood hours pouring over Christmas wish books?) while millions of Amazon packages appear daily on doorsteps worldwide. Amazon invested so heavily in advanced core technologies that amazon server tech, built originally to accelerate their application development and regional performance, is now resold as Amazon Web Services, one of their most profitable businesses.
This leads to my next point. In the information age, our systems are now inseparable from our organizations.
This means our organizations are our systems, (and visa-versa).
Online systems are often the main touchpoint with customers, back-end systems control how effectively critical information can flow between partners and third parties (logistics), and our business systems dictate how efficiently our staff can perform their work (which is also increasingly being done remotely). Our systems are also the source of critical data, which is so important today, it is referred to as 'digital gold'.
Ok, so lets restate the two main points here before we continue - a core focus is critical, and increasingly it is our systems and their data that define our organizations and their future.
Now let's carry these two points into the realm of dispute resolution.
At the start of our Justice transformation journey (started over a decade ago), we analyzed and interviewed an extensive range of resolution organizations. As an outcome of this complex analysis , we identified a number of shared elements (core aspects) that spanned their diverse resolution systems and processes.
In this analysis, we found one foundational core aspect that spanned every organization and was central to everything they did.
Dispute claims, allegations and issues.
Which I will refer to as "issues" for the remainder of this article.
These issues are actually so core to everything a resolution organization does this should probably be called the 'core-core'. Issues are central to a resolution organizations core values, core services, core processes, core competencies, and core goals.
Resolving issues and claims are to dispute resolution what selling and shipping products are to Amazon.com
In case this central importance of issues is not obvious, lets explore it a bit further:
The entire purpose of a resolution organization is to identify and resolve claims and issues. Only when all identified issues are resolved is the dispute be considered closed and the associated service provided. Each new dispute file is really just a new bundle of new issues to resolve.
While the people in disputes (disputants) are important, they are united in a dispute by their association to the issues (or relationship to the claims and allegations being made). When it comes to people in a dispute:
A person can be removed and the issues can remain between others. This shows that people are secondary to issues.
Disputes are combined where people have similar issues against a common respondent (people can be different to link disputes but the issues can't). This shows that people are secondary to issues.
Past issue outcomes for or against a person in a dispute are usually not considered unless they are directly related to the current issues. This means the value of resolution histories for the same person is secondary to the current issues.
While dispute information and evidence are important, this importance is directly related to its value in proving or disproving claims and allegations. If an issue is withdrawn from a dispute, its associated information and evidence is no longer important. Where evidence is found to be unrelated to a disputes issues, it is not considered. This shows that evidence is secondary to issues.
While core processes and business services are important, they are largely focused on the issues in their jurisdiction and the rules that guide resolution. Different processes can even be applied to the same issues to try to resolve it (e.g. facilitation then arbitration). This all shows that processes and services are also secondary to issues.
We identified many, many factors in dispute resolution that have issues at the core, which was further reinforced by a decade of systems and process innovation in the sector.
Ok, so why is this observation important to systems design and technological innovation?
The central importance of issues means that any resolution system that is built without issues as a core design focus is fundamentally misaligned. Maybe you've personally experienced this in a project trying to customize a generic case management system for dispute resolution and were frustrated by system limitations, continual idea descoping and complex manual workarounds.
While generic case systems can seem to have the right 'features' that you can configure (user logins, intake, scheduling, file uploads, notifications, online access), when you go a step deeper into using these features in your sector, you often find their generic designs are poorly aligned with your needs and require incredibly complex configuration or customizations, if they can do what you really need at all.
Implementing generic poorly suited systems is like wearing equipment for the wrong sport. Would you knowingly start a project to transform your sports team performance and then saddle them with generic poorly fitted equipment that makes playing their sport clumsy and harder? I imagine a road racer on a grueling hill-climb that was provided with a 1-speed rental-focused tandem bike. Sure a tandem bike has a lot of the right elements to be called a 'bike', but its horribly suited to the task at hand.
Similarly, many enterprise systems are horribly aligned for what their organization does.
This is why leading companies use bespoke systems designed specifically for their industries and needs. And if they can't buy systems that made for their sector, they build them. They know their systems are the DNA of their organization, and the better they align to the core of what an organization does, the stronger the organization and its future will be.
This is exactly why the DMS designs are issue 'centric'.
By keeping issues at the core of all DMS designs (in exact alignment with dispute resolution), this allowed us to exponentially more efficient and innovative with data models, systems integration, user experiences, business processes, workflow automation, business intelligence, operational performance, and more.
Sure, we could have built the DMS without issue-centrism at it's core, but it would have greatly increased our design and development effort while simultaneously reducing innovation opportunities and transformation outcomes.
Without this issue-centrism and our focus on bespoke resolution capabilities we would have been dressing our client organizations with poorly fitted generic equipment and condemning them to mediocrity.
By keeping this core focus, we were able to achieve industry-leading innovations like intelligent guided intakes, fully automated scheduling and notices, fully automated workflows, highly organized digital evidence, fully controlled guided user submissions, and automated decision generation.
This issue-centrism also creates the complete end-to-end tagged data necessary for training artificial intelligence, a leading technological innovation opportunity today.
Ok, so hopefully I have explained the core importance of issues in dispute resolution system designs and why we maintained this an important core focus.
While this is a critical point, it's also only part of the innovation story addressed in this article.
In addition to maintaining our 'issue-centric' focus, issue management is also a very complex problem space with lots of design considerations. Like our articles on digital evidence and service and disclosure, we had to fully understand and successfully navigate this complexity to achieve our solution outcomes.
The following point is so important I am going to repeat it in different ways in all of the articles in this series.
Solution design in areas of high complexity are unavoidable "pay now or pay much more later" affairs. Decades of complex transformational experience have taught us the criticality of up-front investments in understanding. For the sake of our clients and our projects, we are vigilant about identifying areas of high complexity and applying our proven methodologies to avoid costly failures of idealistic oversimplifications and naïve ideas. We strongly recommend you be vigilant too.
In this article we will be addressing a long list of information taxonomy, process, systems, resolution staff, and user experience considerations associated to issues. We’ll also describe the many innovative issue-centric solutions that we incorporated in the DMS to supercharge the 'issue-centric' core of dispute resolution services.
We will cover a lot here, but as Thomas Edison aptly said, "Opportunity is missed by most people because it is dressed in overalls and looks like work".
That's a great point Mr. Edison.
So lets roll up our sleeves and dive in.
What are the innovative features that made up our service and disclosure solution?
Before diving into our claim and issues solutions, let's review a list of the features and innovations in DMS that resulted from our comprehensive design process. By reviewing this list of delivered features first, it should provide greater context for our detailed bottom-up domain analysis.
Our open-source DMS includes 36 issue-centric capabilities. Like our digital evidence and service and disclosure innovations, these are not ideas, but are production solutions that have been proven and refined through over 20,000+ annual multi-party disputes with 80,000 citizen users leveraging a wide range of resolution processes.
As there are far too many complex features here to describe visually (e.g. with screenshots or process diagrams), you can contact us through the form on our web site to book a live discussion and demonstration where we can show you exactly how we designed these solutions and how they work.
Like digital evidence and service and disclosure, there is no single silver bullet solution here. Like most complex problem domains, the transformative and innovative outcomes we achieved were only possible through a broad set of individual solutions that each addressed a different and important aspect of the complexity. These were also highly integrated in order to achieve complex automation and multidimensional outcomes.
01: A complete configurable list of all claims and issues resolved by the organization with legal names, plain text names and abbreviations to address all application, automation and generation use cases | 02: Groupings of all issues into parent categories that allow a user to answer simple yes no questions on whether general categories of issues apply to them to reduce selection complexity and angry over-selection | 03: Configurable rich text help that is associated to every issue that provides guidance, rules and links to resources that reduce assist with issue selection, improve information relevance and reduce human error |
04. Configurable additional information fields on every issue to ensure that the specific associated information required for each issue is provided and available | 05: Lists of required and recommended evidence associated to every issue with fully configurable names, help and provision options (e.g. upload now, provide later, I don't have it) | 06: Configurable sets or groupings of issues that can be used for the automated detection and prioritization of applications into a correct urgency-based process. |
07. Configurable complexities that are based on groupings of selected issues that automatically detect and route disputes to staff with the associated skills and experience | 08. Configurable issue selection rules that restrict specific issues from being selected where they should not be combined in the same dispute file | 09. Configurable issue outcomes for each issue that record amendments, no-jurisdiction, settlements, awards, orders, dismissals with/without leave - used to record detailed resolution outcomes |
10. Ability to associate all evidence and information uploads to a specific issues to associate provided evidence and the appropriate issue, including the ability for these relationships to span issues | 11. Association of issues to dispute types, dispute subtypes, and processes to make it simple for disputants to select issues relevant to their circumstances and create categorical groupings for business efficiency | 12. Automatic amendment system that detects issues that have included in notices and are then modified, including fully visual amendment indication and change descriptions |
13. Complete lists of all issue language in both legal and natural language terms so that they can be automatically inserted into a wide array of generated documents | 14. Ability for text information and descriptions to associated to any issue from any party so that initial positions and changes positions over time can be recorded | 15. A dispute view that shows all issues and related information and evidence by each party in highly in intuitive layouts for maximized efficiency of staff work |
16. An ability to replace issue outcomes while retain the previous outcome for reference where they are updated or replaced through review processes | 17. Ability for resolution staff to add new issues to a dispute file based on rules for tombstoning of paper applications or the modification of issues in resolution sessions | 18. Fully configurable natural language titles and legislative descriptions of issues that can be used for both conversational and legal use cases |
19. Ability for staff to set specific dates or monetary amounts of orders and awards with calculated totals that can be added into generated agreements decisions and orders | 20. Ability for internal staff to store and view public or private notes on specific issues to store ad-hoc support, screening, processing or resolution information | 21. Systems that hide issues that are removed through amendment including all associated information with ability to show these hidden issues if required |
22. Evidence views, previews, and file viewers that are intuitively grouped and sorted by issues to improve the efficiency of viewing and analyzing provided files and evidence | 23. Ability to automatically generate dispute notices that contain all issues on a dispute file and all their related information for service to responding parties | 24. The automated generation of resolution documents that include issues, issue legislation and rules, relevant issue evidence, detailed issue outcomes, and calculated awards and orders |
25. In-System automatically anonymized and searchable public decisions that can be filtered by included issues and outcomes and allow any dispute file to instantly locate past decisions with identical issues | 26. Configurable rules that define required information and evidence associated to any issue and that are used by online systems to ensure completeness of applications for urgent or written processes | 27. Automated completeness checks that ensure that all issue outcome information is entered by resolution staff based on core tasks like generating documents or closing a dispute file |
28. Full ability for all applicants and respondents to see all active issues on a dispute file when they are submitting information and evidence to ensure submissions are associated to the correct issues | 29. Applicant portal that lists all issues on a dispute file with provided information so that applicants can view and confirm all evidence submitted prior to resolution sessions | 30. Data systems that limit the issue information that can be viewed and the associated submissions that can be made until the other party has been served legal notice |
31. Automated routing of dispute files with specific issues or issue combinations to the correct intake screening processes and workflows to ensure clear work assignment and maximized efficiency | 32. Extensive issue-based rules that show and hide specific resolution staff options and features in DMS to greatly reduce critical staff errors and staff training requirements | 33. Inclusion of issue information in all scheduled jobs and automated workflows that ensure the appropriate templates, processes and actions are taken for the specific issues in a dispute file |
34. Configurable system for adding unstructured information or evidence to issues to address special considerations or edge cases not addressed by structured issues and evidence | 35. Systems for the provision of bulk or batch information that spans issues where applicants and respondents do not have the means of providing this information as structured digital submissions | 36. An automated engine that gathers all issues and their outcomes and, using complex configurable rules, combines them into shared or cumulative outcomes with clear descriptions of how they were generated |
How did we approach this complex domain definition?
While our detailed approach to defining complex domains is important, I am going to save you some reading time here and include a summary of our recommendations. For a detailed description of these recommendations see this same section in our article on digital evidence.
Use general problem, fact, risk and use case statements and not agile "ability to" statements to keep a broader focus on the entire problem space.
Always document at a detailed level and avoid generalizations and summaries that will mask important information.
Make sure your sessions engage a full-spectrum group of highly experienced experts that broadly represent the problem space and that your sessions are led by a strong and experienced facilitator that can manage these senior resources and complex discussions.
Start your engagements with a seeded list of relevant consideration examples to maximize participation, contributions and the value realized from these costly group sessions.
Continually use your complex domain definition to bring everyone to high levels of shared understanding and revisit your documentation often to keep everyone in a mindset of 'all things considered'.
Avoid the natural group focus on only the 'exciting' end-state opportunities by pointing out that complex solutions require a 'Staircase' approach that starts with a highly planned foundational releases that are sequentially extended. This staged building of the solution, like building anything complex, will need to address a lot of of the more mundane considerations before you will achieve the most 'exciting' ones.
Pay close attention to the human biases that will naturally appear in group sessions and work to efficiently eliminate them as they arise. These include cognitive dissonance, the Dunning Kruger effect, confirmation bias, anchoring bias, availability heuristic, status quo bias, recency bias, group think, sunk costs, loss aversion, emotionality, and authority bias.
What was our definition of the complex Claim and Issue domain?
The following 105 considerations make up our domain definition for issues. As you can see, this domain has a lot of problem, process, risk and use case statements that we had to address with our solutions.
In reviewing this long list, maybe you can think of some missed considerations that are specific to your issue management and could further improve our solutions?
Note, I used the term "issues" here to mean issues, claims and allegations. I gave each of these items a unique code for mapping these statements to the DMS features to ensure our designs addressed them all (they are referenced and mapped in the DMS design section of this article).
Information Taxonomy Considerations
IT01: Issues are at the center of all dispute resolution processes, only when all issues have been resolved is the dispute resolution service considered provided
IT02: Issues have different and specific text (data entered) information requirements like associated key dates, associated costs or amounts requested, specifically focused text descriptions, etc.
IT03: Issues have defined (required and optional) evidence that is commonly submitted and useful to resolution, and they also have ad-hoc evidence that is unique to the disputants circumstances
IT04: Issue information and evidence can come from claimants (trying to prove claims) or defendants (trying to disprove claims)
IT05: Issues, when properly broken down, are important to determining resolution urgency, the associated process, and the internal staff with the appropriate training and skills to handle their resolution
IT06: Resolution organizations have legislation, acts, and procedural rules that, depending on their level of specificity, define the allowed issues that can be resolved and the rules around the information that will be considered in their resolution
IT07: Issues are modified when legislation, acts and procedural rules are modified - this requires the full process control of issues created before and after the change
IT08: Issues can be deleted before the initial notice being generated and served, but after initial notice is generated and served deleted issues are amendments
IT09: Issue information can be provided by non-parties (agents, advocates, supporters) on behalf of parties
IT10: Issues can result in counter-issues or counter-claims that are not in the original application and associated to the defendant/respondent
IT11: Issues can have different deadlines and rules for the submissions of information and evidence
IT12: Issues are listed in dispute notices, amendment notices, agreements, decisions and orders, and often using slightly different language and formatting across these documents.
IT13: Issues can have a wide array different outcomes including dismissal (with/without leave to reapply), severing, amendment, withdrawal, non-jurisdiction, settlement, awarded monetary amounts, awarded orders, and custom awards
IT14: Issues can be modified throughout the resolution process and all changes need to be tracked (who, when, what)
IT15: Issues are added by disputants through allowed forms and processes or by resolution staff tombstoning manual form based applications or identified in resolution sessions.
IT16: Issues that have been resolved (outcomes determined) and closed can be re-opened under review processes and have their outcomes changed - past outcomes are important and must be retained.
IT17: Issues have legal language and natural language titles and descriptions that are used in different ways across different documents, systems and processes
IT18: Issues have associated user help information that is displayed in external systems and is different based on use case
IT19: Issues are central to reporting and business intelligence. This data must be related to all dispute file information to enable full operational reporting and business intelligence
IT20: Some issues share generic information and evidence that spans many issues (e.g. contractual agreements, shared damage or repair estimates)
IT21: Some evidence is provided in bulk batches that cannot be easily separated into issue-specific evidence and will remain in batched form on the dispute file
IT22: Some issue information has different information privacy and security considerations than other issue information (different levels of sensitivity and risk)
IT23: The relationships between issues and other associated information will change as business processes change, (e.g. parties, evidence, outcomes) but all historical relationships and data must be maintained in case an old dispute is re-opened.
IT24: Single issues can have one or many (1..n) associated requested outcomes or remedies being sought
IT25: Issue outcomes that are displayed in generated agreements, decisions and orders have content and rules that are specific to each issue and sometimes apply to combinations of issues
IT26: Some issues can be related to each other through things like shared building addresses or sites, and will contain information and evidence that spans these shared attributes.
User Experience Considerations
UE01: Different issues have different issue rules and conditions that must be met in their initial applications (intake) that many users will not understand. If not addressed this lack of understanding will cause costly errors
UE02: Some issues are very similar to other issues from a user perspective but have important differences from an organizational perspective which will cause user confusion
UE03: Some issues should never be selected together, but users not aware of this will make selection errors if allowed
UE04: Some selected issues change the priority of the dispute file and require the applicant to take special actions
UE05: Issues and their associated resolution information can change over time, especially where there are significant wait times for resolution services, users will need easy methods to submit changes to information prior to resolution sessions
UE06: Issues have specific evidence that should be provided and well-organized to avoid adjournments or issue dismissals
UE07: Issues can often be categorized in ways that allow a user to answer simpler general questions, before they see the complex lists of all available issues in the category. This can greatly reduce the complexity and errors in selection by new users
UE08: Disputants can be highly emotional, and in this emotional state are likely to 'over select' associated issues in an attempt to 'throw the book' at the respondent. This can unnecessarily complicate dispute files and create additional cleanup work
UE09: It is very common for disputants to miss important evidence, provide too much evidence, provide the wrong evidence, or associate their evidence on the wrong issue
UE10: Many respondents do not understand the issues that are being brought against them and the associated legislation, acts and procedural rules that describe the actions they should take and information they should provide to defend themselves
UE11: Some disputants will provide a "package" of information or evidence through non-digital sources (e.g. service offices, bulk scanning services) which limits their ability to separate and organize it
UE12: Agreements, decisions and orders include issue titles, information and outcomes that the disputants must be able to understand and verify.
UE13: Depending on their issues, disputants should not receive system-based notifications, communications or be allowed to make certain submissions
UE14: Some issue awards represent a sum that is the result of multiple issues, or that reflect outcomes based on issues that span linked dispute files, this can be very hard for disputants to understand in agreements, decisions and orders unless they are cumulatively described
UE15: The titles for issues that are included in legislation, acts and procedural rules are often worded in legally correct ways, but this is language that users will find difficult to understand
UE16: Applicants have the option of selecting specific processes (like expedited applications, direct request/written, or oral hearings) and these processes each have specific rules the user must follow but will likely be unfamiliar with
UE17: Applicants may be required to correct critical issue errors or to address non critical but important gaps in their issue information. They will need clear instructions on what these errors and gaps are and how to address them
UE18: Applicants will be given restricted time periods to correct critical issue errors in their dispute file before their dispute is considered abandoned/closed and they are forced to file a new applicatio
UE19: Disputants may submit information over multiple timeframes in small chunked submissions. Prior to resolution sessions it will be very useful for users to review all provided information and validate nothing important is missing
UE20: Disputants, if provided with generic 'describe your claim or issue' fields that are not restricted, will be likely to over describe their issue and request things that the resolution organization has no jurisdiction over
UE21: Applicants will often know general information about their circumstances that can be used to restrict the available issues that are associated to them
UE22: Applicants may be unfamiliar with the process and outcomes of certain issues and benefit greatly by being able to review recent outcomes in past decisions with their exact issues
UE23: Not all issues are able to be clearly categorized. In special cases, users may need to add uncategorized generic issues
UE24: Applicants will not intuitively know when they have provided all important recommended issue information, or remember important information they have indicated they will provide later
Staff Efficiency Considerations
SE01: The natural language titles of issues or claims that are used for external citizens are often either too wordy or not aligned with the act, and this can cognitive load and time on internal staff that have limited time with each dispute file
SE02: Specific types and groupings of issues allows for automated detection of dispute file urgency and resolution process. This is very important to a wide array of staff and user actions (e.g. scheduling, notifications, notice generation, user support, submission screening, resolution tasks)
SE03: Specific types and groupings of issues are important to the automated assignment of an appropriately skilled resolution staff member (e.g. the right facilitator, mediator, adjudicator, arbitrator)
SE04: Specific types and groupings of issues are important to controlling external user submissions, notifications, and automated resolution workflows, that if not enforced, can complicate resolution and impact important resolution outcomes
SE05: Dispute files are often linked or grouped together to increase the efficiency of resolution sessions where issues are shared across multiple files. Staff need to be able to locate and combine these files to maximize resolution efficiency
SE06: New disputants can require a lot of live in-person support (phone, email, chat). Live support is costly, limited in availability (by business hours and available support staff), and requires staff training and management. The support information that is provided is highly dependent on issues and often incudes similar support that is related to user issues
SE07: Issues can be removed or modified during wait times for resolution services, this creates amendments that replace prior information, but only if respondents were served notice of the changes. If not served, the changes should not be considered. This can be hard to for staff to sort out unless key information is available
SE08: There are defined (allowed) outcomes for all issues, that can be complex for resolution staff to memorize and adhere to consistently. These should be defined system options that can be selected based on each issue to simplify work and reduce human error.
SE09: Support and resolution staff will need to be able to add internal notes to specific issues or provided information as important context to disputant interactions and the resolution services that were provided. Some notes are FOI-able and some are not, some notes are included in agreements and decisions, and some are not
SE10: The outcomes of different issues (dismissals, withdrawals, awards) dictate how and where these outcomes are displayed in automatically generated agreements, decisions and orders. Different issues also can contain rules or formulas that create cumulative outcomes that form complex agreements and decisions
SE11: Staff may forget to enter important issue outcome information into a dispute file. Where this data is missing it will limit operational and performance reporting and the automation savings of tools like decision generation
SE12: Staff will make changes to issues on behalf of parties (e.g. phone support), and these changes need to be tracked as staff changes not user changes
SE13: Review hearings and review processes usually put a freeze on the issue information and do not allow this information to be modified or added to. This is an important restriction that must be enforced for both internal staff and external users
SE14: Specific types and groupings of issues are important to the enforcement of different timelines and rules, and staff need to be able to tell quickly when these rules have, or have not been met in user submissions (e.g. late evidence)
SE15: Resolution staff will often need to search for disputes based on the issues that they contain, and to see issues clearly listed in search results
SE16: Some issues inherently contain both applicant and respondent outcome possibilities (e.g. not awarded to an applicant means awarded to the respondent) while others do not
SE17: There are time periods under which submissions and/or amendments to issues are allowed, and times where they are not allowed
SE18: There are issues that are not in the jurisdiction of a resolution organization but users may try to submit
SE19: Staff may request that applicants fix critical errors or gaps in their application, that when resubmitted must be validated by staff as corrected.
SE20: A very important comparative performance metric across resolution staff is the time spent on resolution and their issue outcomes. Where the issues are similar and volumes are adequate, this allows for powerful comparative performance across staff
SE21: All issues on the dispute can have a shared outcome like no-jurisdiction, dismissals, or withdrawals. This means that staff will be setting the same outcome on all issues in many cases and this could be automated
SE22: Where online systems ensure high initial issue information quality and completeness and the system can detect the dispute priority and staff skill level, the dispute can be automatically booked and notice provided without intake screening
SE23: Resolution staff will benefit from being able to view past decisions that exactly match the issues on a specific dispute file, especially when they are learning about specific issues and their resolution considerations.
General Process Considerations
GP01: The issues in a dispute file are foundational to automatically detecting the urgency of the dispute and its priority to the resolution organization.
GP02: The issues selected in intake can trigger different application screening processes and workflows by resolution staff
GP03: Initial applications can contain improperly selected issues or missing critical information that the applicant must correct before resolutions services can be initiated
GP04: There are specific issues that are never selected together which naturally creates pools of issues that can be handled in ways that improve user experiences, service efficiency and resolution outcomes
GP05: Different issues are screened for information completeness in different ways and require different screening processes, this often includes critical errors, that if not addressed will result in the dismissal of the issue and the inefficient need for the applicant re-apply for dispute resolution to resolve the issue
GP06: Some information and evidence will not be available at the time of the original application and will need to be submitted later. It can be very important to know if this information is going to available later, or not at all
GP07: Some respondent parties avoid engaging in resolution processes and do not provide any information or evidence associated to issues. It is very important to justice outcomes that the engagement of respondents is maximized
GP08: Some issues have a much greater impact to the parties than other issues in a dispute file and should be resolved with higher priority (first). This leads to defined sequencing of issues in resolution workflows
GP09: Generated agreements, decisions and orders have a lot of repeated issue related information that is used in very similar ways in all decisions, this creates opportunities for automated issue-related content workflows and custom text to be stored and shared across staff writing these documents.
GP10: Amendments (changes) made to core issue information that was contained in original dispute notices (already served) will need to be served again. Whether these amendments have been served is important to whether these changes are accepted and how they appear in agreements, decisions and orders
GP11: Resolution staff spend a lot of time focusing on issues and issue information, making this critical information to a broad array of internal processes and a key factor in workflow efficiency
GP12: Many sub or supporting processes are dependent on the issues in a dispute file, making issues an important routing factor for core and supporting processes
GP13: Some issues are high volume and have defined structured information that should be provided, while other issues are low volume and highly unique in the information that should be provided. This demands both highly structured and ad-hoc issue configurations to maximize utility and efficiency
GP14: Applicants may decide to abandon their issues due to inability to serve, realization they will not get the desired outcome, or deciding not to pursue the matters anymore
GP15: General external information may not be associated to specific issues, and still be very important to their resolution (e.g. held deposits, liens, monies in escrow, protective or restraining orders, application and legal fee recoveries, etc.)
GP16: The process that is most appropriate for resolution is often based on the initial positions of parties on each issue. Issues have their own unique information and early resolution options that can be used to gather more complete initial information and better route disputes to the appropriate service.
Technical & Systems Considerations
TS01: Clearly tagged and organized issue data that includes all party submissions and has well-defined data outcomes is critical to artificial intelligence opportunities and reinforcement learning that is based on the correlation of general dispute information to training goals (outcomes).
TS02: Specific issue configurations are critical data points for the system-based selection of dispute files for scheduled jobs and automated routines
TS03: Dispute files will have important differences in the external information submission channels that are available on a dispute file, how long they are available for, whom they are available to. This is highly correlated to issues
TS04: Issues will be grouped into categories for a number of different purposes (urgency detection, process assignment, staff assignment, sub-processes, etc), this information often needs to be stored as configurations that can be modified to align with rule and process changes
TS05: System notifications and reminders templates are selected based on specific issues in a dispute file and include the merging of information into text that is based on issue lookups. This will need to be updated as issues change
TS06: Automatically generated dispute notices and amendment notices will contain issue information and specific user instructions and guides that are based on the issues in the dispute file. This will need to be updated as ruled and processes are changed or improved
TS07: Automatically generated agreements, decisions and orders are heavily dependent on the specific issues and outcomes on a dispute file. This is complex and highly structured content that will change as rules, processes and issues are modified.
TS08: Disputes that are linked due to similarity in issues and parties will have their issue outcomes stored on the individual dispute files, but will share agreements or decisions that span all associated files, making agreements and decisions artifacts that are stored on one file, but related to all linked files.
TS09: Issues have very complicated relationships with other data in the system (people, information, evidence, notices, etc.), these relationships will continually evolve and change. These relationships are important to both backend and front-end systems and will change with processes, rules and data requirements change.
TS10: There is extensive language, help, policy and outcomes information associated to specific issues that will continually evolve and change. This information will be important to both backend and frontend systems and will need to be updated and improved regularly to address user support or business process needs
TS11: The ability to view issue information in external sites is dependent on the user type (applicant, respondent), role (e.g. primary applicant) and service of the issue information. External systems will need to factor in this complexity to align with information privacy and security requirements
TS12: A lot of information that is submitted to support issues has important metadata that is important to the efficient viewing and analysis of the provided information (e.g. file size, # pages, image resolution, length of audio file, length of video file)
TS13: Issues can have outcomes that have been replaced during a review process, and the review process outcomes will become the new outcomes for the dispute.
TS14: Public anonymized decisions are most easily located using the same issues and applicant information that is provided in intake. Patterns across intake and decisions searches should mirror each other for maximum user and systems efficiency
TS15: Public anonymized decisions are anonymized copies of original decisions that are stored in the organizations systems where the are a source of truth which allows them to be used to validate that orders and awards they have been provided have not been modified (e.g. photoshopped)
TS16: Issues are often grouped by awards for meaningful reporting (e.g. orders of possession, monetary orders) in data warehouses and business intelligence systems that are based on summarized outcome information
Did we uncover any general rules, goals or foundational observations?
The issue combinations selected in initial applications can provide valuable information for automated prioritization and routing of disputes. From your detailed list of issues, identify issue combinations that are associated to specific resolution rules, urgencies, resolution processes, user submission rules, and resolution staff assignment. Properly defined, these rules will unlock the possibility of fully automated intakes with advanced features like automated service routing, automated urgency detection, automated booking, instant notice generation and provision, automated submission controls with reminders, automated service and disclosure, and automated document generation. For example (without naming names), I worked with 'Organization A' with generic issues; 'I want money' or 'I want someone to do something', and 'Organization B' that defined 87 distinct issues complete with specific help, evidence, information and outcomes. Today Organization A is highly manual with low operational control, and Organization B is a highly automated with incredible operational control and business intelligence.
Where staff screening or resolution detects repeated errors or deficiencies in provided issue information, treat these as innovation opportunities to improve submission systems and eliminate these errors from happening. Most organizations invest significant time in manually screening issue-related information gaps or errors that add delays and inefficiencies to resolution. Often they request the applicant to correct these errors before the dispute proceeds or use valuable time from resolution sessions to correct them. This can be greatly improved through a recurring dedicated process that tracks issue omissions, errors and corrections located by staff and identifies systems improvements that will reduce or eliminate them. As your applications become cleaner you will greatly increase the efficiency of your intake, screening processes, and resolution sessions.
Issues can often be grouped into general questions categories that make user selection easier and help avoid the common problem of emotional over-selection. Disputants are often highly emotional, and when shown long lists of all possible issues (opposing persons potential wrong-doings), often 'over select' issues because they want to blame the other party for as much as they possibly can. Where there are a lot of similar issues (e.g. different monetary issues), a generic initial question can be used to help them select categories that apply to them (.e.g. 'are you seeking money for damages to your property Y/N' - that only when answered Yes show all of the individual compensation-related issues). By hiding detailed issue selection behind general questions you will simplify applications for users and greatly reduce the likelihood of emotional over selection.
Define the critical information and suitable length of text descriptions for each issue and use this to request targeted information with max lengths. Disputants tend to over-describe the many ways in which they feel they were wronged, where in reality they should provide specific, concise and relevant information to get the best outcomes. Wherever possible include issue-specific instructions and help for each issue text description, ask for specific important information separately, and reasonably limit text description lengths to ensure they to are concise.
Issue outcomes should be considered critical business data and should not be buried in written documents like agreements, decisions and orders. One of the most important aspects of business intelligence and operational performance is the resolution outcome of every issue you resolve. By ensuring that all issue outcomes are recorded as detailed system data and not buried in documents, you will gain deep reporting transparency into your staff, processes, and services. Having this data at your fingertips enables deep analysis of your resolution services and allows you to make evidence-based improvements and investments.
Looming Artificial Intelligence (AI) opportunities are highly dependent on large volumes of clearly tagged data that span then entire resolution process from initial application through to resolution outcomes. A lot of organizations have generic issues, low fidelity process and submission data, and issue outcomes that are buried in documents. This is a huge and costly gap in both current and future opportunities including A.I. By ensuring that all issues are clearly defined, all associated information clearly linked, and all issue outcomes are recorded as tagged systems data, you will be building a foundation for the many incredible opportunities of modern A.I.
How did we describe the initial DMS design (initial solution definition)
The following is the list of our service and disclosure features that we designed and included in our open-source DMS solution. Beside each item is a list of the domain considerations that they address.
As you can see here, out of our full list of 105 considerations, we were able to successfully address 100 of them, or 95.2%! The comprehensive list of DMS features and input considerations from this process allowed us to group and sequence features into highly intentional phased releases. Our strength in planning and full coverage designs created fast initial adoption rates and rapid realization of intended organizational benefits like process transformation, workflow automation, and digital service innovation.
We created the following categories for the components and features: DM = data model and information taxonomy, UI = user interfaces for submitting and managing issue information, SYS = system or backend features that support issue management.
Identified DMS Feature | Considerations Addressed |
DM: Allow all disputants (parties and non-parties) to be associated to claims as applicants or respondents and a clearly defined, history-maintaining set of issues | IT07, IT11, IT24, TS01 |
DM: Allow all issues to be stored with multiple issue descriptions and issue outcomes (requested remedies) associated to the specific disputant and their position (applicants or respondents) and the staff that recorded the outcome | IT01, IT09, IT13, IT16, IT23, IT25, TS01 |
DM: Allow all relevant dispute information to be associated to issues (e.g. disputants, notices, evidence, information, outcomes, amendments, documents) and for this information to be directly associated to the disputant or staff submitter (who, what, when) | IT02, IT03, IT04, IT12, IT15, IT15, IT19, UE06, UE19, UE20, UE21, GP13, TS01, TS12 |
DM: Allow issue information and evidence to span multiple issues (e.g. general descriptions, bulk evidence) | IT20, IT21, IT25, IT26, UE11, UE23, GP15 |
DM: Allow for both structured and unstructured issues and evidence for special edge case issues | GP13, TS01 |
DM: Allow all foundational issue changes after initial notice service to be stored clearly as amendments histories, and for all changes to include tracking of the associated service | IT14, UE05, GP10, TS01 |
DM: Allow for disputes and publicly posted decisions to share all important issue information so that matching past decisions are stored using the same data as dispute file | UE22, TS01, TS14, TS15, SE23 |
DM: Allow for full process, stage, status and owner information to be recorded for all key phases and actions associated to resolution and tied to issue resolution | GP12, TS01 |
DM: Allow dispute files to be linked with the primary file clearly indicated on all secondary linked files with the ability to access shared agreements, decisions and orders that are stored on the primary file from the secondary file | TS08 |
UI: Create intuitive online flows that use simple questions and general information to narrow issues to specific applicants and ensure that all important information is submitted and rules are followed, with full help on all selections, information items and rules - with the full capability to be returned due to critical errors and be resubmitted with corrections while maintaining initial submission dates | UE01, UE02, UE03, UE07, UE08, UE09, UE16, SE02, SE03, SE19, GP03, GP04 |
UI: Create automated communications, statuses, and intuitive guided flows that applicants can use to correct critical errors or omissions in their application that block its resolution, with automated abandonment if not addressed by a communicated deadline. | UE17, UI18 |
UI: Create intuitive methods for internal staff to add issues manually that are suitable to the specific dispute file characteristics, ensure required associated information is provided and that automatically set the dispute file priority staff skill levels required for resolution and matching to the correct process and staff assignment | SE02, SE03, SE08, SE12, SE13 |
UI: Create methods that that internal staff can use to record allowed outcomes and provide the required and optional information associated to these outcomes, including the ability to replace and archive outcomes modified through review processes | SE08, SE10, SE16, SE18, TS13 |
UI: Create internal issue specific notes for all types of users for the addition and viewing of internal information specific to screening, support or resolution work by staff. | SE09 |
UI: Create rules based flows that allow a user to withdraw individual issues or all issues on a dispute file and have them removed from core views along with all of their associated information | GP14 |
UI: Create methods for disputants and resolution staff to view associated information and evidence that is associated with each issue for both internal (case system) and external (user portal) views including in-system file viewers for associated evidence | SE06, GP05, GP11 |
UI: Create automated information completeness checks for disputants and staff that provide clear feedback on missing issue information | SE11, GP05 |
UI: Inclusion of associated issue information in applicant and respondent flows that are dependent on issues in the dispute file so that information and submissions are contextualized by their associated issues wherever applicable | UE09, UE10 |
UI: Create automated bulk actions to set issue outcomes with one click where a shared outcome has been determined (e.g. no jurisdiction, dismissal) | SE21 |
UI: Create systems that display the 'latest' state of all issues and issue information, including all changes from amendments or submissions, and with a full history of updated information | IT08, IT13, SE07 |
UI: Create generated decisions that are populated by dispute file information including issues, amendments, related act/legislation/rules, analysis, evidence and outcomes. | TS07 |
UI: Create summary and comparative dashboards and reports that use issues and issue outcomes to enable operational and comparative staff performance specific based on apples-apples issue-centric analysis and comparison and are instantly available organization wide | SE20 |
UI: Create extensive search, filter and view tools that allow issues to be used to locate and view information, and that are based on a unified search results pattern that includes clearly indicated issue codes | SE15, GP02 |
UI: Create an automatically generated public anonymized decision with search metadata that includes all important dispute factors, including issues to find exact decisions that match any target dispute and include a link to these decisions in orders so that they can be verified online as unaltered | UE22, TS14, TS15, SE23 |
UI: Display issues and issue related information in internal views with the most important issues first, and well organized associated information | GP08 |
SYS: Issue information configuration files that include issue titles, associated issue information fields, associated issue evidence and help text for all associated information fields | IT17, IT18, UE12, SE01, GP13, TS05, TS09, TS10 |
SYS: Configurable rules that enable and disable external and internal features based on the issues, priority, type, and process currently associated to the dispute file | SE13, SE14, SE17, GP01, GP03, TS04, TS11 |
SYS: Issue language configuration files that include relevant legislation, act and rule information in both legal and plain language format for insertion into generated agreements, decisions, and orders. | UE15, SE01, TS06 |
SYS: Issue prioritization and assignment configuration files that use groupings of selected issues to detect a dispute files urgency, resolution process, and appropriate staff assignments | IT05, UE04, UE15, SE02, SE03 |
SYS: Submission receipts that include associated issues as contextual information on each submission, are automatically emailed and viewable in systems, and can be used as a complete record of all issue related submissions | UE19, GP13 |
SYS: System access rules and configurations that only allow sensitive or private issue information to be viewed, modified and contributed to by validated users | GP10, TS11 |
SYS: Issue-aware scheduled jobs, notifications, reminders and email templates for targeted communications - automatically selected based on the dispute issues and can merge associated issue information, including information that is missing and should be submitted | UE13, UE24, GP06, GP07, TS05 |
SYS: Issue outcome combination based on configuration and rules where individual issue outcomes create a shared cumulative outcome | UE14, SE16, TS16 |
What observations do we have in hindsight, and do any opportunities still remain?
With issues at center of dispute resolution, this is one of the richest areas for innovation and automation opportunities. There are literally hundreds of advanced capabilities that we can add to the DMS that would advance our clients capabilities and the quality and efficiency of their provided services with an issue-centric approach. As the list is literally too long to address in this article, I will provide some key highlights of priority future innovations that we feel have the greatest potential return on investment.
Fully automating booking with no organizational dependencies until initial service has been provided: We built out all of the functionality to automatically book the initial hearing on disputes with issues that do not require enhanced screening or application support. The DMS detects suitable applications with low likelihood of errors, automatically generates and provides initial dispute notice, and automatically puts the dispute into a status of waiting for the applicant to provide proof of respondent service online. This solution was put on hold due to some important pilots of new client processes that include manual work to prove them out (Related to SE22 above)
The applicants ability to view matching decisions before filing their dispute resolution application: With anonymized decisions stored in DMS and associated to the specific issues and outcomes in every decision, our online intake systems can locate recent decisions that exactly match the issues of the applicants file that they can review before they submit. Adding this final step to the application process, the applicant can be provided with matching recent decisions that show both successful and unsuccessful outcomes and the reasoning behind these outcomes. By reviewing these matching decisions it will help the applicant improve the quality of their information and help set more realistic expectations for the resolution service (related to UE22, SE23 above)
The migration to full in-system decision composition (online agreement and decision writing): By extending on our current decision generation, that populates an online preview from defined templates, sections and content, that is exported as an editable word document for custom writing and finalization - this final editing can moved inside the browser in DMS where nothing is done outside the system. This would eliminate the need for external document saving, allow any decision to be worked on from any internet connected computer, and complete an important issue-related data loop for A.I. where all custom writing and edits are now data that can be used for reinforcement learning (related to GP09 above).
Adding issue-specific initial settlement options to obtain party settlement positions: Common settlement options exist for most issues based on their specific characteristics. These characteristics enable guided system-based responses to defined settlement options for each issue that can either automatically flag disputes for settlement processes and/or automatically provide targeted self-resolution tools where parties report a overlap in early settlement positions (related to GP16 above).
Structured and clearly defined respondent issue/evidence: While our systems request specific applicant evidence for each issue to ensure the relevance and completeness of their evidence submissions, our respondent evidence does not have the same detailed structure and is more genetically structured by issue associations and responding to applicant evidence. By adding structured respondent evidence for each issue we could further improve the quality, quantity and completeness of these respondent submissions (related to UE09 above).
Automatic gathering of initial respondent positions to applicant claims as soon as they are served: By adding an automated issue-specific step to gather initial respondent positions to issues as soon as they are served, this would allow all parties initial positions to be included in application screening and for improved routing to the most suitable and efficient resolution process (e.g. facilitation, written hearing, oral hearing - related to GP16 above).
In closing
Our issue-centric core design focus and our complex domain definition worked extremely well in the DMS project and resulted in industry leading automation and innovations in the dispute resolution space. Our approach allowed us to identify, design and deliver a full suite of industry-leading bespoke solutions that fully addressed almost every aspect of this fundamentally important problem space.
I hope this article helps you with your own core focuses and complex domain analysis and has provided some innovative ideas for issue-centric solutions. If you enjoyed this article, make sure you check out our designing the future blog.
Until our next article, keep on innovating and sharing those working solutions!
Mike Harlow
Solution Architect
Hive One Justice Systems, Hive One Collaborative Systems
©2023
Where can you get more information?
If you have questions specific to this article or would like to share your thoughts or ideas with us, you can reach us through the contact form on our web site.
If you are interested in the open source feature-rich DMS system that includes the innovations outlined in this article, visit the DMS section of our web site.
If you want to learn more about this issues domain, our approach to complexity, or to see these solutions in action, we offer live sessions and lectures that provide much greater detail (including templates, analysis, and feature demonstrations). These sessions also allow breakout discussions around key areas of audience interest. To learn more about booking a live session, please contact us through our web site.
If you are an organization that is seeking analysis and design services to support your own explorations into a brighter transformed future, we provide the following services:
Current state analysis: where we evaluate your existing organizational processes and systems and provide a list of priority gaps, recommendations, opportunities, and solutions for real and achievable organizational improvement.
Future state design: where we leverage our extensive technology, design, creativity, and sector experience to engage in the "what is" and "what if" discussions that will provide you with a clear, compelling and achievable future state that you can use to plan your transformation.
Comments