Welcome to tonight's webinar All About Omnitas new custom ticketing portal. With you here tonight is, of course, me, as usual, your moderator, Fredrik Kastenholm, and my ever-comrade Thomas Karlsson. And he's also happened to be the product owner of the ticketing portal, so I'm not going to shut away. Instead, I leave it up to you, Thomas, to give us the great big tour of this splendid new technical. Welcome to Omnitas Ticketing Portal webinar powered by make, formerly Integromat. The ticketing portal that we're going to be showing you today is based on monday.com and powered by Make. Uh, so it does need, uh, a combination of those two services. But as a portal in itself, it could in theory use whichever database we want. It's just that monday.com happens to be very nice and working really well with Make. Yeah. And we happen to work quite a lot with it. Yeah. So before I start showing you the portal, I just want to show you the conceptually parts of how everything actually works. So we understand what we will be looking at later. This is this is it. This is this genetics. It's like super clear, right? We don't need to explain it, but, uh. I think we can just jump on from here. -And. -Everything. So we have someone, a client, a colleague. Because the cool thing with the ticketing portal is that it can also be used for internal uses. We we actually have the first customer used for the, uh, graphical or marketing team to manage orders from without the whole organization. Uh, so this little character in that case was actually a colleague in another department. But you start a process by generating a form and monday.com with work forms. Quite easy, quite simple. We're still using the basic ones for today's webinar because, uh, that shouldn't be the main focus. The form generates an item in monday.com Obviously someone at the company or in the agency gets notified and they start working the ticket, just like any other ticket that you see in monday.com, right. So that that's not the, the, the particular thing about this portal. What also happens is that Make will get a webhook and and we will learn that there's a new ticket. We will send an email to the person saying, thank you for submitting your ticket. Here's your ticket number. If you want to check how your ticket is doing, you can go straight to this URL. And there's also a a login portal if you have multiple tickets. Because some of the organizations will have single tickets, some organizations will might have multiple tickets per submit. The right. -Um. -And all of that is being managed by Make. And Make is then also presenting the actual portal. So when the user clicks and gets to the portal. In this example, we have shown you a uh two way. So first you get to a place where you can see all your tickets, the name of them, the deadline we type and status just as two examples. And then when you click them, that's when you get all the information. And as you see, we can have a chat about it. And the chat will then go back into monday.com. And it's really cool because all we're doing is using the update features of monday.com, basically the chat bubble to generate all this conversation. So we also can set up webhooks. So when an operator agent, support person or uh, when they write something for the client, they will automatically, if we choose to get an email saying like, hey, there's a new comment on your ticket, please click this link and then they can get straight into the ticket as well. So that's really cool to know. Obviously, I know this a little more by heart than you do. Fredrik, is there something that was unclear, something that you would like me to clarify as part of, uh, -this slide here? -Yeah. So. Coming back to having that communication back and forth. So we can do that with people that have no monday.com account whatsoever, especially not my monday.com account. -Correct. -So we don't need to fiddle about with guest passes or, uh, -viewer permissions or anything. -It's just very sad. And that's the whole point with the portal. If you're if you're fine with using guest access in monday.com, to be honest, you don't need a portal, a portal list when you need to interact with people that shouldn't even be guest. They shouldn't even be viewers. Even if we have item level permission enabled, a viewer with item level permission cannot communicate. They cannot add files, they cannot update. Um, the ticket. And this is what you want. You want to have a two way communication or a two way -collaboration even. -Um. Yeah. How nice. Wouldn't it be? Just be. Hey, dude, you didn't remember to upload all the files? -Please do that. -Yeah, and actually, we do have one example, I think, where we can even see that you can actually share files. To the person receiving it. So person here do we want to jump in and look? -Check out what it looks like. -I think that's about -where we're going. -Yeah. Cool. So just to add some complexity to this, in our monday.com board we have a ticket in name, a responsible person, a general status for the ticket. We just wanted a status column with type one, two, three and four just to be able to show additional information, some kind of deadline, a longer description. And then we wanted to do something really cool. We have who's the owner of the ticket and is there anyone else in my organization involved in this ticket? So in this setup, we can actually see the difference between tickets we own and tickets where we are collaborators, as we're calling it. And obviously in the form we we had a very simple little checkbox, right. We used a normal monday.com form, ticket, name type, deadline, description, ticket owner, stakeholder. And then we have the little concept form down here. And I wanted to show you one of the. I think it's this one. Yeah. So as you can see, new comment testing, communication test reply. And this is an image uploaded into the updates. Right, right. Cool. So this ticket is ticket number one. It belongs to Lucas. So. Let's jump into the portal and look at how. It looks like. So we have it's done right. We have a description. We have a bit of stakeholders. You are the owner of the ticket, Frederick. Just you know, I hope -you've done what you're supposed to. -Of course it's done. -I was quick about it. -And the actual ticket is actual portal. In this case, it's just a blank. We joked about saying that we have actually purposefully made it as ugly as possible, because we want to show people that this is not the final CSS and final styling. Obviously, the the the portal ticket, the portal will be styled to fit what you guys need, and there's the full capability to do any styling with the divs and classes and so on. So we have a lot of control. So we purposefully kept it blank. So in this case I'm also going to come into what variations we have for login and stuff like that. In this case we're just doing an email address. So in this email address I can now log in and I will get a list of all the tickets belonging to Lucas and where Lucas is a collaborator. So this is the ticket one that we were talking about. So if I click ticket one. It brings me straight into the information we get the ticket number, which happens to be the item ID in monday.com. The name a long description, the type, the status deadline. Fredrik, you being responsible for this. Right. Like we discussed. And then we see the communication that we had and test reply as you see there's actually a file on when I click the file it does a download for me so I can actually access files. I know we just emailing a file with the monday.com email integration. It's not that easy. -Uh. -Not us. Click, click. -No. -In this case, you can actually obviously we want it to give us many options as possible. So it could be saying like, hey Lucas, thank you for this. In order to process your request, we need you to fill out this, uh, waiver form or, or this, uh, other, uh, form, uh, for us to get all the information we need. And, uh, and then you can distribute it easily. We can then fill it out, and then we can submit it back with a reply and just hit submit. Uh, we actually got a question here. Uh, what software is used to build the -portal? -So right now, uh, it's, uh, it's in vercel. Uh, but it's a code that's, uh, transferable, and it can be self-hosted, so we don't need to host a portal for you. You can self host it as well, uh, and run it with, uh, on your servers. Currently, vercel, uh, that's powering this demo environment, because that's the easiest one for us to set up. So, and, uh, from what I see here, um, of course I get some information and I can also upload files. I can't only receive files, I can also add files. Uh, for all of you. Those of you who don't speak Swedish, uh, Thomas computer has actually, uh, put in "Välj fil", which means, uh, choose a file. Yeah. This is this is localized, uh, because it's using basic, uh, web browser technology. Okay. So I write a comment on the portal. Right. Submit. What now happened is that. To get one. I write a comment on the portal by Luke Abbott, which is named after the guy who wrote all the make scripts. Uh, so Luke got it out here and so quite, quite nifty in that regards. -Yeah. -And as we see, the response time is quite snappy. Yeah, yeah. It goes uh, and then we can say, uh. I answered in monday.com and everyone -was happy. -Update. Right. And what? So let's go back to this little schematic here. So when I now make the update I could toggle it to say send an email and saying, hey Thomas, you have a new reply to your ticket X, Y and Z. In that email I can insert a link straight to the ticket as well, making it so I jump into the ticket instead of landing into the login page at all. So I don't even need to land in the login page. -So you can. -Basically skip all of that just to get in there and make it really, really easy for your colleague or client or. Yeah. -Exactly. -You write something in the update, the update generates a webhook, Make pulls it up and populates the portal. And we actually I think currently, yeah, we're using make to send the email and it arrives at the person's. So let's see here I answered at monday.com. Everyone was happy. And then I refresh now but we just have click the link and you see there's my comment. Everything's there. -Really. -Really, really great. And it solves a really big problem driving monday.com us. And it's basically and really getting into that communication with with your clients. -Yeah, I. -Also like the fact that you do get quite a nice little, uh, if, if you're someone who submitted a lot of tickets and you want to follow them up. And obviously that we said we're going to go into the variations later, but we could email ticket number, combination, username and password, single sign on. We have all. So this is just a simple one, right? Because we don't want to weigh it down with this. So as you see my ticket, my collaboration tickets. So these are the ones I've submitted. Those are the ones that someone else submitted and said I'm involved. And that's really great because it's really nifty to know, say you're a manager and you're using this for internal purposes, for example, ordering computers or phones or whatever from the IT department. It's really nice as a manager. Yeah, I know where I'm a collaborator. Just so basically I'm there for the information or when it's this, -my specific order and stuff like that. -So and we also have like let's talk about some support functions where individual people within your clients can submit tickets, but then you have one person or a few people within your client organization that wants to be able to check all ongoing tickets that they have with your service. You can still take care of that. And if you know those rules, you can build. So if a ticket is submitted by this domain, you always fill out another field. So those people will get a very big comprehensive -list of course. -Yeah that's that's true. So you say for example, you have um Volvo, let's use a Swedish example here. And then as soon as someone emails from an avelo.com address basically route that person in as a state caller to being just having all of that. Yeah, that's really, really great. Exactly. And like I said, we can click it in. We see this is also some replies a few hours ago. So we actually got a question here which actually not so fine here. Uh so can we ask is it possible to generate tickets created via email as well or only via the form. So. So really look at this. Let me just log out. Uh, so this is the form, right? But I can do. Anjali, I still need to put my email address over here. Or the client in this case. And that's what you won't get any columns filled out if this is generated by by email, -correct? Right? -Yeah. Otherwise you will have a major headache trying to parse. -A pure text. -Email. Hmm. So, uh, but if you have some kind of email parser, you could have this sent over email. To be honest, there actually is a good email partial with make, so you could have all the emails going into make parceling it so you get at least the sender's information and maybe all the people that are CC:ed over here. And this would be the. -Email body. -That will be the body of the email. So at least you get some more information, right? But not the full not the -full one. -No. So for example the type. So if this is a say your that ordering department in your company again you couldn't be shooting. This is an order for a cellphone or an order for a computer that you might have problem mapping in. But that on the other hand could be -added manually by the operator. -Yeah. Definitely. Because someone still needs to be assigned, you still need to give a status and stuff like that. And it's not a big, uh, hassle in that regards. Right. So, so these items in here can be generating any way we want. In theory, this could be a shareable board with our clients. And then we have the portal for someone else to just look at everything. I'm just saying that there's no big limitations on it, to be honest. And when we now log in to have a look, see and see what happens and now ticket generated manually date is missing on categorized not started because that's what we had over here. So we can do the good stuff we can have working on it. Type two. And then now let's set the deadline. And uh, why not also say. Hey, uh, can you please tell me, uh, if you want X or Y. -Right. -We actually got a few questions here as well. So Sarah wonders, what is the benefit between tracking all of your tickets on the omni portal versus filtering on monday.com? Is it just to solve the transparency between the two applications or reports being created out of -omnibus? -Uh, well. If I'm an operator like Thomas Karlsson working at Omnitas, and this is my monday.com board, where I do case management, the portal is not for me. The portal is for whoever I'm managing the cases against, and I don't want to let them into monday.com or a viewer permission is not enough because I actually need them to communicate with me, or I need them to change some column -values. -Exactly. And now let's just go back and say, let's jump into this ticket. Everything is now filled in, as you -see, as I suggested. -Uh, we. Have one more question from the question about would it be possible to reopen a closed ticket automatically when a customer send a new email after the case is. -Closed? -Yeah, definitely. I mean, this status is currently set manually, but since all of these updates from the portal, right, you write something in the portal, it goes in here that goes through make. So we can also make sure that when we write that update, if the status is set to done, change it. And right now. -It's. -It could be just as you said. It can actually be better to have, uh, closed, uh, as a status instead. But you could since we're already using Make. Like I said, the make is what's creating, uh, all the ones all the comments here, that's Luke bot. So this is the client, right. And when you print, look what we could make it. So if the status is closed, change it to working on it automatically. That's awesome. Have another question from Matthew. How long are tickets stored? Does it show all of my tickets forever? Or can it be configured to only show, for example, last three months? Uh, can you build a in a and can you build in a survey for -feedback? -So um, right now the way we have configured it, it will load all the tickets that are relevant for the search for us. We can add in, uh, business rules as well, because all of this logic is sitting in make and it's it's basically just saying filter the search result based on this parameter. And that parameter could be that it cannot be older than three months and that you could also have it. So when you log in, let me just log in here and show you right now we are dividing this by my tickets and collaboration. We could have it open tickets here and close tickets down here. And we could even have even longer or old tickets further down or however we want to do it. So that's really, uh, uh, that's a configuration part. What was the second part of the question? -Was that the survey? -Yeah. Can you build in a survey for feedback and yes. So how we can do it in a few different ways, right. One would be when the status changes to close a new email sent to the person with the survey obviously on monday.com work form or any third party service to your survey tool that you want. It could also be that on a close ticket, we could actually have a new field where we say, please let us know 1 to 5 how well you appreciate the, uh, how how you got along right and all. In the end, all that had to do, uh, or be was that could just be rating columns, right. Saying so you can actually show see the client feedback. Straight in. So that could be definitely built in. And then you just bring that in as a column value here and you allow them to change it. Because right now this is read only right. We're just patching the data. The only thing we're allowing them to do in this example is to communicate and upload -files. -Yeah. So there's basically a plethora of different ways. So basically make a proper survey for example in monday.com have that and have that actually connected to the ticket. So you can backtrack everything as well perhaps to a client trust if you want as well. So you can see over time or doing it the easy route or anything in between basically. -Yeah, exactly. -Uh, so I guess that's the power of monday.com and Make both because it really gives you a lot of leeway to do basically what you want and what -you need. -These are just some a list of some of the things that we can configure here. We could from a login perspective, we could remove the whole login and just use URL sending you straight to the ticket. We can have email as the sole variable that you enter, just like you saw in this demo. We could have it. So you need to enter your ticket number. We could have two factors or two variables email plus ticket number. Or if we want to create a username and password uh in some combination we can use that as well. And if you use it internally within your company, it's even possible to connect this to a single sign on against your Active Directory. So if you're not authorized in the in the ad, you don't even get to access the tickets, even if your name is on one of the tickets. Right. So that's the logging screen that we were talking about. Those are the the variations we are allowing there. Um, on the ticket page itself, we can of course allow for two way communication, two way file sharing. We can choose which columns to display because we we don't need to display all the columns that we have in the board that. So we can have external columns, we can have internal columns. Just so you bear that in mind. And we can also allow if this column should be changeable or not. Uh, so those two together gives a lot of freedom. Then when we talk about the portal in general, you have. Do you want a list view? Yes or no? The list view was that when you logged in. You saw all my tickets, right? That would be the list view or. Uh. And do you want the detailed ticket view? Yes or no? Because some organizations might just want to present the list saying these are your tickets. These are the statuses. Don't try to click them because nothing will happen. But you can see your your ticket right in the list view. So you can either have only the list view. You can have only the detailed ticket view where you probably need a URL to get straight to your ticket. Or you can have the combination that we just showed. We can group the tickets in any way that fits your needs. Currently, it's grouped on my tickets and collaboration tickets. It can be open, it can be closed. It can be any other kind of tickets. We could have grouped them by type. So saying this is your type one. This is -your type two tickets. -So for. And we also obviously have full CSS styling capability, so it doesn't have to look this ugly -as it does. -But that was intentional. -Yes. -Look and feel like your company, both for internal and especially external users. Yes. Uh, should it be someone else's? We have that question from Tony, and he's wondering a bit what is the benefit of doing this versus just getting ZenDesk on the side? Uh, well, Zendesk is a really good ticketing system. I mean, it it has a portal like feature. You do need to have a login, uh, with username and password, uh, unless you use the URL. Zendesk is another system. So if you want to connect your, uh, tickets to your clients, to your work, to your CRM that you probably have in monday.com, uh, then you're going to have to integrate Zendesk in monday.com. This will allow you to run it straight on to monday.com Uh, but basically it's a good it's a smart question. Told you. Because what we're doing is we're actually creating send this capability on top of monday.com. Exactly. And it's all about that not having 15 different softwares, running license costs and a hassle, logging in, logging out and basically ending the day with like 20 different types of different systems. You're working in and trying to make life a bit easier for everyone to be able to run that. And that is actually one of the biggest benefits, because if you have all your support cases in one system, then you have CRM data, project data, or client, everything else that pertains to a client, some other base example in monday.com, then you're never going to get that whole picture, at least not without running heavy integrations between the systems. Mm. And I mean, we didn't develop this because we thought it was a fun thing. We developed this because we have seen a lot of need, a lot of requests in this category. So obviously there is a big demand of being able to present some kind of portal on top of monday.com. Right now we're calling it ticketing, but you could have it as a product list as well. I mean, uh, whatever your item represent is what that kind it will be that kind of portal. Right. So you could have your whole product catalog actually in this, uh, uh, ticketing portal environment. Same thing. Instead of having tickets, it will be items that are available for everyone, either after login or without logging in. And then you can get different data metrics on those different products. -Which could be really, really. -Nice. That could you build in, uh, say you have a rather long product list, could you build in a search perhaps, or something like that. -Or. -To make. -A. -Filter, a search that that's not a problem. So basically, uh, what we're showing is the ability to use monday.com thanks to Make, to generate content that is available externally that someone can interact with, that in turn generates input back into monday.com That's if we if we put away, take away all the fluff. That's what we have created a way of visualizing monday.com outside of monday.com, but not as a shareable board view that's not interactable, but it's actually something you can interact with. Cavalera wonders, uh, would it be possible to have a direct webhook to Monday from makes? You can trigger changes within monday.com to Make in real time. I don't think I've been following the questions, because all the changes that you do on the ticket will be reflected both ways. -Live. -Yeah. And they are built with webhooks, I presume, without having been -looking under the hood. -Yeah. So everything is is already built with webhooks. So when I do an update, uh, a write an update that sends a webhook, and when I change a column value that sends a webhook and it's been picked up by Make. And then. Yes. -Yeah. -And vice versa. If I do something in the portal as a submit that will send a webhook into Make and make the changes in -monday.com. So. -So it was quite instantaneously when I wrote something in the portal I just changed tab went to that item and the comment was there already from Luke. But you'll follow up on that was, oh, I didn't know. Uh, Make has realtime webhooks for monday.com. They're called watch event in Make uh and we have a webinar on our website on the task last webinar actually that was specifically about webhooks and monday.com. So please check that out. And that actually the look bot -talking. -Yeah yeah it was. And something to mention on this is that uh it used to be webhooks an integral mark. But when we move to Make we actually have a special uh, module within the monday.com app inside of Make that allows us to watch for changes -instantly. -Exactly. Uh, any more questions in the chat? Uh, yeah. Actually, came one from Jeffrey. Uh, would it be possible to add a column to copy email to in order to reply to more than one user? -Yeah, I mean. -This could be a configuration as well. So let me bring you back to the monday.com. Right. Uh. We can either configure it so it only sends the email to this column, or it sends the email to all the people we have in the stakeholder column. We could also have additional email columns that gets filled out automatically based on any of the other variables as well. So again this since we are already have Make in the mix, we are not limited by how monday.com email columns and mirroring work. We have full freedom of create any kind of lookup or rules or a matrix of relationships. So for example, back to that domain check. Doing that domain check could actually add a person in automatically. So okay this is from Volvo. Com okay then I should add in Peter @volvo.com for example. And I will always do that when it's a volvo.com for example. He's always going to be the stakeholder because he needs to know or whatever. So uh, I actually play around quite a bit with uh, email workings within Make and monday.com as a combination, there's not much you can't do really. Just have a go at it. I just came up with a new use case for the portal. We could have someone requesting work by filling out some variables. We have additional columns that in turn presents the quote. Once you fill it out, you change your status. You get an email saying, hey, commit, go in, check out your quote and approve it, and then you can have questions and conversations about the quote through the portal. But you can allow a status column for them to be changed as as the approval or rejection of of the quote. That can of course, as well be done in a shareable board. Definitely. If you want a portal with with your own, uh, style and you don't want to invite your clients to yet another system with which username and password, uh, that could work. -One thing. -Going back to that first use case you were talking about. So you are ordering marketing assets and stuff like that. Uh, quite often happens that you have one person ordering something, but one other person should be the recipient of the done asset. And that could also be so you can have that all communication is going through the ordering person and up until the point it is closed or done. So we are delivering that and then that the second person actually gets the first email. And yeah here you can go in and download the assets. You can use it for approvals. Yeah I mean there's again anything that you want to project outside of monday.com with a higher level of interactive ability than one of the shareable views, you can use the portal. So basically, your imagination is what's going to set the limits to this. Would that be fair, a fair -statement? -Oh yeah. I mean, this is typical of us, right? Where where you haven't built a cookie cutter system for you. We built a framework that we just like monday.com can take different pieces, different aspects, and create different effects to solve a multitude of use cases instead of making a very rigid, non changeable, only ticketing portal. -That actually is. -Quite a typical of us. -Yeah it is. -So here's the basic or here's the framework. It has all the bells and whistles. Now let's tweak it to -match you. Exactly. -Yeah. Yeah exactly. And this also means that obviously this portal is not something that's going to be on the monday.com App store. It's not just an install. And then it goes, you do need to talk to us. We do need to do we have the framework, but we need to do tweaks per each client that wants to use it. So if this is something you're interested in, please give either Thomas or me an email or a call, and you find all of our contact details on our website on the task. Or it's just Fredrik@ omnitas.se or Thomas@omnitas.se So that's where you find all our contact details. So just sling us a mail and we'll talk about what your needs are and, uh, see what we can do to get you installed.