Service Desk

Don't we already use issues for supporting .com users in https://gitlab.com/gitlab-com/support-forum? That's not to say that the steps here are wrong, I just want to clear up what already happens

@smcgivern we do, but this project hosts public discussions, not tickets submitted by our paying customers, which we want to address privately.

@victorwu GitLab Service Desk was the name internally chosen to make it perfectly clear what the feature is. We don't need to call it per se.

Advantages of calling it that way:

Service desk seems to be the popular way of naming these kind of services

Disadvantages:

It's clearly a copy of JIRA
The first iteration will not contain what most customers expect from a fully functional service desk à la Zendesk

We could call it Customer Support, which still convey this notion of service desk, but doesn't come with all the promises of being a fully functional service desk.

@regisF : Thanks for the context!

@smcgivern : For gitlab.com support, what I have in the description is just after high-level discussion with @MrChrisW . No clear direction / process implementation detail yet, if at all. Primary goal is just to get somebody using the features right away. Natural fit is our own Support team. I'm really hopeful we can do that, with minimal disturbance in our existing processes and tools.

@smcgivern Interestingly enough we also accept GitLab.com support via https://support.gitlab.com - specifically for bugs (gitlab.com) and account issues. I discussed with @victorwu redirecting these requests to our internal GitLab.com "customer support system" for a period of time for testing purposes. This means the tickets would roll into Zendesk and into GitLab.com, we could easily switch back to Zendesk if required; with little disruption.

@smcgivern we do use part of gitlab as a way for people to submit issue reports, and is sort of works for us as we are transparent so it works, but a lot of workflows require sensitive data so it would be something else.

@victorwu Speaking on behalf of support as a team that's heavily entrenched in ZD right now, how do we see our team bridging the gap to use this feature in the "near" term? We basically need all of the features of ZD, and I might even suggest shooting this down as something that's so far out we shouldn't focus on it until version 17.

I imagine this feature as a hard sell for a lot of orgs. A lot of companies have completely separate Dev / Support teams and processes, so it seems like a weird market segment to design for when we are trying to shoot deeper into the enterprise?

I think our "Idea to Production" needs to get a lot stronger before we go to "Production and beyond". My

@lbot thanks. I don't want to force you to switch to something you don't want to use

@smcgivern I think we have the prime example with @MrChrisW's use case https://gitlab.com/gitlab-org/gitlab-ee/issues/1675#note_22957369

I'm all for the testing the feature and it could be useful, but I wonder if paying EE customers really want this? I feel like any customer with a 200+ seat license is already deeply entrenched in ZD and would be hesitant to switch?

Thoughts:

Big Co's are running GitLab on-prem. How will customers get to this interface? Just email?
Small Co's are probably running CE.

There is a part of me that thinks tight ZD integration might be a better V1 to understand the feature set and provide immediate value to what I imagine (we would need numbers) at least a good portion of our customers.

@lbot what do you mean by "small co's" and "big co's".

Can't go into much detail here, but we have much, much, much (much) more EE customers with few users, than "big" customers (big being 100+ users). Moreover, JIRA Service Desk is such a success for Atlassian, that it clearly shows an interest, even if no customers ask for it at GitLab.

@lbot - If we had a tool that rivaled ZD in functionality, but was a part of GitLab, do you think that would be enough to entice some companies?

Our goal isn't to target the big ZD power users right away. We start with something lightweight, get it out there, get some usage, and continue to build upon and evolve it based on feedback we receive. We have to start somewhere

@regisF My understanding based on our growth goals is that we want to head higher up the company size chart? (I may be completely off base) My logic is based on:

We want to triple ARR (Annual Recurring Revenue) in 2016&17, and double it in 2018&19&20 (closed) (T2D3), in order to IPO in 2020. Source: https://about.gitlab.com/strategy/ based on https://techcrunch.com/2015/02/01/the-saas-travel-adventure/

@awhildy I think that it's more for "niche" software teams? For example most companies I know past 20 people (maybe 5 devs/ 5 sales/ 5 support and 5 designers) have two different teams/leads handling dev and support. That means that you'd have to convince 1) the dev team to go gitlab (not hard) 2) the support team to also switch and use gitlab. It's "two" sells instead of one. Does that make sense?

