Service Desk with email

/cc @dzaporozhets @JobV

Added ~139512 label

Added ~139607 label

So this would send an email on every issue update, in that case? (this is how fogbugz does it)

Do we want to have the ability to not send out emails to the third party on every update?

@JobV yes, send an email on each update, like ZenDesk. I think you need the ability for private comments.

BTW This feature request is many months and probably more than a year out.

Sound cool. Can someone who familiar with Zendesk and GitLab explain a concept?

@dzaporozhets

people email support@gitlab.com
this opens a confidential issue on GitLab the whole team can see
we can comment in private or in a comment visible to the customer (in the last case they also get an email)
customer can respond by commenting online or via email (both visible in the issue)

This prevents duplication between ZenDesk and issue tracker.

@sytses sounds pretty cool. However it feels like a lot of work (basically we implement own zendesk inside GitLab). If it would be only us I rather make integration with Zendesk instead. I am wondering how many customers asked for this.

@dzaporozhets this is far out and a major change. There is no customer demand for this yet so we shouldn't start it but I wanted to have it on our radar.

@sytses cool. Lets see of there will be some demand for it in future.

This would be competitive to https://www.atlassian.com/software/jira/service-desk

Added ~698702 label

I think an email to issue gateway would be pretty neat, but I dont think gitlab needs to be an email server. Instead have the gateway be an email client that inturn will create issues based on rules and templates. Modeling the JIRA email handler would be of interest too.

Thanks @tom.davidson

Another interesting approach is https://boardthreads.com/ that also uses an issue board to do this.

They use the icon in case a message needs to be emailed to the end-user, very smart.

Added ~413002 and removed ~698702 labels

JIRA Service Desk in particular, in its second full year of availability, achieved a scale we’re incredibly proud of and today has over 17,000 organizations using it. (source: https://s2.q4cdn.com/141359120/files/doc_financials/2016/Q4/Atlassian-FY2016-Annual-Report.pdf)

I've played with JIRA Service Desk and I expected to find a much more complex product than what I've actually seen.

To create a complete service desk, we need 4 components that address:

How customers send the requests (email, dedicated support page,...)
How we work on issues (custom views, special filters,...)
How the support team is doing (SLA, reports)
Overview of customers (statistics, history,...)

Obviously we can't build that kind of thing in one shot.

It's also interesting to note that when you subscribe to JIRA Service Desk, they try to convince you to also take a subscription to Confluence .

MVP

For the MVP, we can start with something relatively simple like the one @sytses suggests above. This is what we need:

A new user attribute (not a new permission): User Agent, that allows someone to respond to a customer or close a service desk issue.
A new functionality: private comments (only visible to the team)
A new settings page in the admin panel to set the email address tickets will be sent to, and the project where the issues will be created in.
A new email template, for the email sent to the customer informing we have received his feedback.
A way to let customers interact in the private issue, without being counted as a seat in the instance

Mentioned in issue #1182

Related issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/18067

@victorwu we are investigating this. It will have an impact on discussions.

I've tried to keep things as simple as possible and reduce the amount of change required for this to happen. If we don't want to mess with the User and Issue objects, and allow customers to interact in an issue without being able to view the code, we have to create a new permission type. Can you review and tell me if you see something I could have missed? Thanks.

Thanks @regisF. I can't comment too much about the technical nature of the User and Issue objects since I don't know it very well yet.

As for the functionality, could you outline what user flows would be achieved in the MVP release? I read the system components you are proposing. But could you tie everything together in a flow, which users are involved, etc. so we could get a better picture of the problem being solved?

mentioned in issue #1427

@victorwu I've added more context in the flow.

I've also changed the scope a bit.

The initial specification allowed the customer to go to GitLab to discuss in the issue. But that creates too many changes in the application: we need a way to let this customer see and comment only his own tickets (and nothing else), while not being counted as a seat in the instance.

This new proposal still requires changes, but are less drastic. Once we agree on a flow, I'll create dedicated issues for each step of the flow.

Looks great @regisF .

Are we going to use this to support EE customers? Who are the first users for this feature?

The first iteration that is MVP (i.e. usable) can literally be just 1. as you've described. Operationally, you just need to set up a dedicated project with the right permissions.

So when an email is sent in, an issue is created in that specific project, and the system just copies the email headers and body into the issue title + description. That's the only thing you really need to make this feature work. I'm not sure that would be powerful enough for even medium sized companies. But at least we get it out there. And for a small company that doesn't want to buy ZenDesk, by buying EE, they have this really dead-simple way of scanning through all support requests. So this could be useful enough for them. And of course we build on this to make it more powerful, increasingly automating more of the manual steps, etc.

With this approach, you don't have to worry about setting up permissions, etc. in the first iteration. You just get something out there and learn from feedback before making all the subsequent detailed designs of how the flow would work.

@victorwu I've thought about that too, but we still have the same problems even if we choose that route. So I don't see how that simplify things - I think it's actually the same, if not harder.

we need a new email address to send issues to
the author of the ticket shall not count as a user seat
we still need the customer to read our comments by email
if we don't want to change the system too much, we should not invite customers to participate in GitLab directly, so we need to send emails that do not contain the link to the issue when a comment is made on the issue.
the changes in the code will have to be made at the project level then, which is the same as changing the issue instead.

I agree that for the MVP we don't need private comments per se, nor the sidebar changes (I've updated the issue to reflect that).

