Replicated Vendor Support Paths and Processes

Supporting your customers
, ,
1

Replicated Vendor Support

This document outlines key workflow points of engagements between
Replicated team members and our customers. For a video overview of these processes, see these recordings from Replicon Q3 2022:

Support Paths and Processes

Community

  • Community is a forum that is actively monitored by Replicated’s team of expert engineers and has many answers to common questions
  • This is the preferred location for asking non-sensitive questions, and you may find that your question may have already been answered here

Vendor Portal

  • Vendor Portal access

    • You will need an invitation from someone at your company who already has access to the Vendor Portal in order to join the correct team in the system to submit requests.
    • If you sign in using Google Authentication without an invite, your request will not be properly routed and you won’t have access to view it
      • If this happens, or If you do not know who to request access from, you can reach out to us in Slack and we can help identify who you can reach out to for access and we’ll get the request re-routed
    • Coordination and collaboration on requests submitted through the vendor portal will take place in GitHub – you’ll need to ensure you have access to your team’s shared GitHub repository in the replicated-collab org.

  • Submitting a request

Support Request Best Practices

  • Always attach a support bundle
    • This allows our support engineers to get the full picture and help find a resolution or workaround faster.
    • Sev1 Issues that include a support bundle have a 3x faster resolution time
  • If you are experiencing multiple related issues in the same environment that are captured within one support bundle, describe all of them in the original support request.
    • This allows our support engineers to work on resolving all of the issues together and helps us identify a root cause. Working on related simultaneous issues sequentially will result in a longer time to resolution.
  • If another issue arises while a support request is actively being worked on, if it’s not the same issue and/or is not captured in the original support bundle, please submit a new support request with a new support bundle.
    • This allows each issue to be fully captured and will allow our support engineers to effectively research the issue.

Tips for Working in GitHub and Receiving Notifications

  • Routing specific notifications to specific emails - you can control which email your notifications go to which email address here

|410.0908756967404x423.0337789890576
|410.0908756967404x423.03377898905761545×1600 290 KB

  • If you want to be notified of new issues and responses on issues, you can subscribe to all activity in the repository (or choose any of the other options as desired)

|624.5556544968834x353
|624.5556544968834x3531600×900 170 KB

  • If you want to ensure you get notified on all activity for a particular issue, ensure you are subscribed to that issue

|475x493.96738377441466
|475x493.967383774414661545×1600 311 KB

Escalation Severity Level Definitions

Severity Summary Definition Submission and Tracking
S1 Broken in multiple environments, widespread Replicated issue A suspected critical Error that: (1) renders the Distributed Software inoperative; or (2) causes the Distributed Software to fail catastrophically (system down condition); and (3) can be reproduced in more than one installation. Submitted through the Vendor Portal, tracked on the Inbound Escalation project in GitHub
S2 Broken in single customer environment A suspected high impact Error that materially restricts the use or performance of the Distributed Software; or (2) suspected error that renders the Distributed Software inoperative but the error cannot be reproduced; or (3) an issue that renders the Replicated Vendor portal inoperative. Submitted through the Vendor Portal, tracked on the Inbound Escalation project in GitHub
S3 Non-down issue in customer environment, or blocking issue in Vendor tooling. Generally, something is not working as expected. A Distributed Software Error that causes a minor impact on the use of the Distributed Software or a documentation error; or (2) an issue that materially restricts the use of the Replicated Vendor Portal. Submitted through the Vendor Portal, tracked on the Inbound Escalation project in GitHub
S4 “How do I” and other product integration questions, including “how should I prepare for a customer environment” **These are not blocking issues and will be reviewed by the team on a regular cadence. Submitted in Community or, for sensitive questions, the Vendor Portal. Tracked in Community, or on the Packaging Steps project in GitHub
FR Requests for new features or functionality Any request for enhancement or a bug fix in the existing product for the Replicated project team to triage and respond on. Submitted through the Vendor Portal. Tracked on the Enhancements: Feature Requests and Bugs project in GitHub

Slack

  • Our shared Slack channel will continue to be a resource for your teams, primarily to be used for:
    • Scheduling meetings or trainings
    • Non-urgent, non-technical questions
    • Issues or questions about system access (i.e. GitHub, Vendor Portal)
    • A general backup if other communication channels fail
4 Likes