Support Policy
TL;DR
OVERVIEW & PURPOSE
This policy explains the support structure and processes in place for Licensees and their Sub-licensees. For definitions, please refer to the Licensee Mandate and any related addendum
SCOPE
All employees, contractors, consultants, sub-licensees, appointed providers, temporary and other workers within or outside of the Licensee’s organisation and its subsidiaries must adhere to this policy. This policy specifies the sub-licensing parameters and processes.
POLICY DETAILS
What is included in Licensee Support?
Direct access to an assigned tech team. This may include developers, engineers, support agents, and/or channel managers.
Access to support on GitHub. Selected members of your team will be given access to the relevant GitHub repositories where support tickets may be logged.
Ability to escalate from Resolve. You are the highest escalation point for tickets posted by your platform subscribers, appointed providers, or sub-licensees on Resolve. If you are unable to resolve an issue, you can further escalate it by posting to GitHub.
Documentation. Written and visual platform documentation is made available to subscribers and maintained by ED.
Support handling etiquette
Product knowledge. The Licensee is expected to be familiar with the platform and equipped to handle most queries not identified as errors.
Self-testing. Licensees and Sub-licensees are expected to exhaust internal testing and troubleshooting with subscribers and/or end-users before posting on GitHub. Licensees are encouraged to only escalate issues to ED when there is no documentation or training material available, or if a genuine error is suspected and all troubleshooting has been exhausted.
GitHub ticket adherence. Support ticket templates are provided in GitHub and assist the ED support team in resolving issues more efficiently.
Tech Role boundaries. The table below lists the various support roles and responsibilities. Please also refer to the Error Reporting Process & Etiquette.
Item
Assigned
ED Server Management
Everyday Digital
ED Platform Security Management
Everyday Digital
ED Platform & Server Monitoring
Everyday Digital
ED Tech Support (On GitHub)
Everyday Digital
ED Tech Rollouts & Upgrades
Everyday Digital
ED Platform & Tech Bug Fixing & Patches
Everyday Digital
ED Platform & Tech Documentation
Everyday Digital
Licensee, Sub-Licensee, Subscriber Support (On Resolve)
Licensee, Sub-Licensee, Subscriber Training & Onboarding
Licensee, Sub-Licensee, Subscriber App Deployments / DevOps
Instance Management (Accounts, Control Centre, Raven)
Non-platform support (email, Excel, user knowledge gaps)
Platform Operator Internal Support Team: Resourcing Requirements
Training Specialist. Platform Operators (in the form of Licensees and/or Sub-Licensees) are entirely responsible for training their subscribers/customers.
Support Contact. When a new subscriber account is created, the account’s Agent is made the default support contact until an alternative team member is added and assigned to the support role. The support role is responsible for managing all end-user and team queries. There are normally two options when it comes to assigning the support roles:
The Platform Operator may appoint a support person on their team and handle the subscriber’s end-user queries.
The subscriber is trained and enabled to handle end-user and team support internally, and chooses to appoint an internal support contact who will handle all tickets.
DevOps / Solutions Architect Consulting
Solutions Architect. In the absence of an internal tech resource within the Licensee/Sub-Licensee team, Everyday may on occasion or on request operate as the Licensee’s external Solutions Architect role. The Solutions Architect services may be accessed in accordance with pricing policies made available by ED.
Availability. The Solutions Architect is only available upon request and with prior notice.
The Solutions Architect role may include, but is not limited to:
Pitch and Scoping Assistance
Implementation and Integration Solutioning
Technical Consulting
Technical Sales Guidance
Technical Documentation
Platform Security Consulting
Platform Infrastructure Consulting
Technical Policy Development
Implementation Guidance
Integration Guidance
API Guidance
New Feature Implementation
Bespoke Feature Development
Licensee technical support and error handling
Innovation Investment
Any other services/attendances which may be agreed to between the parties
Resolve Ticket resolution process
Who submits tickets? Anyone who is added to the “Team” on the account-holder’s platform can submit support tickets via the Resolve tool. End-users do not use Resolve to submit tickets.
Escalation of Tickets. The escalation works as follows: Team Member ➼ Support Role ➼ Sub-Licensee (if applicable) ➼ Licensee ➼ ED.
Subscriber escalates to Licensee: When a platform user submits a ticket, it is automatically escalated to the Licensee’s account (as well as to anyone who has been assigned the support role). The Licensee & the support contact will be alerted via email and a platform notification and can respond via the Resolve chat.
Licensee escalates to ED: In the event that the support role can not resolve an issue, they can escalate to the Licensee. An account that has been appointed to a Sub-Licensee can not escalate directly to the Licensee.
ED Support Hours
ED will provide technical support via GitHub and via meetings that have been scheduled. GitHub tickets will be responded to Mondays to Fridays during the hours of 09.00 to 17.00, South African Standard Time (SAST).
ED Support Levels
Level 1 Support (Resolve a Ticket). Licensees are responsible for Level 1 frontline subscriber support and are responsible for all platform users and end-user assistance, including the handling of any queries related to activation and deployment, user issues and general maintenance of the platform/service. Licensees are encouraged to include training and support solutions into their service offering to the subscriber to cover support-related costs.
Level 2 Support (Escalate a Ticket). Escalations of tickets to ED in the event that you require deeper technical or product assistance to resolve a user query/ticket and/or error. Level 2 Support will only be provided to the Licensee.
Support Restrictions
External issues. ED does not support any issues that are due to: connectivity/ISP provider issues, email issues, third party software, subscriber and/or end user incorrect app use, custom requests and/or custom scope work.
Custom requests and consultations. As a rule, Licensees should aim to sell the platform as-is. When additional features are requested or integrations are needed, this goes beyond the role of the Licensee and would require intervention, consultation and potential project scoping for a custom platform instance.
Where the Licensee requires ED’s engineering and product team to engage directly with their subscriber or their implementation team to handle a custom request and/or technical consult (for example, security consult, feature request, etc.), this will be billable at the hourly Dev Rate outlined in the most recent pricing.
Issue Levels and Resolution Times
ED determines the severity level and resolution lead-time of issues reported by Licensees, as follows:
Enhancement. No user is affected but an enhancement may be favourable ➼ expected resolution time is at the discretion of ED.
Low. Affects a low amount of users or is not app- or platform- breaking ➼ expected resolution time is 5 - 10 days.
Medium. Affects a minority of users or is app- and/or platform-breaking in isolated, specific scenarios ➼ expected resolution time is 3 - 4 days.
High. Affects a majority of users or is app- or platform-breaking in a majority of scenarios ➼ expected resolution time is 1-3 days.
Severe. Affects all users and is app- or platform-breaking in multiple cases ➼ expected resolution time is 1 day.
Supporting End-Users
End-users are the platform subscribers/customers and app users. The subscriber may have been enabled/trained to support their own users, or the Licensee can offer to support their subscribers’ users.
The Licensee and their subscribers/customers should work together to decide on a solution of how users will be supported. This could be through a contact form, phone number or third party ticketing system. Any issues that can not be resolved, can then be escalated by the subscriber to the Licensee and by the Licensee to ED, as needed.
ED may offer a public-facing, regularly updated user knowledge base to assist with troubleshooting and FAQs.
Handling feature requests and custom requirements
Feature Request. This can be any request submitted by the Licensee to ED for a platform feature change or new feature development. Such a request will need to be scoped and scheduled into production at the discretion of ED and based on ED’s current roadmap and capacity. Feature requests will typically include an implementation fee and/or a development cost over and above the monthly Licensee fee.
Custom Request. This is a request that is related to a single subscriber’s specific need. For example, a subscriber wants a certain feature that will not be adopted across the platform. A scoping fee (billable per hour - see Pricing Policy) will be charged to the Licensee for the handling and evaluation of custom requests.
Error Reporting Process & Etiquette
Step
Details & Etiquette
Issue State
STEP 1: Reproduce & Information The issue is reproduced and further information is gathered from the affected party/ies in order to facilitate debugging.
The platform operator handles initial troubleshooting and debugging internally and with the affected user/s.
Error Confirmed
STEP 2: Report
A ticket is created on GitHub wherein the issue is described in detail.
ED Support Contact is assigned, and a label is attached to the issue.
The platform operator submits screenshots, videos, and details on GitHub.
No personal details are to be included (privacy breach).
Pending Evaluation
STEP 3: Evaluation
Issue is evaluated and the level of severity established.
ED responds on GitHub and indicates if further details are needed.
Severity level is established.
Labels are used to further define the issue.
Evaluated
STEP 4: Scheduled Issue fix is scheduled by ED based on severity.
Implementation is dependent on the issue severity level assigned.
Scheduled
STEP 5: Testing & Staging Issue fix is tested on staging environment or released immediately.
Depending on the nature of the fix, it may be released to staging first and tested in beta prior to a live release.
QA Testing
STEP 6: Release Issue fix is released to live environment.
This may require app updates.
Close
Custom Request Flow
Step
State
Feature Request The platform operator receives and evaluates subscriber request and creates a detailed brief and posts a ticket on GitHub.
Open
Evaluation
ED evaluates the brief and responds with an estimated scoping time and cost.
Evaluated
Scoping Initial fees are accepted by the operator and the scope is workshopped to define a brief. Relevant stakeholders may be included.
Pending
Development Scheduled ED provides a cost estimate and schedules development. The custom request may be considered under Dev Bandwidth depending on the nature of the work.
Scheduled
Testing & Staging The custom feature is tested in a staging environment and released when all tests have been passed. The Licensee handles support directly with the subscriber and escalates to ED.
QA Testing
Release & Monitor
The custom feature is released and monitored for issues before being closed.
Monitor & Close
Last updated