@regisF

For the end user who is sending the email and requesting the support. Their experience is not impacted at all:

(1) An end user sends a request email. They get a response to the email. It may go back and forth. But the user lives in Gmail/Outlook/whatever and nothing matters. This is fine. I assume in the MVP, we are not innovating on this aspect, or improving the experience of the customer experience.

(2) On GitLab's side, I agree we just need one dedicated user that the system uses to author the issues. For a first release, this can just be the default system admin. So that solves the user count problem.

(3) All new emails that come in from the customer automatically create new issues in that dedicated private GitLab project. On the GitLab side, that could be messy, because one email thread results in multiple issues if the end user sends in multiple emails. But that's okay for an MVP

(4) On the GitLab side, people can organize the issues together however they want. It is manual, but at least they have existing powerful features of labels, assignees, etc. So there will be workflows that support staff can create manually. This is actually good because it will give us feedback on how support people use this.

(5) On the GitLab side, people comment on issues as usual, collaboration happens within the support staff and engineers, etc for that company. At some point, they are ready to respond back to the customer. In that case, somebody has to go back to a dedicated email client, and then respond to the customer directly through email. And they can manually copy and paste their response back into the GitLab issues.

This seems like the least system-disruptive MVP. (You could argue that it's such a bad experience on the GitLab side it's not good enough.) But I would say those are all acceptable, because you can leverage the powerful features of labeling and assigning and due dates, and weights, etc. And then later on, with subsequent releases, you solve / automate away (3) , (4), (5), and add more bells and whistles.

Wouldn't this implementation just require a new system module that takes emails, parses them, and then create issues using the GitLab API? I assume this would be a simplest code implementation. Of course let me know if I'm not right!

Thanks @victorwu for the constructive feedback.

(3) There is always, in every support case, a back and forth between support agent and the customer. One issue per comment would be unmanageable to follow the discussion, and on this case, make following the process from issue to commit and push to production impossible - which is against our selling point of having an integrated flow.

Moreover, if the customer presses the reply button, GitLab already parses the email and puts the email as comment in the issue.

To sum up

We use one project as the "service desk"
- (new feature) Each project gets a new email address to act as a service desk
We create one confidential issue per email sent
(new feature) The issue's author is the default instance admin
(new feature) The issue body contains the name+email address of the sender
Subsequent emails on the same issue will be added as a comment

Then we ship this, market it, take feedback and iterate.

@victorwu actually there is one problem with this. I forgot about it.

The customer needs to receive all comments made on the issue. Therefore, we still need to set the author's email as being the customer's email, without being counted as a seat.

The customer needs to receive all comments made on the issue. Therefore, we still need to set the author's email as being the customer's email, without being counted as a seat.

I think this is one of the main arguments to be had. I totally agree that this is a good feature and an obvious flow. But do we really need it as an MVP? Could we not just have whoever is commenting also use a separate email client to respond to the customer? If that's a non-starter (for whatever reason), then I agree posting a comment should just fire back an email, and therefore, the comment thread should essentially just mirror the email thread from the user's POV. (Which in essence, we are cloning ZD, which of course is probably the right solution, since this is a solved problem.)

@victorwu back to this.

If a customer can't receive the answer by email when a comment is made, I think it's a non starter. That means communication would happen in two places (emails and GitLab).

@regisF: Sounds good. Thanks for sharing that context!

changed title from Handle incoming emails with support questions in issues to Use GitLab as Service Desk incoming emails with support questions in issues

added ~874214 ~91796 labels

changed title from Use GitLab as Service Desk incoming emails with support questions in issues to GitLab Service Desk

added ~333913 label

@smcgivern could you read the issue and let me know if this is achievable in one release, or if we need to cut through the fat even more?

mentioned in issue #1490 (closed)

This would be a great feature addition - I've worked with a lot of different helpdesk software over my career, and a simple, lightweight service desktop solution integrated with gitlab issues would be a great addition.

As mentioned above, I would expect:

the ability to create an email alias for support@domainname.com that gets delivered to my gitlab service desk.
gitlab reads email and opens a ticket on behalf of customer, creates a customer record based on email address and name if none exist, otherwise it associates new ticket with existing customer
support engineers can view open issues, assign to themselves or others, and make a comment or note. Comment should update and email out to all involved parties including customer. Note should be internal-only comment that does not email customer
any customer replies to email out of service desk should be captured and properly threaded -- probably based on an x-header in email
a way to merge tickets together if multiple tickets exist for same issue
a way to merge customers if multiple customer profiles get created for same customer
a way to manually enter a service desk request if it comes in via phone or comments in other email
some basic metrics on ticket aging, ticket volume, ticket closing by "agent"/user
a simple way to reference gitlab tickets or issues and see a visual representation of whether ticket is open or closed when page is rendered. This should create an entry in the corresponding gitlab issue tracker as well for cross reference that will show if service desk request is open or closed
ability to spawn an engineering issue from a service desk request and tie them together
service desk screens should refresh if someone adds comments or assigns ticket to themselves

