Trouble Shooting: Support Tickets

Owned by Patrick Sayegh
Last updated: Mar 13, 2024
2 min read

At the end of the day, we should take the time to really investigate into the ticket, as this will help us understand the issue, how something works and allows our engineers to focus on other priorities. This will depend on urgency of course, as if something is urgent(duplicate orders, shipping requests etc.) then this needs to be sent to an engineer right away.

Below will walk you through some rough guidelines to help you with ticket work:

 

  1. New ticket comes in

  2. Understand what the request is

    1. This isn’t always so simple, as merchants don’t always give us enough context

    2. Do your best to work with what you have and if it helps, write it out as an internal note in your own words

    3. Each issue that comes in, is never the same type of problem. They can look like that, but Pipe17 is customizable to each merchants use-case.

  3. What is happening?

    1. Dive into the merchants org to try and see what their issue is

    2. Can you replicate?

    3. Do you see the same behaviour they described?

  4. What is expected?

    1. How is this supposed to work?

    2. What is their use-case?

    3. What connectors are they using?

🚨 Its good to write out their flow, setup etc. This can help with digesting the issue, and allow you to see things more clearly when trying to see what is currently happening as its not always obvious.

  1. Deeper Dives

    1. What does the events say?

    2. Does the connector settings look good?

    3. Was there any recent changes done to their site?

    4. When did it work last and what did that look like?

    5. What does the JSON show us?

    6. What does DataDog tell us?

    7. Can you leverage Bernard to understand more?

  2. Next Steps

    1. When you have exhausted all your resources, and nothing seems to be lining up you need to know when you should create a bug VS when it should be a general question

    2. Bug: When something is not working as expected, and there is no explanation for it, it can be safe to say this might be a bug

      1. It is okay if you are wrong here as well, as engineering might be able to see things we can’t - so its good to also learn from them. Just please be sure to provide as much information, what you tried etc.

    3. Slack Question: This is more for “gut checks”. You need a second pair of eyes to help you understand what is actually expected VS what is currently happening. Sometimes, this will lead to a bug ticket - but not always.

  3. Handle Time

    1. This can vary, but try to always aim for 1.5 - 2 hours per ticket

 

There is no perfect way or a specific formula when it comes to troubleshooting. The best way is to really break things as much as possible, and to not be afraid to be wrong. Also, if you need more information please don’t hesitate to ask the merchant for more context and examples - but its good to do what we can before doing so.