<aside> 🔈 At Stockly, communication between teams are handled through a ticketing system. Each team has its own ticket table with specifics but the global architecture is the same and most fields are in common. You can find here our organizational chart: ‣.
</aside>
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 field Reminder (See Fields) that's hidden. To set your reminder you need to display the hidden properties with ˅ XX More properties (See Image 1), then the Reminder field should be on top.
EmptyInclude Time (You may want to update the time format to 24 hour in ⚙️ Date format & timezone), and then input the time at which you need to do the taskNone ˅ at the left of ⏰ Remind and select when you want to be reminded
Some tickets requires validation from others Stocklers (ex. Team Leaders). Most tickets requiring validation have templates as Ban Supplier, however if you create a ticket requiring validation that's not a template you must add a section Validations 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 do not tag directly all validators. Notify only the first validator, when he validates the ticket he will change the mention of the next validator in a tag to notify him. The last validator will then pass the ticket in 0 - Pending Workforce.
Step 1: As part of the Tech team you need to implement a feature requiring the validation from @Elrendio (as Team Leaders) and @Eliott (as CEO), you will therefore create the section and tag only @Elrendio and mention @Eliott in plain text
Step 2: Once @Elrendio validated the ticket he will check his name and change the plain text Eliott Jabes into a mention.
Step 3: Once @Eliott validated the ticket he will check his name and set the ticket status to 0 - Pending Workforce.
Validations
Validations
Validations
<aside> ✋
You should not set a deadline unless
</aside>
Only one team should be the owner of ****a ticket. That team may request help from others but will still be the one accountable to the company for the issue being well-handled.
Yes! If a communication is complex, you can 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, you may re-open it. If not, it's best to open a new one. Your decision should also take into account the amount of data in the previous ticket: if a lot of information from previous ticket is required for the additional work it would be best to re-open it. As a good practice, you should avoid re-opening tickets that were closed prior to last week. (For example, if a ticket was closed on a Wednesday, you can re-open it during the following days. If it's the week after, you should open a new one.)
Using tickets grant many super powers, ie:
Before
Problems