OK, thanks very much for coming. This is my talk on the Customer Portal. You might have seen the talk last year I did on the Support Portal, and we've had a slight rename.

It's called the Customer Portal now. And we're going to talk about that today and how we use OwnCloud kind of as a platform. So I'm Tom Needham. If you don't know me, I'm a solutions architect at OwnCloud. I actually joined back in 2011 when I was 17 years old. Worked in development for a bit.

I went away to university, did an engineering degree. And I'm still here working full time now. I've been in the support team for about 18 months and working solving cases and really jumping into the code. So this is a picture of me on the weekends.

If I'm not coding, I'm usually on a boat. And when I'm on a boat, I'm usually doing IT as well. So this talk, I'm going to talk about the customer success team. We've widened the scope of this project from support now to talk through the other teams. And we have this big team now called the customer success

team. Going to talk about the learnings over the last 18 months that I've had of working in support and how I think we can make some improvements. Look at what we do at the moment. So the processes we have and the tools we use for working internally to solve your cases.

I'll then introduce the customer portal, which has been a project of mine over the last year to bring all of these learnings into some automation and into an application that we can all use to help solve cases more efficiently. I'll then talk about the engineering behind it, which is my term of using own cloud as a platform.

I'm really using it for its fast and good share. And finally, the roadmap, so where we are now and the ideas for the future. So this is our customer success team. It basically encompasses all of the teams we have that interact with you after sales and help make you successful.

So any case, be it consulting, deployment, or finding bugs, finding issues. You'll talk to one of us, and we work and help solve the problems. So I've worked in support for the last 18 months and worked for many of you and learned a few things

about how we interact. I think there's some areas for improvement. This is a rough idea of what it looks like internally and externally for you, how we communicate. So as a customer, you come to us with an issue. It's usually done via email.

Hits us support at owncloud.com or consulting at owncloud.com. That gets tracked in our CRM, so we have threads of emails as cases. Just text, you might even attach a file now and again. And that basically hits our CRM and saves it as a case, so you get this case number.

As support, we then read these cases from our CRM, and we can work with engineering and who use GitHub. So we might take some data, take the versions, take the exceptions, format it all nicely with some steps of how to reproduce it, and we put that into GitHub. So then our engineering team read this from GitHub.

They know what the problem is. They dive into the code and come up with a pull request. So in that whole process, there's four or five different teams reading information. Actually, engineering need the data from the customer, but they maybe don't directly talk to them, so we filter out some of the early communication, getting the log files, getting the configuration reports.

So there's a lot of back and forth, and we actually need one central place where we can share this data, and also sharing it in a more usable way than email. That's what we're here for. That's what owncloud's all about. And we end up sharing things like log files, config reports, maybe we do patches or some special versions for yourselves.

And sometimes that ends up even happening via email. We do use customer.owncloud.com for that, but we really want a nice automated place, central location that our teams can work and share this information between everyone. So trying to sort out that mess. So these are some of the solutions we use already.

The engineering team heavily use GitHub. That's what they use for managing their workload. They use labels, they use milestones, they have projects and Kanban boards. And so when we put issues into GitHub, they can assign things to engineers, they can give them special labels, and that's how they do their prioritization.

Let's say when you, as a customer, email us, that hits our CRM, and that's handled usually by our support team. So we have this kind of synchronization between GitHub and also what you're telling us. So when engineering may fix an issue, we've then gotta manually bring that back to the customer. And likewise, if the customer gives us more information, gives us better log files, we've gotta feed it through to engineering

so they can take that information and maybe figure out what the problem is. Sometimes we create patches. That's obviously done in GitHub by our engineering team. And in cases where it's a severe problem or you need to fix straight away, sometimes we send that file through to you so you can patch your instance

and take that fix straight away. And again, those patches are sometimes done via email or sometimes done through customer.owncloud.com, which we use as our own own cloud instance for sharing files with you instead of email. Don't know what is randomly pressing buttons. So we use customer.owncloud.com already,

which is an own cloud instance running own cloud 9.1, I think it is. And we're basically trying to move this to our new portal. So the idea is we have something called the customer portal. And this is basically taking all of our learnings from the processes and coming up

with a new own cloud instance. And we have this app installed on top of it called customer portal. We use other apps such as the workflow and tagging to add functionality. At the core of it, you can log in as a customer and view your cases. So you see a list of support cases. You can work on your consulting cases.

You can help us with feature requests. And in there, you can view them. You can create new ones. You can close them. We can give you an indication of cases we need more information on. And also, if you have the issue resolved, you can click in there and close it straight away. Instead of using email, we can actually use

the own cloud platform for file sharing. So if you have log files to share with us, you can upload them straight into the case. And it's tracked in one place, one folder. All of our teams can work on that together. It saves files going via email. We can't see where they've gone if they've been shared with the correct people.

