<aside> 🔈 At Stockly, communication between teams is handled through a ticketing system rather than an instant messaging system. Each team has its own ticket table which includes specifics, but the core fields & table structure are common. This helps us handle requests more efficiently for all involved parties.
</aside>
❌ Example of a request sent on Slack ❌
✅ Example ticket for the same request ✅
Implementing a ticketing system has many advantages, including:
🙋 Ownership 🙋
Tickets are assigned to a single Stockler, responsible for resolving the issue. Clear ownership prevents issues from being forgotten and unresolved.
🔢 Priorization 🔢
Severity is a mandatory input to tickets, thus helping the receiving team prioritize issues by level of urgency. Details in Ticket Severity
📕 Context 📕
Tickets provide a centralized forum to gather information & notify all Stocklers pertinent to the resolution of an issue. Scrolling through Slack isn't ideal to gather info.
♻️ Templating ♻️
Teams often have multiple requests of the same type for one another. Templating allows for these to include all necessary inputs upfront to hasten its resolution.
👣 Roadmapping 👣
Tickets allow to track issue recurrence and resolution. This helps feed the roadmap of new features & processes.
Below is a description of Stockly’s key ticket fields and the table built to visualise them.
🔑 Key Ticket Fields 🔑
All Ticketing tables have i) a set of fields common to all tables, and ii) fields relevant only to the team’s specificities.
Below is a description of i), the common core of fields:
More details in Fields
⛩️ Table Structure ⛩️
Stockly’s ticketing system is built within Notion, which allows us to leverage all of our existing documentation and processes. All Ticketing tables at Stockly have the same skeleton structure.
At a glance we can already see which tickets have the highest severity and which Stockler owns them.
Sorting is both:
Pending Workforce on the left to Done or Dropped on the right.Thus the most important, least completed tickets appear on the top left.
Definitions
Structure of a Ticketing System
<aside> ⚠️ ‣ and ‣ pages should never say “please create a ticket in this table”. It should always be instead a button on which Stocklers can click and that automatically creates (and opens) a ticket in the correct table, using the correct template.
</aside>
You may refer to Fields to see which field you must, may or must not set.
Please read Ticket Severity
Most ticketing system have a hidden Reminder field (See Fields). To set a reminder you need to display the hidden properties with ˅ XX More properties (See Image 1), then the Reminder field should be on top.
EmptyNone ˅ at the left of ⏰ Remind and select when you want to be reminded
Only one team should be the owner of ****a ticket. That team may request help from others but will still be the one responsible for the issue being handled. If you’re unsure which team to select, please refer to ‣, or ask a more senior Stocker ☺️
Yes! If a topic is complex, you may go discuss orally with the other concerned Stocklers, spontaneously at the office or booking the appropriate amount of time in their calendar. But in the end, we must never feedback on a ticket something as short as “Aligned irl” or “Discussed orally”. The summary of the oral alignment and the clear output should always be written in the ticket.
Tickets are for bugs and recurring tasks to do, questions and other interactions. Feature requests are specific to the Tech team and will require product evolution. Feature Requests are basically the equivalent of weekly planning for other teams. If you're not sure between creating a feature requests and a ticket, please create a ticket.
If there's any additional work to be done on a ticket flagged as done there are two options:
If you know for sure that the Assignee still has in mind the ticket to be re-opened, or the relevant ticket was very heavy data-wise, you may re-open it. If not, it's best to open a new one. As a good practice, you should avoid re-opening tickets that were closed prior to last week.
Some tickets requires validation from others Stocklers (eg Team Leaders). Most tickets requiring validation have templates, however if you create an untemplated ticket requiring validation, you must add a Validations section on top of the ticket followed by a To-do list with each members you're waiting for validation.
While waiting for validations the status of the ticket should be On Hold and the Assignee should be the Ticket Creator. Please tag only the first validator, as they will tag the next validator themselves in order to notify him. The last validator is responsible for moving the ticket to 0 - Pending Workforce.
Owner: ‣ - ‣