GitLab Incubation Engineering - Latest, 9 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Incubation Engineering - Service Desk - Update 1

Description

This is the first update video for the GitLab Service Desk Single Engineer Group. Marc walks us through his vision for Service Desk and explains his first steps in iterating on custom email addresses on a per project basis.

You can find all resources on the Service Desk SEG handbook page :
https://about.gitlab.com/handbook/engineering/incubation/service-desk/

Please subscribe to this GitLab issue if you would like to receive notifications for all future updates:
https://gitlab.com/gitlab-org/incubation-engineering/service-desk/meta/-/issues/3

Additionally you may have a look at the feature exploration issue:
https://gitlab.com/gitlab-org/incubation-engineering/service-desk/meta/-/issues/2

If you want to learn more about Incubation Engineering at GitLab, please visit
https://about.gitlab.com/handbook/engineering/incubation/

Chapters
0:00 Intro
0:16 SEG Vision for GitLab Service Desk
1:37 How E-Mails are used in GitLab
3:34 E-Mail problem summary
4:10 Custom E-Mail Address Solution Path
5:05 Outro

A

Hi, my name is Mark and I'm, the single engineer group for the gitlab service desk and you are watching update number one.

A

So, what's the vision for the gitlab service desk, we want to provide a complete yet lightweight and customizable customer support solution that brings customers, customer support staff and developers closer together and that all deeply integrated into the gitlab ecosystem. So what does that mean Complete? Because it has all the features you need to leverage high quality customer support lightweight, because we will focus on shipping a core product that you can enhance and build your solution around it. For instance, we support email as a support center now and may offer API endpoints later on.

A

So you can build any multi-channel solution. You will need it's deeply integrated, because service desk tickets are just gitlab issues with added functionality, so you can use all the good stuff your developers and managers love today and with our private nodes integration, you can even collaborate on a service desk inquiry with your fellow software, Engineers managers and designers.

A

Your team can also use the service desk issue as their Sprint items or on kanban boards, and the customer support agent may send an answer to the customer after engineering ship their work, so I will work towards that vision and I decided to start with integrating custom email addresses into service desk gitlab uses three different email addresses or mailboxes to an all email related services for gitlab.com. This is the default email address that we use to send all outgoing emails like notifications and admin stuff.

A

It's the incoming email address, which is a mailbox, the digital app uses via IMAP or Microsoft graph to fetch emails that append notes to issues and other work item types. You can also use it to add new issues, but that's not in the scope of service desk the service desk email address, which is also a mailbox that we access. We use that to ingest service desk inquiries and create a new issue from that below is a very long example from a service desk test project. I use here you see the automatically generated. Thank you message.

A

Gitlab sends out after I submitted an inquiry via the service desk email address. You can see it was sent from the default address and the reply to address is the incoming email on a self-hosted instance. You also need to set up all three inboxes in order to make service desk work. Here you got a little more freedom, but you won't make it to a fully custom email address for your service desk project. Right now you may use any sort of default address in this case.

A

Gitlab mail.whatever.com, you might configure the incoming email address as gillib does so you will have a single mailbox that uses email sub, addressing that is a virtual Alias, where you may append any sequence of characters after a plus sign and all emails to those addresses will still land in the main mailbox.

A

Many providers support that feature in gitlab relies on that functionality to make email ingestion work. You can also use a catch. All email address that you configure for a subdomain where all emails to that subdomain land. This way you get a shorter service, desk email address.

A

So what's the problem with this current implementation? In a nutshell, it does not support for fully customized and professional email experience throughout the communication with the customer you can add email forwarding from your custom email address to the cryptic service desk email address, but the customer will always receive answers from the default instance address, and the reply to address will always be the incoming email address.

A

This is especially a showstopper for gitlab.com customers, as they don't want to have gitlab email addresses in their customer communication.

A

By sticking to our value of iteration, I propose a solution path where we do not have to change a lot on the existing functionality. When email forwarding is configured correctly, your customers can send inquiries to you via custom email address that works right now too.

A

We could then ask you for that custom email address and its SMTP credentials, so we can send all outgoing emails via those settings, so we would use your SMTP server to send email actually. Additionally, we could alter the reply to address and use your custom address and add the issue hash to that, because your custom email forwards to the service desk mailbox. We can then read the replies and add new nodes to existing issues.

A

I was able to prove the concept of my local machine and will start the implementation shortly still a lot of work ahead, but I think the direction is clear if you're curious about the progress make sure to check out the service desk, single engineer, group handbook page or subscribe to the update issue, everything is linked in the video description.

A

Additionally, there is a feature exploration issue in the service desk meta project that lists a lot of ideas derived from feedback and existing issues. So this is it for today take care, see you soon.