Hope my input helps!

Thank you for your input @ross.campbell There are some great points in your analysis.

@regisF thanks for scoping this down! For now, I'm just commenting on the MVP above:

However this email address is specific to a user, so we can't use this.

Couldn't we use that email address as the Support user sees it? Then we don't need a new concept for this part.

The author is a generic account, Support

this account is created the first time a ticket is received

https://gitlab.com/u/Support - how would we handle that? Maybe we should ask users to create a user with a no-reply email address, and configure that as the support user for the project, instead?

Two new metadata are added to the issue: name+email (both taken from the sender's information)

This, and the notification changes around it, sounds fine.

Private comments

I really don't want to do this - at least, not yet https://gitlab.com/gitlab-org/gitlab-ce/issues/23436 But we can leave it out of the MVP.

So my proposed change for the MVP is this:

Each project can have a support user set.
That user's private issue creation email address will be shown in the project settings to people who can admin the project, so we should make it very clear it shouldn't be someone's personal user.
That user should also not have higher than Guest permissions, so that they can't use slash commands in the email.
When an issue is created by email on that project for that support user:
- We make it confidential.
- We store the sender's email and name (from the email) in new columns on the issue itself.
- We send comments, but not other issue changes (assignee, milestone, labels, etc.) to the email on that issue, without linking to the issue.
- The support user still gets all the emails as normal, which is why it should have an unused email address for its notification email. Any other participants in the issue receive emails as normal, too.

How does that sound?

Thanks @smcgivern for your input. I just have one additional question.

Each project can have a support user set.

How do we define it? A checkbox in the user creation page, indicating that it's the support user?

@regisF I think the user shouldn't be special except within the context of a project. So the users table wouldn't have any changes, but in the project settings you could configure the service desk with a user account to use for this case. Does that make sense?

@smcgivern makes sense. I'll update the body of the issue.

I'm not trying to be rude — and I might have misunderstood the latest proposal — but this doesn't sound like a very useful "Service Desk" to me. I'm aware that this is just for the MVP but in my opinion the user needs to be able to comment by email and in the browser (e.g. GitLab interface) in some way (and also see the issue thread). Otherwise it's just a "new" way to create issues by writing an email (and you can already do this right now if you have an account and access to the project). Since this is for EE Premium, I would be willing to buy EE Premium (e.g. through the announced silver package) just for a solid Service Desk in GitLab. Currently, I have to pay for Zendesk / JIRA Service Desk just to have this functionality, anyway.

@mrksbnch thanks for your comment. I agree that this is a very basic approach - but that's exactly the goal. Ship something as fast as we can, then iterate upon it. If we aim too high for the first iteration, we'll never ship it in time. We've done this for all the features in GitLab that were primitive at first, and we've made them powerful over time. We'll keep doing that. We think it's the right way of shipping softwares.

changed milestone to %8.17

changed milestone to %16

added ~126459 and removed ~139607 labels

@awhildy can we get UX love for this feature? Thanks! There is just one small setting to design.

I've talked with Marin about this feature. It appears that the current solution we use to process incoming emails (https://github.com/tpitale/mail_room) has a lot of technical debts attached to it and infra/packaging teams would like us to reconsider changing it for something else.

The thing is, what else? We need to investigate.

@smcgivern does this gem fall under Discussion?

@hazelyang - can you help @regisF out with this? Thanks!

@regisF I'd say so, yes!

@awhildy Sure! Will do.

Uncheck Service Desk

An idea: I think we can hide the further information(the support user and email address) if the Service Desk is unchecked. It would make the project settings page look clean and reduce the unnecessary information when people don't activate Service Desk.

Check Service Desk

assigned to @hazelyang

@smcgivern so, do you think we need to refactor the way we treat incoming emails in order to ship this new feature?

Thanks @hazelyang for your work! I've updated the body.

@regisF you mean omnibus-gitlab#1363 (closed)? I wasn't really aware of this, but I agree that we should fix this before encouraging more incoming mail.

Oh wait, maybe it's not a strict blocker. But I think it's safer to do omnibus-gitlab#1363 (closed) first, if nothing else. @marin does that make sense to you?

@smcgivern if we do Service Desk, we'll put much more pressure on the incoming email support, right? We need to make sure that what we currently use will work with a much bigger (potential) volume. So now we need to make sure that it's a non strict blocker.

@smcgivern It is not a strict blocker but please if at all possible, lets try to resolve the technical debt before we build on top. Pretty please :)

OK, let's talk in that issue!

removed assignee

@victorwu as the feature has not been planned yet, I'll let you decide where it falls under your roadmap for Discussion.

@regisF: Do you mean you want to pass this to me given your immediate transition to Edge? If yes, just update the description to me, no problem.

@victorwu exactly. Thanks!

@victorwu to provide some context, the service desk of JIRA is now their fastest growing product ever.

Consider making this issue a bit more manageable by specifying individual changes that should be made to GitLab (and can be merged separately).

