Proposal talk:Customer service

access=customers/private

Could you perhaps use existing tags instead of this?

• office=company + access=customers vs.
• office=company + access=private

-Bkil (talk) 13:04, 23 July 2020 (UTC)

I would have thought this proposal is about open customer service desks a la concierge and recepions otherwise. -- Kovposch (talk) 14:16, 23 July 2020 (UTC)

The tricky part is that even customer service offices are opened to customers only in a very small part. access=* seems a bit mysterious, I would prefer more explicit tagging, though if that proposal fails I would be also OK with using access=* @Bkil: Mateusz Konieczny (talk) 21:03, 6 August 2020 (UTC)

I hope not. Mapping receptions is a debated topic: amenity=reception_desk. While differentiating between an office that can be visited by outsiders (access=customers) vs. ones that can not (access=private) makes a lot of sense and this is how I read the introduction. -Bkil (talk) 14:28, 23 July 2020 (UTC)

I was thinking about "customer service" as in "reception"s at shopping malls and facilities, ie the likes of concierge and service counters; not the desk receiving upon entering a site. To me, it's more about the ambigious tag key-value. Say, if the function of an access=customers office=* (values currently describe the industry / business sector) is to be explicitly tagged, something such as service=customer_service (purpose-built) or customer_service=yes (if not going down the service:customer_service=yes scheme}] could be used. amenity=customer_service makes it sounds like a POI within an office, not that the office itself is a POI. -- Kovposch (talk) 17:53, 23 July 2020 (UTC)

Or maybe adopt usage=* to distinguish front vs back office. -- Kovposch (talk) 14:41, 24 July 2020 (UTC)

customer_service=yes - I switched proposal to use that. service:customer_service=yes is silly and usage=* has problems - would be problematic for iD (it is an iD design issue, so it should and can be ignored) but also would require knowing how office is used, I want to be able to just tag that customer service is available @Kovposch: Mateusz Konieczny (talk) 21:05, 6 August 2020 (UTC)

Interesting. Now that you mention it, it may be beneficial to map the customer service point (so called "vevőszolgálat") inside a large department store or supermarket like a TESCO somehow. You need to show the product there after purchase to get a stamp on the warranty card, and it is usually far away from the cashiers. Would this schema be appropriate or is this something else? -Bkil (talk) 18:31, 23 July 2020 (UTC)

I read it as for the distinction between the types of office that my county council operate. The major towns have small (two- or three-person) customer-focused offices that receive rent payments and council tax payments, deal with queries and complaints, have rolls of recycling bags, etc. There is also a large complex of offices which are not customer-focused (although one or two may be) but are where paper pushers push paper and customers only go if specially invited to. --Brian de Ford (talk) 19:27, 23 July 2020 (UTC)

Yes, it would be useful also for office=government (@Brian de Ford:) Mateusz Konieczny (talk) 21:06, 6 August 2020 (UTC)

customer vs. customers

As mentioned there is a osm term customers used for access=customers. Could it be beneficial to not mixing it? So using here amenity=customers_service instead of amenity=customer_service? There is always small confusion, see also ongoing iD-ticket: https://github.com/openstreetmap/iD/issues/7831 --MalgiK (talk) 06:47, 24 July 2020 (UTC)

As I understand, it is a phrase in English. It even has its own Wikipedia article - https://en.wikipedia.org/wiki/Customer_service Mateusz Konieczny (talk) 21:08, 6 August 2020 (UTC)

Customer service office as a independent feature

Hi. Thanks to Mateusz Konieczny for this proposal. I was just looking for a tag to map a customer service office for public transport users (metro and buses).

In my case, these offices are independent from the company's headquarters, so I had thought of using "office=customer_service" + "operator=company_name". The "office=company" features already exist for the company headquarters on the map. I was looking for a way to map the customer service office independently. Using "office=company" + "customer_service=yes" it would seem that it is a distinct company, when in fact it is the customer service office of the same company, but located elsewhere. Isn't it a good idea to use "office=customer_service" + "operator=company_name" for a customer service office? --Dcapillae (talk) 11:09, 12 August 2020 (UTC)

Sometimes the features may be co-located, eg. there is a desk at ground floor for customer service, but the upper floors are ordinary company offices, in that case we may not deem the customer service desk distinct enough to have it as it's own tag, and still best to think of it as an attribute of the office. When you have have one building for the company offices, and different location have a shopfront for the customer service function, then I can see how using different primary tags can make sense. Aharvey (talk) 12:08, 21 March 2026 (UTC)