I sound contrarian, and I want to clarify that I think this is cool, but I don't see us using it, and I don't see my last company using it either (12 employee startup), and I don't see the company before that using it either (when I left they were 50 employees). I personally don't know how this would make it into an org where 2 teams need to agree on the same product for two different purposes.

@lbot - Totally appreciate your honest feedback! When you say tight integration with ZD, do you have ideas on what sort of integration would be valuable? Or what is a pain today?

@awhildy "tight" integration with ZD would be:

An easy way for ZD tickets to be linked to gitlab.
An easy way to track ZD tickets linked in gitlab for metrics and stats.
A trigger in ZD that would internal update (or something else even) if a GitLab issue was closed as that usually means the problem in the ticket(s) should be solved.

For a V1 even just the first 2 would help us a ton.

@victorwu - I can understand @lbot argument that instead of competing with a mature product on functionality, we start by integrating, and pulling people into using GitLab as the connection point between Support and Devs. Sounds like the pain point today is more in the integration with other products such as GitLab then in any functionality missing from ZD, etc. We could still build the MVP down the road, but maybe getting our foot in the door with the integrations first would be helpful. Thoughts?

We generally prefer an integrated solution, in the sense that everything is in GitLab, don't we?

mentioned in issue #149 (closed)

mentioned in issue #1706 (closed)

mentioned in issue gitlab-com/marketing#848

@lbot, we would totally use it if it let's us do our work efficiently :-) Hey, we may even have efficiency gains, not having to go back and forth between poorly integrated platforms :-)

@ernstvn I agree that it could be helpful for a team to manage .com support requests. That said I think the scope of this as "you can email a gitlab server, and view the email, and send a reply, and link the emails to issues" seems like a 2 month long project fraught with a lot of bugs because email is a mess (attachments?). I'm not doubting our team or the possibility for potential usefulness, I'm questioning the opportunity cost.

There is an issue floating around where a frustrated user, after waiting 2-3 releases for a bug to get fixed, said something along the lines of "I wish GitLab would stop making flashy new things and make sure the core of the product works." That sentence makes me wince. I think about it every day.

Which leads me to ask: Is there something we can be working on now, that would have a bigger effect for more customers, that is easier?

mentioned in issue #1727 (closed)

mentioned in issue #1728 (closed)

mentioned in issue #1734

mentioned in issue #1735 (closed)

@lbot @ernstvn @MrChrisW . I updated the issue list in the description above, with some pretty obvious next steps for features. But wanted your feedback on which direction to head next. In your opinion, how important is it to have a web form to submit support requests, if we already support emailing in requests? It seems like a basic feature that companies would want. But I tempted to bypass that for now and just jump to the next feature that is support-facing (i.e. GitLab internal), like support queues etc. I.e. go for breadth before depth.

We used to be email based only, then added the web form to help do a first step of sorting / triage since people can select their type of problem and provide information about their installed version and such through the web form. For that reason we're using the web for more and more, but email is still very common, probably more than 50% of requests come in over email.

That's great info @ernstvn! Thanks! We don't have to make a decision right now. But I'll leaning toward not building native web form support then. We could set up a marketing-ish page to explain to people that they can probably use some service to stand up a web form to redirect messages to the gitlab support email. Maybe google forms or typeform.

In your opinion, how important is it to have a web form to submit support requests, if we already support emailing in requests?

I agree with Ernst, I don't think we need it for a V1.

That said, I'm newer to the GitLab Product side, do we normally build features without identifying potential customers and getting their initial feedback?

I'm still beating the dead horse that "Atlassian does it" and "we want to make a more integrated solution" are not enough for me to be confident that enough of our customers (or potential customers) want this or would use this. I'd love to see some plans around how many customers we'd hope would adopt this, how much money we'd estimate to earn on this, etc.

Thanks for the feedback @lbot . Great comments.