This might be very useful and a very interesting EE Premium feature.

added ~1012342 label

I'd really love to get the GitLab support team (@gl-support) involved in the feedback cycle for this feature, as it develops. I'm sure we can provide some valuable feedback

Thanks @MrChrisW : Let's chat

@regisF @JobV : I assume that many companies who need a support solution would just choose a product like ZenDesk. So our initial target market is companies that are already using GitLab? And so we can pitch this to them as an integrated solution into GitLab issues and projects? I assume this is a similar strategy taken by JIRA SD? Is this the general direction / thought?

So perhaps the initial use cases can be more focused on nailing the integrations into GitLab itself.

@MrChrisW in order to provide valuable feedback, we would ideally need to use it or at least plan to use it. Would it be sane to target a subset of requests, like GitLab.com users and try to move them to this?

I can't imagine living without our current web form and the information it gives us.

Could we start by building a web-form first that sends all requests to ZenDesk and then we have the power to route them here?

I could see immediate value to the customer if they did not have to fill their username or email address into the form because if they are signed in we already have it.

@smcgivern @hazelyang Does it make sense to build in an email option in the comment thread itself? As part of first MVP? Support staff would comment in the issue. But next to each comment you can click a button to fire off an email response to the customer. So support rep has more control, but not have to re-invent everything.

@smcgivern Is email sending in GitLab stateful? Would we be able to know which emails were sent (attempted to be sent)?

So our initial target market is companies that are already using GitLab? And so we can pitch this to them as an integrated solution into GitLab issues and projects?

@victorwu this is the general direction and this is why, I think, JIRA SD got so popular (the integrated experience).

@dewetblomerus the goal is not to let them sign in at all to the instance, because we don't want to count them as a new seat. Can you provide details about what the form currently asks for?

@smcgivern @hazelyang Does it make sense to build in an email option in the comment thread itself? As part of first MVP? Support staff would comment in the issue. But next to each comment you can click a button to fire off an email response to the customer. So support rep has more control, but not have to re-invent everything.

@smcgivern Is email sending in GitLab stateful? Would we be able to know which emails were sent (attempted to be sent)?

@victorwu the MVP is to always email on comment, so this would allow not emailing? I think that's along the lines of https://gitlab.com/gitlab-org/gitlab-ce/issues/23436.

We do store sent notifications in the DB for some types of email, yes, which includes notes (this is so that you can unsubscribe). This is per-noteable (issue, MR, etc.) though, not per-note; and I don't think that they actually guarantee the mail was sent.

Yes @smcgivern . I'm leaning toward tying an outgoing email to every comment by a support user (as per the MVP).

My thought is that a very natural next feature is that you can control some comments to be sent to the external user, and some not. This way support users can chat with each other in the comment thread, and when they are ready, write one final comment and email it back to the external user. This breaks the original design a bit where you welcome the external user to view the entire thread in a web browser by clicking on a link. But I'm more thinking of a ZD scenario where the thread is private to support users. I'd figure doing something like this wouldn't be a lot of extra technical work, especially if some of the email/notifications is already in place?

gitlab-ce#23436 does sound familiar to this in that not all comments are created equal.

@victorwu FYI, Zendesk has private comments to achieve this. You can make a whole thread private but I think this is not what the support team uses most of the time.

Thanks @regisF . That's interesting.

@victorwu I still don't really like gitlab-ce#23436, but it does sound like the most obvious way to make the use-case work.

So you would never set a comment to be specifically emailed, and all public comments would be emailed as normal, but you'd have the ability to add a hidden comment that is neither emailed to people who have insufficient permissions nor visible in the web UI for those people.

@victorwu now that I think about this, if we had a button to trigger the email to be sent, this will be a new kind of interaction in GitLab. And possibly error-prone: support agent would have thought to send the comment to the requester (because a comment was entered), but he could forget to actually press the Send button. My 2 cents.

@smcgivern Yep I can see how that can get confusing. And it's getting messy with essentially these "external users". Let's stick to what Regis and you have already laid out.

Why are using a dedicated "support user" instead of the default system admin to create issues automatically? Is it because the user who creates the issues would get a lot of notifications, so we want a separate support user?
We are using the support user's private issue creation email right, something like zxcv1234asdf@company.com right? So in practice, I suppose an organization would create something like support@company.com and configure to be forwarded it to zxcv1234asdf@company.com So would it be possible to do that all in GitLab directly? Ideally we never want to expose zxcv1234asdf@company.com at all to anybody. Should this be within or after this MVP?
We would do some reply-to magic to make sure the customer's email thread just works right? Given the above messiness?

mentioned in issue #1675 (closed)

Why are using a dedicated "support user" instead of the default system admin to create issues automatically? Is it because the user who creates the issues would get a lot of notifications, so we want a separate support user?

Yes, and because the email address gives someone the right to impersonate that user, in a sense.

We are using the support user's private issue creation email right, something like zxcv1234asdf@company.com right? So in practice, I suppose an organization would create something like support@company.com and configure to be forwarded it to zxcv1234asdf@company.com So would it be possible to do that all in GitLab directly? Ideally we never want to expose zxcv1234asdf@company.com at all to anybody. Should this be within or after this MVP?

