Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Creating ShelterBuddy Engineering Requests

Note: Before escalating, consult the Escalation Matrix and Known Non Solutions policy before introducing a ticket to ShelterBuddy engineers.

https://shelterbuddy.atlassian.net/wiki/spaces/PLP/embed/2865102852

If a ticket helps all customers: escalate

If a ticket provides critical support to a customer: charge, escalate, and discuss

If a ticket is a “nice to have” for a single customer: follow Known Non Solutions link above.

Start in the ticket, then go to Jira in the lower-right to make sure the two tickets are connected.

Hubspot-Integrated Fields

  • Project: Always “Shelter Buddy (SB)”

  • Issue Type - Options: 

    • Bug - An expected function of the software isn’t performing as it should, and it’s clearly something that both we and the customer expected to provide for them as part of our service.

    • New Feature - Feature request for functionality that does not yet exist but would benefit the customer. Please note, for 99% of these, they should follow the Known Non-Solutions procedure and not interfere with the devs regular activity (aka, try not to use this)

    • Task - This is an expected function of the software that can only be done by internal Pet Loyalty staff. (example: Kennel card customizations)

    • Improvement - Request for improved functionality based on existing features that would benefit the customer. Please note, for 99% of these, they should follow the Known Non-Solutions procedure and not interfere with the devs regular activity (aka, try not to use this)

  • Summary (This is a Title): “[Shelter Name] - [Summary, <8 words]”

  • Description - detailed description. Include items like URL to the page where the problem is going wrong, steps to reproduce the problem.

  • Reporter - who is submitting the ticket. Put your name here unless submitting on behalf of another PL employee. Be advised that if a non-CS rep is the reporter, then dev may not recognize the request as having come from CS.

  • Attachments (file upload) - Screenshots or other data where necessary.

  • Sync Notes and Comments - Yes. This helps devs get context about the ticket.

Jira-Only Fields

Next, click on Jira Ticket attached to the ticket to complete the submission

  • Priority: MAIN detail. Jira priorities are different from Hubspot.

    • High Priority in Hubspot = Critical in Jira. This means that the issue is causing the shelter to be unable to operate.

    • Medium Hubspot Priority = Must Have in Jira. This means that the issue is preventing key ShelterBuddy functionality, like loss of a feature or a bug.

    • Low Hubspot Priority = Normal or Nice to Have in Jira. Normal is slightly higher, so use your judgment and pick which you prefer.

  • Labels: This will expand as we use this system more. For now, there’s only one label we use

    • support-priority - Use this only for Critical or Must Have tickets.

    • data-migration - Use this for onboarding shelter data migration requests.

  • Due Dates (new functionality to be switched on by a certain date) - Only use this if there’s a defined, hard line deadline from the customer. Should probably be limited to “Must Have” tickets and customers with a set onboarding deadline.

  • No labels