And likewise, the other way, we can supply you with data, you with patches, you with maybe test builds, custom apps, that sort of thing, all in one place. Traced, we have all of the privacy and security and controls from own cloud. And we're not using email. And we can do it all in one central place.

We can also use the portal for software delivery. So you may have already used customer.owncloud.com for accessing versions of the own cloud code. And we can move that essentially over to the customer portal. So again, you have one set of credentials. You can log in and access this functionality from your enterprise subscription.

So we'll expose things like the server versions, the enterprise apps, and then even move own brand over to the portal. So you can access your branded clients, your branded themes, and again, all of the documentation that comes with that.

So here's a little preview of the instance, the portal instance. Again, it's just a normal own cloud install. And as part of the app, I utilized the alternative logins option in own cloud. So there's an extra button which allows you to create a new account as a customer. You can have multiple user accounts per customer.

And each user gets their own account. And they're associated with the same group, which is your organization. And that organization, you get to access all of the cases, all of the data as your organization. So when you log in, you get an overview of your support cases.

At the moment, it's focused around support. And we're building in the functionality for additional types, such as feature requests and consulting cases. And each one will have its own basic form so we can get the right information from you. So this is what it looks like for support cases. You can see the one in red is highlighting to you

that we need some more information. And you can add some sorting if you happen to have a lot of issues with us. And you can also jump into the recently closed. If you need to check out a solution that we've given to you, refer to a patch or refer to some advice and documentation that we've given. There's a link in there as well

to open a new case, which pre-fills your email client with the right address with a subject and an idea of what information we need from you. If you jump into a specific case, you get some more useful information than that. It's just left some text at the moment.

Obviously, you see the case title. And we're trying to design this around a timeline so you can see how the case has evolved. When you initially created the case, the details you supplied us with. And then, obviously, by default, it's all based around email still. So the communication is still done via email. And you see a list of those emails, even from your colleagues.

So you can jump in and work on things together. And then, utilizing OwnCloud, we have this button in the top right called Case Files. So in the background, what we do is we create a folder for each case. And we share it with your organization. So anyone who logs in from your organization can access that data, share log files, read the patches,

upload screenshots or videos of what's happening. And we also share that with slightly different permissions through to our internal teams. So engineering can access the log files. They don't have to go to three different places or ask someone to access the email to get access to the log files of what's happening.

And then we also have a button in the top right for replying to a case. So that will open your email client with a direct link through to support.owncloud.com or consulting.owncloud.com with the email reference. So it will already be detected and go straight into the case.

And of course, you can use the Case Files button to jump straight to a folder and upload the data. So now I want to talk a bit about the app behind it. So this is all built around one OwnCloud app called the Customer Portal. It uses purely public app APIs.

Doesn't use anything special or internal. It's all available for app developers. So I'll jump in. First of all, there's the user provisioning. So we have our customer list in a CRM. That's our basic identity provider. But we don't actually want to keep the users in there.

We want to use the OwnCloud user management. So I use it in a similar way to our shivlet application for auto provisioning. So when you log in, I can detect that the user exists on the CRM. So there's an identity there. And I can then create an account in the back end, in this case, the database. So I can bring in things like your display name.

I can bring in your email. And I also bring in things like the entitlements, so which enterprise subscription you have, and assign that to different groups. I then also use what I call a dynamic group back end. So as part of the app, I've made a group provider. So it exposes some groups to OwnCloud.

And those groups represent, first of all, organizations. So if you log in with four different members from your team, you're all automatically assigned to a single group for your organization. And then also we expose your subscription as groups. So they're mapped through. And if you've got 10 customers

who have a certain subscription, they are exposed as a group. And that allows me to do things like sharing resources with specific entitlements, sharing access to certain apps with specific entitlements, some specific organizations. So you know you can enable an app for a certain set of groups. Again, we can do that based on your enterprise subscriptions.

Next is file and share management. Again, file, sing, and share. So for the cases, I use some hooks in the background, and I can automatically create the folders. So when you click on a case for a first time in the background, we actually automatically create that folder for that case.

I share it with your organization because you're the organization who created the account, created the case, and we also share it with our internal teams. And using OwnCloud, I can actually create multiple shares with different permissions on the same folder. So I can give you, for example, more restrictive permissions, and I could give the internal teams more permissions

to change data. Again, I use the groups for sharing because we're not just sharing with single accounts like on our customer OwnCloud instance. We have multiple users per customer. So we do all of the sharing based on groups, and that allows you to log in and work on things as a team, not just as single users

and have to share passwords. As I say, we can change the permissions based on the group. So based on subscription or based on who's logged in, we can change the permissions around a case. And then finally, workflow and automation. So we use our own enterprise apps on this install.

We use the workflow app, and we can do things like detecting automatically the type of log files that you're uploading. So if you uploaded some server log files, we can spot the kind of size, we can spot based on the name, the MIME type, maybe the device it was uploaded from,