I think this should be after the MVP. We could have a project-XXX@company.com address for that case.

We would do some reply-to magic to make sure the customer's email thread just works right? Given the above messiness?

Ah, good point. In the MVP, the customer will have access to the email tokens of the 'support user' for the purposes of replying as well, and we'll send the emails to them as if they were that user.

Thanks @smcgivern . That all looks good. Let's re-start the convo for final final final details when we start on it. Earliest for 9.1

@victorwu I think this feature falls into our major release process: https://about.gitlab.com/handbook/product/#major-feature-rollout

At the very least it deserves its dedicated feature page. Let me know when the feature will be planned so we can start designing a page on www-gitlab-com.

Thanks @regisF : Tentatively 9.1 will be for the scope you released here. But do you think that's worth mentioning on www-gitlab for 9.1? Since we probably it won't be powerful enough to advertise it as "Service Desk" feature? Maybe 9.2 or 9.3 for an official "launch" of "Service Desk", and in the interim releases we release features that contribute to it.

@victorwu hum. Good point. I'm torn because if we put some marketing effort on our first version, we might potentially have more real feedback - even if the feature is basic. But does this basic version deserve a feature page on v1? "Maybe" - depending on what we can ship for 9.1. Let's keep the discussion open.

changed milestone to %9.0

assigned to @jneen

removed ~1012342 label

@awhildy @hazelyang : Can you review the latest updated specs for this issue, which we are doing in 9.0. Let me know if you see any problems, edge cases.

Can you look at what I updated here for the settings screen? I think it's better. Let me know your thoughts.

I like "Activate Service Desk" because this is a per project setting, and the project itself can probably used as normal. Some users/orgs may choose to use this project as a standalone service desk. Some may not. I want to emphasize external email support, because the feature set is limited right now.
The robot user and the private email address are gory details that I don't like, and we should get rid of soon (as stretch goals) or future features. In the mean time, let's help the system admin and be specific. What is the correct wording? I want to emphasize robot user versus regular human user. Also, adding a link there is a nice touch because they probably want to create a new dedicated user account.
That ugly email address is system generated. We should emphasize to the system admin not to advertise it or share it with external users. We should emphasize that they should redirect / forward to it. Is that the right wording?

@regisF our current from is here https://support.gitlab.com/hc/en-us/requests/new

It asks for details around the customer's request, like which version of GitLab they are using, and then we then see that information on the ticket or sort tickets based on it.

In order for it to be as useful as what we have now, the form fields would need to be admin-configurable by someone on our team as we change it from time to time.

mentioned in issue #1706 (closed)

@victorwu Suggested text:

##### Activate service desk (?) Select a user to be the automated support account. This should not be a user account for any person on your team. Add user

Forward external support email address to:

Notes

I don't like using robot and human.
Do we really have to say 'External email support' in the header? I think it is clear from the feature name, plus there is a (?) to learn more.
Simplified the 'Forward' string to be more direct

@awhildy : That's perfect. Let's use exactly what you proposed. If @hazelyang could get updated comps that would be great.

@hazelyang is on her weekend, but should be able to update it early next week.

@victorwu @jneen and @awhildy chatted and agreed on:

