User:ShadowMasterCM/UR Handling in NYS

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)

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 about poor service issues, and they simply go somewhere else in the future. Modern society expects perfection and insists on instant gratification, even from a 'free' app like Waze.

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. There are so many alternatives available for GPS, that we must take extra care to not leave any user dissatisfied with Waze or its data, that we as editors manage in WME.

Poorly handled URs will likely result in disengaged users that could eventually uninstall Waze.

Lower number of users will likely decrease sales of the Ads seen in Waze.

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: Many editors take the approach of making an educated guess about the URs issue and then simply close the UR, with the goal of 'keeping their area clean'. However, this could result in incorrect assumptions about the actual issue, resulting in a confusing experience for the user. Imagine a user submits a UR about a newly constructed housing tract they live in. They send a 'General' UR type with no additional information, as they pull out for work in the morning. An editor then finds the UR, and notices something odd in the name of an adjacent road in WME, fixes that and closes the UR with a comment about 'road renamed'. The user now wonders if Waze staff is incompetent [many users think that Waze staff handles the URs], and the user sees the street is still missing from Waze. Even worse is the editor that simply closes that UR with out any comment, leaving the issue unresolved and likely an angry user. Avoid 'educated guesses' and assumptions. ASK FOR MORE INFO EVERY TIME!
2. Age of URs: Many editors have personal opinions on how old is to old for processing a UR. After a UR is XX days old, they consider processing it is simply a waste of time. There were URs discovered in remote areas of NYS that were 3+ years old. Each UR was sent the standard request for additional information. Many were not responded to, and were eventually closed as "Not Identified". However, there were also several dozen that DID respond, and provided enough information to help fix major issues with the current map data. This included adding an entire housing tract, complete with street names and house numbers!
3. Reminders: Many editors consider 'Reminders' another waste of time. Let us consider how busy each of us are, and how often we have to reschedule tasks, or simple forgot to do something. Why should do we think Waze users are any different. We all need a reminder from time to time. Leaving a UR on the map for another week does no harm. It can end up being very useful if the user responds to the reminder, and provides information that helps resolve an issue with map data.
4. Weekend Warrior: Many people that own GPS devices often only use them when they are going on a special trip or to a new destination. Many of them do NOT use the GPS to navigate to/ from home/ work, because they feel they 'already know how to get there'. Consider the parent taking the kids to the 'away game', and they use the GPS to get to the sporting event. Family outings to a park or camp grounds over the weekend. Special events like NASCAR races and NFL games are not usually something we do every week and 'know how to get there'. So a user opens Waze of Saturday morning, has an issue on the way to the 'event' and sends a UR, and then later Saturday night closes Waze. Sunday or Monday an editor finds the UR and requests more info, and then 3 or 4 days later, closes it since they did not get a reply. Even if you waited as long as 7 days, but did not send a reminder, there is still a significant chance you will close the UR before the user ever opens Waze again. This leads back to the disengaged user mentioned above.

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.