and we can assign some tags to that. So as an example, I've already implemented config file detection. So configuration reports, as you know, something we ask for almost straight away when we get a support request, is we need to know which PHP version you're running, which app versions are running at the minimum so that we can figure out how to recreate the environment.

So the first thing for us is if we can detect the name is configuration report, the type is application slash JSON. We know it's a configuration report, maybe based on the size as well. We can tag it with a label using a system label so it doesn't appear to yourselves or even to us, it's just internally. We can tag it as a configuration report.

And that can then help us know whether we have up-to-date information and we can solve cases or whether actually the last configuration report we received from yourselves is maybe one year ago and so it's probably not representative of your current environment. Obviously, we also use the built-in activity and events.

So when we're uploading data to, for example, a patch into a case, you can actually click into your activity stream and you will see that an own cloud engineer has uploaded some data. If you want to, you can actually go into your settings, click on activity emails, and you'll get an email straight away when we upload some data. If we upload a new own cloud version,

you can get an activity straight away because that file is still a folder shared with you and you can get the activity event. If you use the sync client as well, you could even synchronize that entire folder structure. So you have all of your case information, all of your patches downloaded and you can obviously drop files and log files into that

and they get uploaded to us. And you can sync, of course, the software. So you could sync the server versions, you could sync the app versions, and obviously when we add that in there, it gets pulled straight down to you and you have it available offline all the time. And finally, audit events. I utilize our auditing apps on portal.incloud.com.

We can see where the files are going. We can see when they've been used. So for example, if we give you some patches or some versions, we can check that you've actually received them and you can put them into production. This is a little preview of the config report detection.

So for example, I can look across all of the cases and look for all of the files that are tagged for the config report. If we don't have one at all, I can pre-warn you essentially we're gonna ask for a config report. Carlos is gonna email you in an hour or so and say, can we have a config report? We need to know what versions you're on. So if we can get that information sooner,

that obviously helps you solve cases quicker. It saves us time in having to just ask for the same questions at the same time. But also if we have a config report from one hour ago and you're creating a new case, we don't need to ask for another one. So we can detect that and save yourself time and ourselves time and hopefully solve cases quicker. So I there give you a link directly to the documentation

to generate a report using the config report app. And I also give you a direct folder private link to the folder you need to upload the log file into. If you drop it there, it obviously gets tagged with the config report and the portal will know that this customer has uploaded a config report

and we can hide that message because we have something that's recent from you. So this is an idea of the roadmap. So last year we basically came up with the idea based on the problems and findings from working in support for a while. We gathered some ideas together

and we put together an initial app. Had a closed beta, learned some more things. Maybe didn't write it the correct way first time so I decided to take all that feedback, completely rewrite the app from scratch. I added this group backend so you can have multiple users per customer. I added the file platform

so that we can share files between cases. That's really the crunch point for me is that I want this to be in one central place, not spread across emails between your team members and our team members. So the end of this year, we're essentially launching the portal for everyone. It's up there with some, if not most,

of the functionality that I've spoken about today. We're gonna work to improve the types of cases we support so initially we developed this as a use case for support but actually the same process is really useful for consulting. We can have a nice form which can get an idea of what you need from us.

For example, feature requests, product management can have a nice form for what you're expecting to happen. Maybe you can upload some screenshots or some diagrams of what you think should happen and we can have our own process for managing product feature requests. Also, towards the end of this year,

we're working on a partner portal which you'll hear more from Joerg later today. So it's extending much of the similar functionality to customers to our partners. Again, we can expose things like training materials through shares and that's done through your subscription. At the beginning of next year,

we're looking at integrating the software delivery side of it. We have the marketplace already which is software delivery for apps and we also use customer.ownglide.com at the moment for software delivery for the server versions and we can actually use your credentials because they're tied to your subscriptions to authenticate yourselves

for accessing things like the marketplace so you can use one single login and we're even looking at things like authenticating to a Docker registry so you can access enterprise Docker containers based on your portal credentials. There's one set of credentials you can use. You can have multiple users per customer

and they're obviously tied also to your enterprise subscription. We also have a small task to move own brand from own cloud nine up to own cloud 10. I think we have a pull request open for that at the moment just to make some updates so we can shift that over onto the portal as well and again, use one central place for you to access the code.

And then after next year, middle of next year, we've got a few more ideas up the sleeves. We can use this portal as a central place to give you update reminders. If we have knowledge of the configuration report so we know which apps you use, we can send you notifications if a new app comes out or a new update comes out with some fixes.

We have the potential to use this for security advisories so you can log into your account and look at the security advisories. And also for training material, we have our documentation but perhaps in the future we have some admin training materials we can provide to you through the portal. And I've put the question mark there

because I opened to you for suggestions on features. Ultimately this is about helping customers so if you have ideas of what we can include here, then happy to hear it. So thanks very much for listening. I'm here all week. Come and grab me and I'm happy to set up your account for you, give you a demo and show you how it works

with your data and you can go away from here and use the portal. Thanks very much.