He was super kind and provided me a long answer with more context that I could share with you 
My takeaway is that it would be helpful with better accessible tooling to match incomplete store information (i.e., not necessarily an accurate location) with existing OSM objects. Especially opening hours is impossible to maintain otherwise
You can repost this more detailed reply. Maybe there are people involved with OSM now who will realize that this actually is a problem.
I complained about the same thing in Here is my experience. I work for a company that syndicates location data for bu... | Hacker News, back when I still worked at Brandify. I’ve since moved on and the company was sold to someone else, but they still are performing the same job. The issues are exactly what I said they were. After this many years, I do not remember exactly who I dealt with. But I know I tried to make edits, read feedback on data rejections, and we wound up hiring one of the OSM developers on a contract, before we abandoned the project.
Here is some context.
The syndication part of the business was what I described. Here is how it worked. Every business we worked with would come up with their own custom format for spreadsheets to send us. We developed basic imports for each based on their format. We then mapped that information to the various output formats for different mapping companies. Each mapping company had their own format, and often two APIs. One for a bulk upload, one for a per business modification. We worked out all of that logic. After that, each month the business would send up a new spreadsheet, including store openings, closings, holiday hours, and so on. We’d process that, and publish. We literally have no access to any information except what’s on the spreadsheet. Which is usually far less information than OSM wants.
The actual mapping companies all deal with complex data merges. As a verified publisher for a verified business, our data on store hours, phone numbers, and so on would be considered definitive. Actual geographical layouts though? Generally they consider their data more reliable. It usually is - businesses told us our addresses, but not an accurate geolocation. Their merges also generally successfully dealt with some more complex issues. For example streets may have a concurrency, That’s where, for example, State Rt X also has a local name for the same stretch of road. Or a city may go under multiple names. For instance the Post Office will deliver to my house whether you call my city Lake Forest, or El Toro. Mapping companies figure this out.
That was my situation, when I was asked to implement OSM for two clients. A restaurant whose name I forget, and Walmart.
My first attempt was to read up on OSM’s API. After running into issues, we hired an OSM developer as a contractor, and I tried to work with him. Then we decided to abandon the project. Now there is a report that Walmart succeeded. If so, they came up with a custom solution that is very different from the normal syndication process. I can well believe that they did that.
Here are specific problems that I encountered.
- Our search for a store of the same name in around the same location often failed, so we tried to create a new store. Only for our data to be deleted as a duplicate. We tried a number of things to improve the matching process to existing data. This improved things, but remained too low quality.
- Our data often had state routes, while OSM had a local street name, leading to failure to place the store.
- Data for stores in malls was rejected for our inability to place the store correctly within the mall.
- Walmart department data was rejected because we were trying to place multiple departments with different phone numbers and hours in the exact same spot. It wasn’t enough to know that the Walmart had a pharmacy with specific hours and phone number, we were supposed to know where in the Walmart that pharmacy is.
- Our business hour data for newly changed business hours was reverted because it was considered less trustworthy than previous in person reports from some time earlier.
I do not at this remove remember what fraction of this discussion was on forums, with that developer, and so on. I just remember the overall picture of the feedback. Which was:
- It was our fault for having such crappy data. (Sorry, but it is all we have. Do you want accurate store hours, or not?)
- You should just download our easy mobile app and use that! (I’m working in Anaheim, CA. How am I going to walk around a mall in Las Vegas?)
- Oh, just fly someone to every store and have them do it. (Our budget is limited by our contract with the company. It doesn’t cover airline travel.)
- Just get an employee at each store to download the app, and map the store. (We di not have the authority to order Walmart employees around.)
That was where we abandoned the contract and took the penalty.
In the thread they say that Walmart has now worked with OSM. My strong guess is that Walmart itself took solution 3 or 4. Which they have the power to do, even though a syndication company can’t. But very few companies are willing to put that level of effort out just for OSM. And so most companies will just outsource the work to syndication companies, who will syndicate it to companies who have a workflow that they can use. Which means Apple Maps, Google, Facebook, Foursquare, and so on. And OSM will continue to be able to complain about crappy companies that can’t be bothered to update office hours on OSM.
I understand why OSM does this. Merging crappy data is a lot of work, especially for volunteers. A map interface that is usable by people walking around requires far more detailed data than syndication companies have. If you don’t insist on quality in some way at some point, you’ll never get it.
But it comes with a cost. Right now OSM says, “You have to be this tall to work with us.” So you get to both complain how crappy the data from businesses is, and complain that you don’t have business data. Seriously? Pick a lane!
