Creating ShelterBuddy Engineering Requests

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

Open

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.

• Assignee: This will be left blank, when an engineer picks this ticket up they will assign it to them selves. When a ticket requires another person to help (say for testing or to answer questions) then the ticket will be assigned to the other person (or a comment will be left tagging the required person in).

• Status: The ShelterBuddy Support board has the following columns and statuses on the board:

  • Backlog: These are tickets for the team to work on and is a combination of CS tickets and general technical tickets that engineering have created. The CS tickets would be prioritised by the CS team so that engineering knows which ones they should move to next.

  • Next: These are tickets in the queue to be worked on next. The board is prioritised automatically using the priority field on a ticket, so the highest priority tickets are at the top of the next column.

  • In Progress: These are tickets that are actively being worked on by engineering.

  • In Test: These are tickets that require testing from the CS team, they will be assigned to someone to test. When a ticket does not pass testing the ticket will be given the status “in progress” and assigned back to the engineer that asked for the testing.

  • Pending Release: When testing has passed the tester will select the status pending release and assigned it to the engineer that asked for testing. This means the ticket passes QA and can be released to customers.

  • Done: This means the ticket has been completed, and ready for the next release of ShelterBuddy.

Minimum Criteria

Before escalating for custom development, please consult these steps:

1. Multiple Shelters: First, identify if the request benefits multiple shelters or just 1. If just 1 shelter…

   1. If the bug or request doesn’t provide critical functionality, politely let them know that we’ll add this to our engineering backlog, but we cannot provide a time frame and it could be over 6 months.

   2. Even if not a bug, is the request something that a reasonable person would think is included in their agreement with us?

2. New functionality: Is the feature an approved feature? Current “no-go” list of features we avoid investing in

   1. Boarding

   2. Online Licensing

   3. VolBuddy (Confirm?)

3. Minimum Price / Preserving Our Price Integrity: If the request is a custom development quote, convey that our minimum for these contracts is <$3,000>.

   1. After the first 10 hours of development time, additional development time is $250 per hour. If the customer agrees to these minimums, then we can have devs scope it for a more accurate estimate on total hours.

4. Admin Actions / “Wow” moment for customers: Quick Fixes versus Show Stoppers: (comparing to Adopets Process External Adoption Category)