The Cruz One Platform combines best in class technology tools into a cohesive communications and support system. The platform provides 24×7 access to information and ticketing system, and support during operating hours (TBD). The goal of the system is to provide streamlined access to support services while leveraging automation and knowledge sharing to provide economies of scale. Our customer base is potentially hundreds of users who require fast access to support provided by tens of support staff.
Requirements
Access to Support. Customers must be able to access support via phone, chat, email, web, and video.
Phone. For urgent situations, or when a customer does not have a working internet connection, they should be able to receive assistance via phone. Think about a teacher having a technical issue while attempting to conduct a learning session, or a student who is having trouble connecting to the internet. Phone access will hopefully be provided by Zoom using their new unified voice/video service. This would provide seamless communications between customers and team members, including call routing and queueing.
Chat for customers. For customers chat will be provided through the helpdesk software. By leveraging web based chat, the user needn’t download an application such as Slack, nor require on boarding to learn the application. In addition, there’s no concept of user accounts, we don’t need to hassle with licensing costs.
Chat for team members. For our internal team and those providing support, Slack will be used. Slack provides a free tier for unlimited users, the ability to use channels for group discussions, direct messaging between team members, integrations for alerts from other parts of the platform, and a non-public place to coordinate our efforts.
Email. Nobody needs another email address, yet many may wish to have some level of anonymity in not providing their direct email address. All team members can have access to an @cruz.one email address through GMail. Currently this would be provided via email forwarding through an existing business account owned by Cloud Brigade, but hopefully we can move this to a separate account provided by Google with free access.
Mailchimp. Normally used for marketing, Mailchimp is really useful for group communications. By automatically adding everyone we communicate with to our mailing list, and tagging contextually, it makes it super easy to send comms out to each/all group rapidly. We can also send automatic replies to avoid repetitive and redundant communications.
Web. A WordPress website was created to host the cruz.one website. WordPress was chosen due to it’s comprehensive list of plugins and third party SaaS integrations. More than a website, this portal will provide our customers with ease access to all resources behind a single login. Currently it’s ugly, but all the building blocks are there.
Video Conferencing. Zoom can be used to provide online classrooms for teachers and students, as well as one on one technical support including remote access. For example if a customer has internet access but is struggling with a computer or application issue, Zoom can enable the team member to see the problem and optionally take control of the remote computer to fix the problem. As a bonus, Zoom Phone provides a software phone client for team members to provide support via regular voice as well as switching to video.
Project/Task Management. Asana is great at managing, collaborating, and assigning tasks and managing projects.
Documentation. What we are building is no different than a business. In order to collaborate and track what we have done, and in the interest of providing a model for this type of situation, everything needs to be documented. Confluence is the best tool for this.
Workflow
Service Levels and Routing. While we are a volunteer organization, it is critical that are effective in our service delivery. In order to manage the dynamic load of support requests, as well as prioritize service delivery, we need to create a logical system to route and queue support requests, with an emphasis on self service. While we don’t want to create an access barrier to support resources, self service plays a critical role in managing the demand for support.
The Customer.
A routing system might look something like this.
- Customer visits website
- Fills out “I need help” form
- Creates account
- Self triage based on need/urgency
- Access to chat bot for self service/routing
- Bot attempts to point user to relevant articles
- Access to knowledge-base and ticketing system
- Non-urgent support can be provided through the KB
- Tickets can be submitted if no answer in KB
- Access to chat
- Chat system can queue customers who need real-time triage
- Tier 3 support reps can assess need and route as appropriate
- May feed back into ticketing system if lower priority
- Access to phone support
- Calls will be routed to an auto-attendant
- Queues can be staffed based on competency
- Access to chat bot for self service/routing
The Team Member.
OK, so what does this look like on the back end?
- Potential team members apply via form on website
- Moderator qualifies applicants
- Approves via WordPress (changes role)
- Zapier automation creates accounts based on role.
- All team members login to Slack (account can be added to their existing work slack app if applicable)
- Join relevant channels based on role(s)
- Support team members login to Freshworks (ticketing/chat/knowledgebase)
- Team members are assigned roles/queues based on their capability
- Support team members login to Zoom client (phone/video)
Tying it all Together
Operates like normal support organization
Just like <insert company here>, customers can receive efficient triage and get routed to resources based on need and priority. Multiple tiers of support staff can communicate with customers, collaborate with other team members using Slack as a back channel, and escalate customers to other team members based on competency and skill level.
EN_US 
ES