Communication and Support for Additional Services

[kenneth_ds]

Over the past several months we've encountered circumstances where our representative community members have come to our support group with needs for services that are considered Additional Services. While understanding that the documented stance is no expectation of support and can change without notice, there is a larger need for support beyond community forums for many of these services.

There are several examples where unannounced changes have rendered services inaccessible (Google Scholar access tied to Google Assistant being enabled) or have popped notices for our users that direct them to Workspace admins when we don't have any communications or resources from Google for context (Google Colab).

At minimum an updates blog, dev diary, NDA product roadmap, notification in the admin console, or any communication resource that could be provided would go a long way for Google Workspace Admins. Technical Service providers want to partner with Google and provide the best support possible to the communities they represent. We need Google to open the door.

[icrew]

100% agreed!

It may be apocryphal, but I heard years ago that the decision of whether to be a core service or not rests with the team running that particular service, which is just nuts. 

As one recent example: Google Photos counts against an organization’s storage quota in Workspace, but since it’s not a core app, there are no admin controls or APIs. Meaning that an admin has no way to see/delete/assist with/change ownership of a user’s content in Photos, even though the organization is paying for that storage. 
Google, this policy really needs a major rethink!

Ian Crew

UC Berkeley 

[wccartd]

+1

[strublej]

100% Agree!!!

[icrew]

Yes - this would be really helpful.

Paula Lackie
[image: DataSquad link]
DataSquad Founder + Academic
Technologist
for
Data - Carleton College
*Find me at the **AT Drop-in events on the ITS calendar
*

*Be sure that you measure what you want. Be sure that you want what you
measure. ~Paula*
*"An asset is only an asset if you can access it ..." Association of Moving
Image Archivists/Digital Asset Symposium 2008*
*~*

*I stand on the homelands of the Wahpekute band of the Dakota Nation. We
honor with gratitude the people who’ve stewarded the land through the
generations and their ongoing contributions to this region. We acknowledge
the ongoing injustices that we have committed to the Dakota Nation, and we
wish to interrupt this legacy, beginning with acts of healing and honest
storytelling about this place.*

[ctb38]

Thank you, Kenneth, for laying out the problem that we've been wrestling with. It's not a new problem; it goes back to the formation of Google Apps as a suite of disparate tools pulled together under one umbrella. The umbrella has very fuzzy boundaries. Products on the border of that umbrella or outside of it have different rules and governance than things inside, but we have to manage them as a whole (and our users perceive them that way). The only way for us to really control it is to lock our campuses down to just the core apps, but that denies our users the value of a lot of useful tools. Google could help us by telling us when a non-core product change is going to affect us, giving us messaging for our users, and giving us the controls before we hear about it from panicked users, not two weeks later. (Not to mention that changing a service that is used in classes right at the end of a school term showed a distinct lack of sensitivity to the audience.)

-Chuck Boeheim

Cornell University

[kenneth_ds]

Exactly right!
My answer to faculty questions about ongoing availability has to be met with, "I don't know; that's an excellent question" and a link to the Google support article saying that there is no expectation of continuity of service.