...

• 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<$3,000000>.

   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)