The updated requirements are in the description. Usage ping also in scope for 9.0, i.e. (https://gitlab.com/gitlab-org/gitlab-ee/issues/1706).

Next steps:

@jneen : Start looking at the technical work. See if there are any more edge cases that need to be considered. Begin work. Coordinate with FE for help.
@hazelyang : Can you review the updated requirements. With this feature, we will hide the complexity of creating support user from the system admin. Everything happens in the background. Also, we should have a warning message for spam. Can you update the mockups to reflect that please.
@jschatz1 : Could we have someone on the FE team to work with @jneen on the frontend side. Thanks!

FWIW the splash page that @dewetblomerus referred to "lives" in Zendesk. We can readily make one ourselves and use the Zendesk API to do what we need... but for now we're using the functionality that we're paying extra for in Zendesk.

@awhildy @victorwu Updated!

Service Desk off

Service Desk on

Added the warning message for spam.

I want to clarify, because the copy is important here:

The warning is not that email might be marked as spam, it's that you might have an unlimited number of issues opened by who knows who with no ratelimiting.
Given that, I believe that a much stronger warning is necessary - perhaps a popup that makes you say "[x] I have a spam-filtering service in front of this email address"

(er, forgot to add an at-mention: @hazelyang ^)

@jneen Thanks for the clarification.

Given that, I believe that a much stronger warning is necessary - perhaps a popup that makes you say "[x] I have a spam-filtering service in front of this email address"

A popup probably makes people feel a little bit intrusive. Perhaps the text color is changed to be orange would be better. (Need help to modify the copy... )

@hazelyang : We don't need the whole section on choosing the support account. Since everything is automated, GitLab will do it in the background. @jneen will just manage that in the code automatically. And so the user just checks the box, and they see the ugly email address, with the instructions, and the warning.

For the message, how about something like this:

We strongly recommend you protect the external support email address. Email spam would result in many spam issues being created inside GitLab.

@awhildy @axil : Could you give us some quick feedback on the technical language here that will be read by sys admins.

@victorwu @MadLittleMods will help out.

(new feature) The issue body contains the name+email address of the sender — @regisF

Are we still going to add this? I didn't see in the issue description.

Also, could we automatically create a user account for the support bot when activating the service desk feature instead of having to select a manually created user to be the automated support account? Or is this manual selection for the first iteration only?

@pedroms : Yes to both questions. Read the description and the last few comments.

Since failing to do so can result in a user's instance being DOSed, and it's only when the feature is enabled, I am okay making it intrusive.

Also, I'm not sure about the UX of the randomly-generated email address. Regenerating means that all the user's customers have to update the addresses on their end, and failing to do so will make their comments be blackholed.

@jneen : The ugly email address is generated by GitLab. The sys admin creates another real customer facing address to share with customers. and it's forwarded over. and nothing should be re-generated. the ugly address should be static.

So the sys admin just copies that ugly email address and pastes it into their email config tool.

We don't need the Select a user to be the automated support account. This should not be a user account for any person on your team. text any more, or the dropdown for GitLab Support name. Thanks @hazelyang!
With those removed, we only have the checkbox + header, grey box for forward email, and the warning. This simplification will make the warning message stand out more.
I'd rather have a clear, strong, persistent inline message. A popup isn't the right pattern for a message of this sort - it makes sense when you click a big red button that says 'Delete project', but in this case, the orange text with the strong message is clear and obvious.
@victorwu - Could we make the DoS concern more clear in the warning text? Something like:
We strongly recommend you protect the external support email address. Email spam would result in many spam issues being created, and could disrupt your GitLab service.

@hazelyang : Could you make the quick changes above and stick it into the description.

@MrChrisW @lbot : I would like to try the simplest version of service desk (as scoped out here) with GitLab support if at all possible. I would like it to be as real as possible though, namely that we have a support email address, support@gitlab.com, and we somehow expose it to certain people, and that it is a channel all on it's own. And maybe we can monitor it closely. And we turn it off once we see enough problems or have learned enough, in order to minimize disruption in your day to day work, And so that group of support tickets would just be totally different.

Do you think that's feasible and makes sense from an operational perspective? We could just simply update this page (https://about.gitlab.com/support/) to include that extra support channel. Not sure how much extra work is involved in configuring a new email address is though.

@victorwu it is easy to provision a new email address, check out the GitLab Email Forwarding document. It'll be harder to run this in parallel with Zendesk without having one or multiple people be less efficient than usual, and without losing ticket history if we decide to switch off the experiment at some point.

Thanks @ernstvn . That makes sense. Could we just run the experiment for like 20 tickets or even just 10? If we put that email address up on the website, could you estimate how many tickets would come through there? So maybe once the support folks see 10 issues have been created, then we stop the experiment. And perhaps for record keeping later on, these could be manually copied to ZenDesk after the support issue is closed?

I let @lbot decide that as Support Lead. But I'll say that I don't think it sounds crazy.

@awhildy @victorwu Updated!

@ernstvn @lbot @victorwu Would it make sense to trial on the GitLab.com Support Tracker? It's already located on GitLab.com and not in Zendesk.

Sure @markglenfletcher but then you would be the one trialing it right? We're not planning on sending customer inquiries there I hope.

Support still receive tickets for GitLab.com via the Support form and Zendesk though right? I figured it would be a good way to dogfood the first iteration without posing an impact on customer support.

Can't we make the email address follow our URL scheme, why the random URL? @victorwu

@JobV can we try something like incoming+gitlab-org/gitlab-ee@gitlab.com as the default url for https://gitlab.com/gitlab-org/gitlab-ee/ with incoming@gitlab.com being the url you set for incoming email. The random string is for authentication, not for spam prevention. Spam prevention has to happen before the email hits GitLab for now. The email address needs to be memorable. It should work be easy to use, easy to remember, and work without setting up forwarding.

The random URL is assuming we are re-using the email issue to project functionality as a technical implementation, at least as a first iteration, and then the sys admin would have to forward support emails to that random address.

In future iterations we would hide that complexity inside GitLab itself so that the sys admin can just pick that default url. (And probably solve the spam problem within that same feature.)

@jneen : Am I missing anything beyond what we discussed earlier?

mentioned in issue #1727 (closed)

@jneen : I added a stretch goal per the above discussion. I.e. the sys admin gets a friendly default email address and so doesn't need to do any forwarding outside of GitLab. GitLab handles everything under the hood.

It is important to note that per RFC 5233 the plus (+) when used in the local-part of an e-mail address can be treated as sub-addressing, where "joe.user@comapny.com" and "joe.user+tag@company.com" are the same e-mail address, but the mail system either tags (in the case with Google) or filters into a folder 'tag' (other common on-prim email services) the mail due to sub-addressing.

mentioned in issue #1734

mentioned in issue #1735 (closed)

@jneen raised a good point with OOO auto replies that could cause a problem with infinite loops, if both the external user and an internal support gitlab user had it set up. The existing code should already be catching these and blocking them. But something to verify during testing. Also mentioned in description.

@jneen @smcgivern @hazelyang : I updated the description per further discussions. Please chat here if questions / concerns.

In particular, we want to protect against spoofing emails. So the idea is opting out of a support request:

Support user emails in.
Support user gets an automated response email, welcoming them.
Support user can click a link/button in the email saying to stop the thread. If they do so, this generates an email back to GitLab, so that the support staff can know to cancel the request (close the issue).

This helps with the scenario that a malicious person spoofs another person's email address.

@jneen @smcgivern @hazelyang :

@jneen found out that when creating issues, GitLab is already doing some spam filtering. So we agreed to reduce the tone of the warning message (but still have a warning message). Mockup in description updated with that toned down message.

Thanks! Also note that GitLab only uses Akismet when configured: https://docs.gitlab.com/ce/integration/akismet.html

So we might want to link to that, in the case where it isn't configured.

@jneen @smcgivern @hazelyang @awhildy : Updated the issue description with this:

Behind the scenes, GitLab manages a special support-robot user to do issue creation / comment adding.
This user (username, email, and avatar) shows up in the GitLab UI.
That support-robot username is defaulted to support-bot and email is defaulted to support-bot@gitlab-instance-url.com.
The system will automatically change that username and email if it's already taken.
That support-robot account cannot be used by a human to log into GitLab.
That support-robot has an avatar.

@hazelyang : Can you provide an avatar for the support-robot user? I think the main use here is that it is obvious to human users that this account is a robot, but also, it is generating these comments on behalf of the external customer. So not sure how to best communicate that in the avatar.

@awhildy : Do you have a better idea for the username/email of the support-robot user? Again, it should communicate that it "represents" the external customer, but that it is also a . That seems hard.

@victorwu It would make sense to 'auto-create' an account for someone who replies via email to a ticket - even if that account has a special/new status so it doesn't take up a license unless it's later claimed or unlocked. This is what Zendesk does. The advantage is that in the future, the user can come claim their account, or sign in to their already existing account, and view and interact with their tickets. If we post updates as a bot user, this will not be possible now, or in the future.

cc/ @lbot @MrChrisW

@dblessing : That's a great idea as we build out SD in the future to support more "state" of customers, and recognizing them, even though there are not fully registered / have an account with us. Not something we can build out now. But I do like that idea!

@victorwu sorry for the delay in response here. I mis-understood todos and wasn't getting alerted.

I would like to try the simplest version of service desk (as scoped out here) with GitLab support if at all possible. I would like it to be as real as possible though, namely that we have a support email address, support@gitlab.com, and we somehow expose it to certain people, and that it is a channel all on it's own.

@victorwu I don’t think we’ll be able to route support@gitlab.com into this test unless we also forward everything to Zendesk as well, which sounds like a mess.

We could just simply update this page (https://about.gitlab.com/support/) to include that extra support channel. Not sure how much extra work is involved in configuring a new email address is though.

@victorwu, I think the best channel to pipe in would probably gitlab.com support. It’s a non-trivial amount of tickets and they are “low priority” for Support as we have to prioritize paying customers.

Could we just run the experiment for like 20 tickets or even just 10? If we put that email address up on the website, could you estimate how many tickets would come through there? So maybe once the support folks see 10 issues have been created, then we stop the experiment. And perhaps for record keeping later on, these could be manually copied to ZenDesk after the support issue is closed?

If your sample size is 10, it probably makes more sense to just replay closed tickets into this system. Randomly select 15-20 tickets that have been solved and see if they have anything unique about them (internal comments, etc). Doing a “quick” firehose squirt seems like more trouble than it’s worth.

Would it make sense to trial on the GitLab.com Support Tracker? It's already located on GitLab.com and not in Zendesk.

@markglenfletcher Sure, these could get piped in too, somehow, but I think the benefit of those being public is it lets people +1 issues and add to existing issues and get things on our radar faster. It's a common problem in a “support silo” were an agent has to connect the dots, not the submitter.

@victorwu - I'm also not coming up with anything better than support-bot currently either, so let's go with that. I didn't like describing things as 'robot' and 'human' in our description -- saying automated, etc. seemed clearer to the intent, and just a better description of what we meant. But when it comes down to what makes sense for the name, having bot in it seems fine.

The avatar

How about a fox?

or a robot?

@victorwu @jneen:

Behind the scenes, GitLab manages a special support-robot user to do issue creation / comment adding.

Is this used for all projects using service desk on an instance?

@hazelyang : Let's use the robot avatar, since @awhildy says "support-bot" is okay.

@smcgivern : Yes, I think so, same support-bot user for all projects in that instance. Any scenarios where that might be a bad idea?

@victorwu I was just wondering. If someone had access to this user, they could already read all support tickets for a project - this just extends that to the instance level. As you can't log in as this user, though, it should be fine.

changed milestone to %9.1

added Deliverable label

@victorwu sorry, late to the party. About the message to the admins, I'd go with something like:

Make sure to protect the external support email address with a tool like
SpamAssassin. Email spam would result in many issues being created, and
could disrupt your GitLab service.

Mention of the most known tool to fight email spam
Replace "we recommend" with "make sure" to make it sound like a needed action, otherwise there will be consequences.

We can have links in the docs how to do that. There are some great tutorials out there, like http://www.akadia.com/services/postfix_spamassassin.html or https://www.digitalocean.com/community/tutorials/how-to-configure-a-mail-server-using-postfix-dovecot-mysql-and-spamassassin.

cc @hazelyang

Per @jneen in Slack:

i have an MR open on CE that creates the concept of an "internal" user that's not allowed to log in

[21:52] this is a concept shared with CE's "ghost" user - a user who owns all content made by deleted users (edited)

[21:53] this way, adding a service desk user simply plugs into existing CE code and is super straightforward

mentioned in merge request !1366 (closed)

mentioned in merge request !1396 (closed)

mentioned in commit apilab@8c79b56f

mentioned in merge request apilab!1 (merged)

mentioned in commit apilab@1b5105c3

@victorwu I'm not sure if this is the right issue to raise this, but I know with this feature we spoke about handling out-of-office replies. It seems like there is an email header (TIL) that may be helpful there:

https://msdn.microsoft.com/en-us/library/ee219609(v=exchg.80).aspx

Such as, if X-Auto-Response-Suppress header exists within the email, then GitLab can skip processing it.

A customer brought it up and I figured could be useful info for this project as well.

@lbot I think that's for sending emails, not receiving them? Thankfully, we already add that, as of 9.0: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9163

@smcgivern right, but isn't Service desk going to get auto-responders that may have this header set?

-> Someone emails service desk. -> Goes on vacation, out of office responder -> We reply -> OOO reply gets sucked in to service desk.

This came up in a customer request where I'm trying to repro gitlab pulling in OOO replies as responses to issues. (attempting to repro now)

@lbot correct, AFAIK that header tells mail clients not to send OOO responses to the mail in question.

mentioned in issue #1992 (closed)

changed title from GitLab Service Desk to GitLab Service Desk (renamed to Customer Voice)

@jneen @MadLittleMods : I updated the description mockup to show "Customer Voice" as the name of the feature.

changed title from GitLab Service Desk (renamed to Customer Voice) to Customer Voice

mentioned in issue #1728 (closed)

changed title from Customer Voice to Customer Voice with email

mentioned in issue #2028 (closed)

mentioned in issue #2029 (closed)

changed title from Customer Voice with email to Service Desk with email

@jneen @MadLittleMods : We are back to "Service Desk".

@smcgivern : Could you please create a label for "Service Desk". Thanks!

@victorwu I don't know the rationale behind “Customer Voice”, but “Service Desk” sounds much clearer to me. “Customer Voice” sounded a bit too marketing-speak and unnecessary. So I appreciate this change

@pedroms : Here's more context: https://gitlab.com/gitlab-com/marketing/issues/848

@smcgivern I think I have permissions to create project labels. Can I create the label?

@victorwu sure, although I've done it now

added ~17903689 label

Awesome thanks @smcgivern

added ~1571678 label

The feature is merged and will be in 9.1! Tracking issue for the docs is https://gitlab.com/gitlab-org/gitlab-ee/issues/2094, with an MR open at https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1586.

closed

Hi, i have a quick question. This feature is described as "Exclusive ~"EE Premium" feature only".

I am wondering why i can use this feature in my gitlab.com Free Plan which i think is equal to the EES Version only.

Can i rely on the fact that this feature will be for free in medium term?

EDIT: When i go to https://gitlab.com/help i can see i am on GitLab Enterprise Edition 9.1.1-ee 43c23ff4. But from this site https://about.gitlab.com/gitlab-com/ i would derive i should be on EES. How can i get info on this?

mentioned in issue #2297

@ganomi : The feature will be available on GitLab.com for the Silver Plan and Gold Plan only. We will be making this change likely in the next release in May. I apologize for the confusion. Once we make that change, it will no longer be available on GitLab.com on the Free Plan and the Bronze Plan.

The GitLab.com plans how they map to CE / EES / EEP are here: https://about.gitlab.com/gitlab-com/.

Further details on the GitLab.com plans and why we are doing them are in this blog post: https://about.gitlab.com/2017/04/11/introducing-subscriptions-on-gitlab-dot-com/.

Thanks for mentioning https://gitlab.com/help. I can understand how this confusing. I've created this issue to address this: https://gitlab.com/gitlab-org/gitlab-ee/issues/2297

mentioned in issue CardBook/CardBook#392

added devopsplan label

added Enterprise Edition label

mentioned in commit 522b3c74

changed the description

removed Plan [DEPRECATED] label

changed the description

removed time estimate

added grouprespond label

moved to gitlab-org/incubation-engineering/backlog#19 (closed)

Service Desk with email

Context

In scope use cases

Acceptance criteria / gotchas

Design

Documentation

Stretch goals

Out of scope

Original issue description

Description

Proposal

Wireframe

Out of scope

References

Designs

Child items ...

Activity

MVP