User:ShadowMasterCM/UR Handling in NYS View history

No edit summary
Line 14: Line 14:
== UR Data Collection ==
== UR Data Collection ==
[[File:Top 10 UR-MP Stats.png|200px|frameless|left|NYS UR-MP Stats (Dec 2015 - Jan 2016)]] Data collection about the URs of NYS began at the end of December 2015, using the 'stats' section of the UR-MP script. The collection of the data was refined and eventually was formatted in a way that we could look at it and review exactly how bad the UR situation was in NYS.  
[[File:Top 10 UR-MP Stats.png|200px|frameless|left|NYS UR-MP Stats (Dec 2015 - Jan 2016)]] Data collection about the URs of NYS began at the end of December 2015, using the 'stats' section of the UR-MP script. The collection of the data was refined and eventually was formatted in a way that we could look at it and review exactly how bad the UR situation was in NYS.  


== Why URs Matter! ==
== Why URs Matter! ==

Revision as of 20:57, 14 June 2016

New York State has had a significant number of Update Requests created within its borders, creating a unique testing grounds for what works, and what does not, when it comes to handling Update Requests [UR].

History of NYS URs

During the Fall of 2014, there was Map Raid conducted in the general NYC Region, and at its conclusion all pending URs had been 'flushed' from the map. At the time it may have seemed like a huge victory against the seemingly never ending flow of URs.

However, many new URs quickly filled that void in the NYC region, as well as continued to build up through out the rest of NYS. Approximately 1 year later, NYS had roughly 30,000 pending URs. Yes, I said 30 THOUSAND URs, just in New York State.

Google Hangout was initially set up for the 2014 Map Raid, and was eventually converted to "NY Editors" and is now used as the primary communication platform for editors working on New York State data in WME.

During the calendar year 2015, NY leadership had recruited several new editors and began training them. Eventually, the training and knowledge shared in NY Editors started to pay off. More editors were focused on fixing map data issues, rather than flushing URs. Fewer repeating URs were being generated. Editors better understood the issues and could recognize them faster, and resolve the map data issues faster.

However, despite the best efforts of the newest generation of NY based editors, as well as the occasional visiting editors, it never seemed like the UR issue was getting any better.

UR Data Collection

NYS UR-MP Stats (Dec 2015 - Jan 2016)
NYS UR-MP Stats (Dec 2015 - Jan 2016)

Data collection about the URs of NYS began at the end of December 2015, using the 'stats' section of the UR-MP script. The collection of the data was refined and eventually was formatted in a way that we could look at it and review exactly how bad the UR situation was in NYS.


Why URs Matter!

Hopefully by now, most of you have heard or read, 'Quality Over Quantity". Most editors understand what that means, but for some reason it is quickly dismissed when processing URs!

Corporate America has done significant research and determined that most customers will not bother to complain, they simply go somewhere else. Modern society expects instant gratification and insists on perfection, even from a 'free' app like Waze. There are so many alternatives available for GPS, that we must take extra care that we not leave any user dissatisfied with Waze, or the data that we as editors manage in WME.

So now consider that some user of the Waze app, had something not function as they expected, and that they bothered to submit a UR. That UR is possibly the one and only chance, we as editors, have to make the Waze experience better for that user.

Poorly handled URs likely will result in disengaged users that uninstall Waze. Lower user counts likely decrease sales of in app Ads. Those Ads are what pay the expenses to keep the app free.

Less users, lead to less ads, which leads to less need for editors!

Scenarios To Consider

  1. Assumptions:
  2. Age of URs:
  3. Reminders:
  4. Weekend Warrior:

Processing URs

https://wiki.waze.com/wiki/User:ShadowMasterCM/Standard_Responses

Update Requests in Waze Map Editor https://wiki.waze.com/wiki/Update_Requests_in_Waze_Map_Editor

Solved[edit] If you are able to identify a reason for the reported issue, and if you are able to fix the problem in the editor, fix the problem and save your changes. Then mark the update request as Solved. Not Identified[edit] For various reasons, such as lack of detail provided by the Wazer, or conflicting route vs. drive trace information, you may not be able to identify the source of the reported problem. In these cases, you should attempt to initiate a conversation with the reporter.

The resolution process / Etiquette Promote harmony between editors and the reporter, and improve the good reputation of Waze and its user community Promote harmony among editors and prevent conflict or duplication of effort Engage the reporter productively, efficiently, and courteously in the problem resolution process Missing information

There are many ways to overwhelm the reporter!

Non-responsive reporters without prematurely closing reports that could still be worked on, with resulting map or routing improvements.

Multiple editors take ownership vs shared ownership





1) request more info / clarify as needed

2) wait 7 days

3) send reminder, with info the report will end up closed as Not Identified, if we don't hear from them

4) wait 7 more days

[Note: this reminder step and waiting longer is newer guidance we are using as a trial and will likely become the official guidance at some point based on results from it so far)

5) still no response - scan general area for worst / obvious issues - this is where you can apply best guess scenarios - find something that needs fixing in this area - look harder if you can't find something!


Always close a UR with a comment

Even if only to say it's being closed as NI

Avoid longer overly complex replies in UR.

Add closing comment encouraging user to send more URs when needed in future.