The team had put together a comprehensively long, colour-coded excel spreadsheet to act as a reference point on how to handle violation reports against publishers. This spreadsheet also contained a historical record of accounts that have been suspended or put under probation.
This meant that the process for reviewing new violations, and for monitoring existing ones was extremely manual and time-consuming. For example, any new report would have to be manually cross-matched with a list of accounts that are currently under probation first. Once an account has has finished its probation period, the internal team would have to manually remove them from probation, and thus are required to keep track of probation periods and when they expired on a case-by-case basis.
After reviewing the current process and speaking to a few individuals on the team who handle these violation reports day-to-day, some key insights emerged:
The first step in coming up with a solution involved translating an ambiguous and inconsistent process into a design that could cater for different edge cases. As a general rule of thumb, the below variables were identified with the team to bring a more consistent flow to violation reports, while still allowing some level of flexibility for edge cases
The first iteration catered for the initial need of reviewing a new violation, but failed to take into account the reliance on previous historical cases to apply the relevant penalty.
While a record of previous cases from the same account were visible, users had to externally open each previous case on a separate tab to review its details before returning to the case they were actioning. After testing the design with internal staff, it became clearer that a page layout that caters for this use case was required.
In a second iteration, previous cases were instead listed on the left, allowing switching between different cases without navigating to external pages to do so. This allowed the team to review cases more efficiently and with a better contextual understanding of the account's previous warnings, case notes and communications.
As previously mentioned, in almost all cases a communication is sent to the publisher to notify them of their infringement, after which they are able to provide a response before an action is taken. Initially, these communications were handled fully on the platform. This meant that in order for a publisher to respond to a violation, they would have to login to their account first. This presented a few issues, for instance:
Collaboration with the development team led to the solution of creating a unique URL that is automatically issued through email to the account owner after a violation has been reported. This meant that the account owner was immediately notified, was able to forward the URL to another team, and was able to respond to a violation if the account was already put under suspension.
This solution took a form of a simplified version of the Commission Factory platform, maintaining its brand while remaining separate from the platform itself as a stand-alone page. The receiver of the violation can see any attached documentation and respond to the violation from the unique URL generated for that violation.
The internal team had previously relied on a document that contained a list of templated messages that would be communicated to the publisher depending on the violation type. Initially, this was fully automated as part of the new functionality, which would automatically send the appropriate message depending on the violation type that had been selected, as well as attach all relevant proof or documentation of the violation (e.g. a screenshot).
After testing with the team, it became apparent that there are frequent cases where the templated messages may need to be adjusted, and the attached documentation may not necessarily always be presented to the publisher.
Instead, a semi-automated functionality proved to be a better alternative, in which the templated message would auto-populate with the relevant details, but still allow the internal team to customise the message or to exclude certain attachments from being sent to the publisher.
One of the main motivations for undertaking this project was around increasing internal staff efficiency, which relates to one of Commission Factory's KPIs for the entire company across all teams. After automating many of the manual touchpoints that the publisher development team had been undertaking, the team reported an 80% improvement in the time taken to review and process violations.
Team members who were responsible for the day-to-day review of violations reported that it's much easier for them to see all the active cases in the one place, instead of relying on an excel spreadsheet which was often outdated or inaccurate. This meant that they had more time (and mental energy) to dedicate to their other tasks throughout the week.