In our product development process, we try to do quantitative data analysis, customer development / market research, chat with existing / potential customers as much as we can. It is admittedly an area that product needs to improve much more on, and on our radar. We are ramping up processes and tools in this regard. But nothing clearly established yet. For example, product folks are just starting to get more acquainted with account managers to talk with customers. But our product team is very new and we are getting there. So "Atlassian" does it is one signal. It is a strong signal I would argue. But I agree not sufficient to throw all our chips in. "Integrated solution" is pretty much GitLab's product strategy in nutshell. And it applies here as well.

@JobV : Lee brings up a good point. Since this is (in a sense), a brand new product, should do some more work in the traditional market analysis arena? Or treat this like any other feature, i.e. small iterations and product feedback?

Fortunately, we do not have to throw in our all chips into this initiative. It's actually a false dichotomy to say whether we should do this or not. With each release, we ship the absolute smallest change, balanced with all the other priorities we have overall in GitLab. So in this case, #149 (closed) is that smallest slice. The strategy is to invest the fewest resources (people, time, patience) to get some finite amount of feedback from our users. This strategy minimizes engineering risk as well as product risk, and is not unique to GitLab / startups in general. So even though our customer development side is still ramping up, we can still ship small and quickly month to month to get some progress. Since this is a brand new feature (arguably "product"), it is indeed difficult to get any feedback before and after it ships. So that's why I latched on to the support team as soon as I could. Just to begin that discussion, make sure we are not crazy. And of course we want real-world usage as close as we can, to make sure that feedback is accurate. So thanks for participating!! We need it.

And so if by Q3 2017 (arbitrary date I just picked, not solid timeline) we see this feature not picking up steam, we may cut our losses and move on to the next thing. We wouldn't have invested too many resources (people, time, patience) in the grand scheme of things. So it's a good deal. Furthermore, we are leveraging many pieces of GitLab already and not building a brand new infrastructure / code base. (Another reason to not do the web form thing for now.) So along the way, some of the features that we developed we will probably try to recycle and of course lessons learned form a product perspective is also positive value.

@victorwu already said most things I'd say @lbot.

We should consider the cost/benefit of shipping something small vs. spending that time on market analysis. I'd argue that we ship sufficiently fast that the feedback we get is a better indicator than anything we could've done beforehand.

It's the job of the PM to figure out if it makes sense that we should build a certain thing and how, but if we have a strong suspicion, that's probably enough to give it a try. With everything we build, we should stick to the strategy of small iterations. That doesn't mean we can't have big ideas, plans and be ambitious, that's just a really good way to build something based on feedback, so that eventually - you build something that people want.

In this case, there's a single strong indicator that there is a market for this. Our MVP for this is reasonable in scope. If our experiment fails, it will have lead to several smaller improvements to GitLab that can stand by themselves. I'd say that we're better off focusing on building this and listening to feedback, rather than search for (probably anecdotal) evidence to falsify what we're suspecting.

TL;DR try small things; iterate based on feedback; rinse and repeat.

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

My mistake. Comment above was intended for the Service Desk issue. It is here: https://gitlab.com/gitlab-org/gitlab-ee/issues/149#note_24856585.

changed title from Customer service support to Customer Voice issues

changed title from Customer Voice issues to Customer Voice

mentioned in issue #2028

mentioned in issue #2029 (closed)

mentioned in issue #2030

mentioned in issue #2031

mentioned in issue #2032

mentioned in issue #2033

mentioned in issue #2034

mentioned in issue #2040

changed title from Customer Voice to Service Desk

added ~1790368 label

marked the task 9.1 #149 (closed) Service Desk with email as completed

marked the task 9.1 #1706 (closed) Service Desk usage ping as completed

mentioned in issue #2137 (closed)

mentioned in issue #2201

marked the checklist item #2096 (closed) System create user "Ghost User" counts against user counts (To not count the support user in the license counts of EE). as completed

marked the checklist item #2137 (closed) Allow Service Desk to be configured by project admin as completed

marked the checklist item #2029 (closed) Service Desk with friendly email address as completed

Service Desk

Designs

Child items ...

Activity

Admin message

Admin message

Service Desk

Activity