Mutualizing support and comms

With the current budget situation in mind, several instances had a preliminary meeting on Dec 16 to discuss the possibilities of sharing/mutualizing aspects of support and communications functions. Working together could bring efficiencies for everyone.

This summarizes our initial thinking on this. There is a second meeting planned to continue these discussions and if other @instance_managers wish to attend, here is the zoom invitation.

Summary of our Preliminary Discussions
Instances present were: Aus, Can, US, UK. All these instances currently pay for support and comms management in their instance.

  1. Support Coverage

What is Needed?
Several instances who pay for limited support hours are looking for ‘backup’ coverage when their current support person is away or on vacation.
Several instances who pay support and looking for additional assistance on ‘thorny’ support problems/issues that require more in depth knowledge of the platform.
Some instances wish they could enhance the amount of support available and ‘go beyond the basics’ with users to include proactive support to assist more sophisticated users with things like integrations etc.

What is possible within current resources?
Some instances have successfully recruited support people from the instance user base - ie - identify and approach long standing or advanced users. This could be as volunteers or people paid with honouraria stipends. But this requires resourcing - not all instances have this.

Better option could be to develop a triage system for support, where the instance paid support person receives the user request, and responds if they are able. If they are unsure of the issue, they advance the request to a second support person (perhaps from a different instance). This second person either responds to the first support person, or directly to the user. If this second support person is unable to solve the issue, the second person seeks assistance more widely via slack and if needed, does some testing and creates a bug issue.

This support triage system needs fine tuning: where does this happen? (new slack? instance managers slack? direct contact?) should we/how do we track these issues? Is this triage system just for ‘thorny’ issues, or does it also ‘cover’ vacations etc of primary support people?

A ‘best’ option would be to have a global system (Vtiger or other for example) that all support people use, and perhaps all support requests come into one place. But we recognize this might take some time and more resourcing than we have at the moment.
Also uncertain - are we able to extend this triage system to instances that are not currently paying for support people?

Decision & Next Steps:
Hold a second discussion, inviting other instance managers who wish to attend to ‘fine tune’ a support triage system that uses slack communications for now.

  1. Mutualizing Communications Fuctions

What is Needed
We need a re-vamping of the global website - based on a new communications strategy. Its been at least 8 years? since we last reviewed this.

What is possible with existing resources?
We could pool some time to develop a strategy for updating the global site, and differentiating the purpose of the global site from instance sites. This could result in more efficient use of resources.

Decision & Next Steps
Everyone to think more on this, talk with instance staff, and reconvene to develop a plan.
Developing an inventory all the ‘project’ posts/pages from instances, to tell the story of global OFN, could be a good place to start.

Fellow attendees: @NickWeir @Serenity_Hill @dthomas @amber please modify or add anything I missed.

Next Meeting - January 15, 3:00 pm ET (GMT-5). Here is a zoom link.

2 Likes

Thanks for the update. I’ll come along on the 15th.

I plan to attend the meeting, thanks.