We recently had a chance to sit with our customer, W Energy Software, to dive into how they leverage HyperTrack to create solutions to easily plan, assign, and track work being done in the field.
W Energy provides software to the oil and gas industry and have needs to track work being done in the field and assign tasks to technicians via mobile apps.
Watch the webinar to learn how HyperTrack helps with the following for companies who depend on mobile powered field service work.
• Assign tasks to agents in the field
• Create routes for teams of field engineers, operators and technicians
• Report on tasks completed in the field
The following transcript has been edited for clarity.
Muiz
All right, let's get started everybody. Good morning. Good morning. I'm joined by the amazing Shrivan Kamdar He's the director of product at W energy software, and Mujaheth Mohammed, senior tech lead at W energy. They're both veterans of the company have been around through many iterations of their product. And they're here to walk us through the tech the implementation and how they got to where they are today. Take it away!
Shrivan
All right. Thanks, everybody. I'll just get started. So the product that uses HyperTrack in the field is called JOYN from our company primarily focuses on field users in the energy industry. The module will be looking over today's FSM. And showing a little bit of about what it's about and how we utilize HyperTrack within the use cases.
So I'll give a quick overview of the problem we're trying to solve.
So we as a company, we do accounting, production and transportation, we'll be focusing on production today. And our ethos is three pronged in terms of pragmatic innovation, you know, just practically innovating and having R&D with the purpose, not science experiments for the sake of science experiments, that leads to us delivering speed. And the best type of speed is the type where the customer doesn't have to wait for an enhancement or doesn't have to wait for help setting things up. So that didn't lead to self service.
What we're trying to do on the pragmatic innovation side is do small bets with big wins, our main focus is minimizing cognitive burnout for users. A lot of times they're having to context switch between multiple pieces of software.
And what we focus on is getting that last mile delivery efficiently from many different systems onto a single lap and a single screen. So folks can do the work they need to do. Without having that cognitive burnout.
We do have 62% of our staff in R&D, versus an average of 35%. And most other companies, we use that to lower the risk of everything we're trying to do for our customers, since the energy in business does have a lot of inherent risk involved. We talked about the single pane of glass, because we're lowering the risk upfront a lot of our prototypes and pilots have a high success rate 85% Plus, and everything's pretty much on the cloud.
Shrivan
On the self service side, we want our customers to set up but not build, hire consultants and do other expensive stuff, we just want to set up and go. So we're focused on delivering that underlying how, and so that the customer can deliver the what for the who, when and the where.
So again, you know, we're just trying to reduce the number of workflows and configs that require a lot of support.
Shrivan
And finally, when it's time to go, we want the customer to not have to do the no go no go decisions and just go fast. So this means we implement fast setup use cases fast, provide fast time to value. And then again, you know, going back to lowering the risks upfront. This is all while maintaining safety and compliance.
Shrivan
So when it comes to production, we're able to turn up field production capacity, what that means is, we're able to add 15% full time equivalent headcount without actually adding extra headcount.
Shrivan
We reduce a lot of the workflows in the field, from 10 days to two days or even less, in some cases. Same day reg reports, an increase into the visibility in the field, which is more we'll talk about today. And the application of HyperTrack within the context of that we're able to integrate systems fast since we do understand the customer's systems and their business. So we're able to integrate systems that usually take other companies six months down to 30 days. And then you know, going back to that visibility.
Shrivan
A lot of it is due to the multiple systems in most companies. There's a lot of tasks that happen off the books in text messages, Microsoft Teams, so on and so forth. So we're trying to get that down to zero so that there's complete visibility across the board.
These are just some of the people we went for, right? Whether its visibility at the lowest levels are there organizations that field text vendors, lease operators, all the way up through the engineers, dispatchers. In some cases, even the accountants although we won't touch on them today,drilling and completions in the case of oil and gas and all the way up to the executive suite.
Shrivan
Going back to the cognitive burnout we spoke about a common scenario in the field is you got four guys asking for a tasks from one guy in the field. All these eight tasks are coming through multiple systems, Outlook text messages, actual software systems teams, through a couple of different interfaces, laptops, mobile devices. And then they're turning around, they're taking sticky notes, writing stuff down in their notebook, going into their phone, going into their laptop, and filling out other types of systems excels teams replying to emails, text messages, what not.
Shrivan
So just to do these eight tasks, if you do the math here on the permutations and combinations, this one person, before you ever picks up a wrench to go do the work he needs to do, he has to make 6144 mental decisions just to do these eight things. So that again, that's before he ever picks up a wrench to actually do what he was hired to do.
So what we're trying to do is get those same eight requests into a single field app versus all the other stuff, you know, regardless of what systems they come through, and then he turns around, does the work on the field app, and then lets the cloud integrate to whatever other systems need that.
So this, if you do the math on this scenario, it reduces it down from 6000 plus nodes to 32 mental nodes. So that's a 99% reduction in cognitive load. And that's where we're our focus is trying to reduce that cognitive burnout in the field via this effective last mile delivery.
Shrivan
This is kind of how we use HyperTrack at a at a super high level, we have the SDK on the mobile app, and we connect to the HyperTrack cloud, from our cloud database. And then we have API's from our database in the cloud to other systems for integrating back and forth.
While live locations is great, and this is, you know, an example of what we've used in the past with HyperTrack service, you know, you're able to see where people are, where they're going, how much time they've spent at different places.
SVrivan
But, you know, for us, it's all about the contextual relevance. So being able to pull the HyperTrack live data into our dashboards, and overlaying it with the tasks.
Shrivan
So for example, what I'm showing here is a location when it was last entered, and last exited,what the task on that location was, and who was assigned to. So this is what our customers really like to see is, you know, they want to see their map, they want to see their tasks.
Shrivan
And then they want to see their people moving around in the field. So it's kind of using the HyperTrack data and overlaying it with our internal data. Other things we've done with the data is, you know, we've analyzed stop time and drive time for our customers. So this is like some of the dashboards that they create.
Shrivan
So how long are they at a stop? Versus how long did they spend driving around just to see the balance of the two and whether they can have more effective routes?
You know, what, what locations are they spending most of their time at? And how long were they there at those locations? And how many tasks were done at those locations? So these are some of the other things that we've seen some of our customers do.
Shrivan
And then they do these load analytics, like, for what point of the day are they doing the tasks at and what type of tasks are they doing? So, you know, this kind of gives them an idea, since it's a 24 hour operation? What's happening during day shift what's happening during night shift? And, you know, what are the counts? And are there things we can move around?
Shrivan
So, I'm just going to do a quick demo of what the application looks like. And then I think, Muiz you have a separate section after that for just like a some fireside chat type stuff. Correct. Exactly. Okay. So let me get out of the PowerPoint here.
Shrivan
Okay. All right. So we have the mobile app on the right, that's my iPhone, and we have the web browser on the left, and that's what the dispatcher or the foreman or somebody else would see. So what you're looking at is all the people you can dispatch to you're looking at what the tasks are and who they're assigned to.
So this last task here, that's an AVL inspection, which is basically an inspection in the field, where you're testing for hydrocarbons and seeing if you can hear them, smell them or see them, I have clicked on that task, and I will go ahead and assign it to myself. And once I've assigned it to myself, it appears here on the mobile app. So that's the AVL inspection.
Shrivan
What I can do is, I go in, and I can accept the task. Once I accept the task will see this little clock icon next to my name turned green. So there it goes, it's green, and it shows I've accepted the task. And now what I'll do is I'll fill out this form, saying The seals are okay, there's no corrosion on the roof, the vents are in good condition. I don't hear any leaks, I don't see any leaks, I don't smell any leaks.Everything's free of debris. And I think the rest of it, I haven't made mandatory. So I will go ahead and skip that. I will put in my signature.
Shrivan
And then what I'll do is I'll add some comments, completed the task, take a picture of these little sticky notes here. Send that in, and then I will say the task is resolved.
And once that's resolved, we'll see the updates here. And then we'll go look into the actual task. So there you go. It's resolved. Now if I go in and look at the details.
So we can see the comment updates where I said I completed the task, we can download the image that I took. And I think there may be some delay.
Shrivan
Okay, let me know if the screen is keeping up, I just showed the picture of those sticky notes that I took on the mobile. Yep, it's all good. All right. And then you can see what I filled out on the form. So this is the form with my signature. If you want to save it as a PDF, you can always print it and it will print out as a formatted piece of content as a PDF that you can email out if you need to. Sometimes that takes a while to preview. Alright, there it goes. So it'll just formatted like a form with the signature and you can save that as a PDF printed out whatever you might need to do.
Shrivan
And then all the way at the bottom, there's a big audit trail along with and here's where some of the mapping information, we've also contextualized within the audit trail of the task. So you can see where I was when I resolved the task, and I think this specific task, let me see if I can. So sometimes it'll show two flags, I think this specific location didn't have a lat long in it, but it'll show two locations where the task was and where I was when I actually resolved it. So that's also something we use the geo geo analytics for.
Shrivan
Other things we do is, you know, like we showed on the map view, which since this is a demo site, I don't have anybody live running around in the field. But if we did, we'd be able to see basically what's going on, and you know, where folks are in the context of the tasks.
Shrivan
So obviously, this demo sites and nobody's running around, but that's the reason they showed the the image earlier of you know how that would look. So that's that's it for the demo. Just wanted to give a quick overview of you know, what we're trying to do for the customers but, Muiz, I think I'll hand it over to for the other topics that you had?
Muiz
Amazing. Yeah. So let's jump into, you know, just like a fireside conversation about the technology that you guys are all using, how it works, how you make decisions, technical decisions, the architecture and core behind that. Um, before doing that, let's talk about you guys as yourselves for a bit. I mean, I'd love if you guys could both give us all some background on where you started your careers, your backgrounds in technology, how you got into the software industry, how you got into logistics industry specifically.
Yeah, let's start with you Shrivan, how did you get your start?
Shrivan
Yeah. So I am a chemical engineer, I worked in oil and gas and downstream refining for about eight and a half years.
After that, I joined Seven Lakes, which was a tech company that was operating in the upstream oil and gas industry, which is more, you know, drilling and producing oil out of the ground versus refining it. And we were working on technology for upstream oil and gas companies at the time.
So that's kind of how I got in in terms of just having the general knowledge of the background and understanding of the business. So then started working with developers, like Mizzou in terms of building software for what the market needed.
Very cool. So very long, storied oil and gas career.
Mujaheth, how about you? How was your career? Like, how'd you get started? Would you how'd you get into tech?
Mujaheth
Yeah, so basically, I'm from a tech background. So I joined Seven Lakes, like seven years back I was working on different products, and one is analytics and, and then JOYN this field service management. So that's how I got into this logistics technology. Not much background. But tech wise, that's how I got into this product.
Muiz
Amazing. So you guys both mentioned, you know, you guys have both been with Seven Lakes turning into W Energy for a very long time now.
How did you guys really, you know, having been through that whole process? How did that how has that conversation of building your own tech in house versus buying third party tech? Whether that be packaged solutions or libraries and, you know, existing models? Has that conversation come up? And if it's come up? Where do you guys really stand on that both individually? And as a company?
Shrivan
Yeah, it comes up all the time. You know, we, we do have quite a bit of engineering prowess in the company. So the tendency is to build it yourself.
But, you know, we do from a product speed performance, you know, what our core competency is and what the value is that we're trying to deliver. From a product lead growth standpoint, does it make sense we do that?
Or is it something that's been commoditized by a specialty producer that we can leverage for what we need?
Right? So you know, there are there are a handful of things in JOYN where we've leveraged other companies HyperTrack being one of them.
But yeah, I'll pause there and let Muju add his his bit.
Mujaheth
So this question always comes up because a lot of tech companies who are building field work solutions whenever we want to use that kind of module like HyperTrack versus blank schedulers. So the tendency is to evaluate first, basically, and then make a decision.
Like, what is best suited for it? So in the beginning, we always had this tendency of building something of our own. For example, we started making our own framework, but it didn't end up being because it has a lot of performance issues, all that stuff.
Mujaheth
There are many more examples which made us believe that it's better to use the product which another tech companies working solely on that so that's how we started with HyperTrack basically.
Muiz
Okay, so I'm sure both of you really is you guys are focusing on what you do best and letting other companies deal with what they do best and really just finding that perfect balance of building what you're good at and letting them buying what other people are good at.
Shrivan
Yeah, and and a lot of times, it's about focus, right like, and I always feel with the engineers we have, we could build anything, but doesn't mean we should build anything.
It's, it's, you know, if if it like, for example, what you guys do, there's companies that have tried to do, what HyperTrack delivers. But when we've, you know, and I think we'll get into it, but we've tried some of those those things out. And even with all the resources at their disposal, they were a few years behind, and still working through what you guys were struggling with three, four years ago.
Shrivan
So, you know, even if you have the best engineers in the world, if you're playing catch up, it's kind of pointless, especially if you're playing catch up on something that's not your core competence.
Muiz
All right, so on that note, um, you guys have both been with W energy previously Seven Lakes for a very long time. When you guys started initially working on your location tracking services,
you just mentioned you guys did look at other providers.
What was that process really like? I mean, who did you guys consider? What was that consideration? What did it really come down to in the end?
Shrivan
Yeah, so I'll, I'll talk about the business side, and then would you you can talk about the tech side. So we started with you guys. And we had, I think, the first iteration of what you guys have come to market with.
Shrivan
And yeah, it was it was, you know, to be transparent and blunt, for the matter. It was definitely demo’d well. It worked well, in a few use cases. But there were a lot of gaps back then. And through that journey, well, well, you know, it was still it was already implemented, and customers were able to use it, there were a lot of new asks and features or, you know, once it got used, there were a lot of gaps in the data, because of, you know, just connections gone missing or, you know, offline scenarios, or whatever it is, that were not coming through.
Shrivan
And while that was going on, we did look in other places, primarily Amazon had come out with their location service. So obviously, you think, you know, bigger company, it's going to be much better. So by this time, we were probably in the second or third year of of utilizing HyperTrack. And at that point, I think you guys were just turning the corner in terms of, you know, the quality of the data, figuring out how to get around the gaps. And we were kind of seeing that improvement. But we tried out Amazon anyway, thinking, Okay, it's probably been tested and developed by 1000 engineers, and you know, the typical perception you have when something has the name Microsoft or Amazon on it.
Shrivan
And then once we actually did like a small pilot of it, we found out they were having the exact same problems that you guys had in year one. So, and in some cases more, and in some cases, less. But overall, they were a few years behind you guys, so and then we started noticing every week, your stuff was getting better. Whereas with the AWS Location Services pilot, it felt like we were living the same journey we did with you guys three years ago.
Shrivan
So we shelve that. And you know, even from a cost perspective, it was not much of a difference, because initially, it feels like AWS is always going to be cheaper. Once you get into the details, it wasn't that much of a difference.
So then it was just a matter of okay, what's getting better, faster, and what's working more, and, you know, then we stuck it out with you guys. And you know, I think it's, it's you guys have come a long way. But Muju I'll let you, you know, talk maybe more on the technical side.
Mujaheth
Yeah, so the beginning of at the beginning, like three, four years back when we started with HyperTrack, so the concept of geofences interested us.
And we had to create the routes initially. So that I think it worked for well for us at that time, but as the time progressed, the customers were asking why we need to define the route initially. So that was a pain point and which and then a lot of gaps in your product at that time. So while you guys were working on your new stack, we saw that the data discrepancy, some data was not coming through to us and some of the geofences were getting missed, basically. And then we had to look at this AWS and AWS has issues like since they are new their SDK is not that great.
So we had to write our custom code of handling offline scenarios, or foreground background scenarios. And it was it was becoming difficult to manage basically, some of the locations were missing. And then AWS, so it was good with AWS, because everything is integrated, because we were also on AWS. But since the reliability was missing, so that was one point when we integrated it. Second is when we evaluated for cost. So it's pay per use still, for the use cases we have it was it was going beyond what we’re charging for customer.
So then we're back to this HyperTrack, I think your product, which is on new stack, I think I think you're also on AWS, I think we, we are seeing much improvement, the SDK is fine, it works very well.
Offline, background, foreground, all the scenarios, it's working well. And the reliability is back a little bit. And since now you moved away from the concept of routes to Geofences, it's very easy to integrate into our use case.
Muiz
Amazing. So we really, for both of you, as you know, you would tell us look to other other platforms and realize that, you know, while the their location tracking might be there, they're years behind in terms of outage handling exceptions. Handling any sort of non-happy case scenario really is the feedback I'm getting from you guys.
Shrivan
Yeah.
Muiz
Okay. Um, Mujaheth you mentioned that you had to write custom code for the background. Okay, so was it just simple things like asking for permissions? Or like, Was there more complex outages that you guys were being faced with with the Amazon solution?
Yeah, I'm not sure what is the current state of SDK, but at the time when we are piloting, there is no offline support in that SDK to send locations or location updates to the database versus AWS.
Mujatheth
And even foreground and background was, it was not working well. So we had to like custom code then. And so so we had to create more API's to talk to AWS location services. So that was one more deviation from our main product.
And it was not the level whatever the code we wrote, it was not coming well, because there are a lot of minor, minor cases like network bandwidth is slow, network is slow. So all those things we need to consider, I think, which we couldn't focus. So that's that's the uncertainty was happening.
Muiz
Okay, it's like the technical demand of even implementing Amazon became greater than developing your own product, is what I'm sort of hearing.
Mujaheth
Yeah, to have better reliability. We were losing focus. We had to spend so much time on sending these locations to AWS.
Muiz
Okay. Now, you know, having gone through all of those changes have been there for so many years on the part to the grown immensely in all these years. How do you guys really handle features, scope increases versus technical complexity and making sure the architecture stays simple and easy to easy to iterate on?
Shrivan
Yeah, so I mean, with this product that we just saw, the roadmap is pretty fast paced, there's, there's constantly new things, most of the work we work on are, you know, maybe 10 15% fixes 85%. net new add. So I think it's, it's, it starts with clearly defined product requirements in terms of, you know, it's not just the acceptance criteria has to also involve what are the performance criteria for this feature?
Like, if I click this button, then, you know, given I'm a field user, when I click this button, then this should happen. Okay, well, Muju can give it back to me a week later, and it happens. But maybe it took five minutes, because I didn't say it has to happen in three seconds. So, you know, a lot of those things need to be considered upfront.
A lot of times I think, features are easily designed without the performance criteria that are required for the features. And, you know, you get something that works, but it doesn't work for the context in which it needs to be delivered.
So, you know, I think we've learned that on our journey there to where our acceptance criteria, we have an agreement between engineering and product that unless it unless the user flow is clear, and the user expectations are clear, you know, it can't get developed. So it doesn't go beyond a specific status in JIRA, so to speak.
Shrivan
So once those are clear, then, then you know that then it's on engineering to go figure out the right way to do it, whether it's you know, third party thing or self developed or some library or whatever it might be.
Shrivan
So, Muju, if you wanna add anything?
Mujaheth
Yeah.
Mujaheth
So basically, yeah, and understanding is that whenever any feature request comes, we have a clear understanding, what needs to be delivered.
Mujaheth
And once we have a better understanding, then we go and check it out: Ok, What can we do?
Can we build in-house? But there's something already existing, we can use it.
Mujaheth
And what, and what is the timelines available to us and then that will guide us and then what it was basically,
Shrivan
Yeah, one example, you know, like, getting this, get, getting the live locations within the context of the tasks that are there.
Shrivan
So, you know, initially we found, ok.
Shrivan
Well, do we want to minimize the data?
Shrivan
Can we get the location every 10 minutes?
Shrivan
Well, if someone's driving down the highway at 50 miles an hour and you're updating your locations every 10 minutes.
Shrivan
Well, he could be many miles away for you to look at the map and be like, hey, you're right next to it, go turn around and do that when you call him and he's like, well, no I'm, I'm five miles away now I'm, I'm done, I'm not going back.
Shrivan
So, you know.
Shrivan
Ok, well, we need the map to update every two minutes and, you know, every 30 seconds or, you know, every 20 seconds.
Shrivan
So those are, you know, those, those are some of the things that, you know, within the context of HyperTrack that we were looking at and as well as when we were considering Amazon.
Muiz
Amazing.
Mujaheth
One more thing - the cost of using these extra products also come into picture, one more criteria to what you choose.
Muiz
Makes sense. You know, on the context of like the live locations, updating your data that frequently when you guys are designing your data pipeline and really figuring out, you know, what data do we store?
Muiz
What data we showcase, what data do we highlight to our users?
What considerations go into there because that's also another point that can cause a lot of technical blow and a lot of technical debt and a lot of with a lot of solutions.
Shrivan
Yeah. So again, we we start with from a product standpoint, what does the customer wanna see? OK.
They want to see the location. OK. Then we bring that data in. OK. Well, now they wanna, you know, use an API to pull what locations were visited within a 24 hour period.
OK. So then we know we need to store that but do we need, you know, everything from every second of every day? Probably not, right.
So from a product standpoint, those are the questions we ask and then that then helps engineering do what they need to do. But I think Muju you were about to add something.
Yeah. So for this for this use case, I'm giving it as HyperTrack example. Locations services example because it's what we're discussing.
Mujaheth
So currently we don't store much on our side, we just store geofence events, because that's the only thing we are, I mean, our use case needs currently as everything, everything is stored on your side only whenever we want to be, we fetch it by using UK.
Mujaheth
But in future, right, we have these we are planning new features like if the customer wants a dashboard out of the data user data.
So then we might start storing that information in our, in our databases. But currently no one is asking that. So they're not storing it currently. So that is one use case.
Muiz
OK. And then, you know, this is more of a product question but when it comes to highlighting data, I mean, you know, I'm sure on a regular day these this task screen would be, you know, so full that it would cause visual, you know, cognitive load.
How do you guys highlight and showcase like the priorities you guys have? For example, where does it come into play?
You guys focus on, you know, things like just the schedule times or do you guys have more a more dynamic, prioritization and urgency that comes up for?
Shrivan
Yeah, so we have four levels of priorities, low, medium high and then critical low, medium high is just mostly all routine stuff that can be classified.
Shrivan
So you're, you're probably not gonna go out of your way to do a high, you're, you're just gonna, you know, if you're getting towards the end of the day and you got more highs left than lows and mediums, you might skip a few lows and mediums, let them roll over to the next day and increment in priority.
Shrivan
So we have a priority increment as tasks get older, they move towards their max priority.
Shrivan
So there's a concept of, of a max priority where a certain task type can, the highest it'll ever be is a medium because it's never more riskier than that.
Shrivan
There's also a critical level of priority which means drop everything and go do it now.
Shrivan
So those are usually highlighted like across the gray and purple.
Shrivan
Also on the mobile app, no matter what location they're at, the critical tasks always float to the top.
Shrivan
And then as far as you know, resourcing and having a, a kind of an A I engine.
Shrivan
We do have an engine that looks at things like, what's the skill set of the employee who has the labor availability?
Shrivan
What is the labor availability?
Shrivan
Where are they in the field?
Shrivan
Are we prioritizing for priority or are we prioritizing to minimize distance in their drive?
Shrivan
Do we want to cluster higher priority things together as much as possible?
Shrivan
Do we want to freeze the next two hours of what they're doing in their day so that you're not jerking them around left, you know, throughout the day and changing their assignments.
Shrivan
So these are all the things that go into this little task engine that we have and people can run that multiple times a day. So that any new tasks that are coming in are constantly assigned to the right people.
Shrivan
So those are some of the different ways and how priorities are handled.
Muiz
Amazing. So as all the tech technical questions I really have for you guys right now.
Muiz
What's next for JOYN? What's, what's the future look like?
Shrivan
I think within the context of location services, which is a big, big piece of moving forward.
I think, you know, one thing we're trying to add is right here where you see all the people, if someone is still in the field or you know, hasn't moved in 15 minutes, 30 minutes, what, whatever, you know, the customers decide that number to be.
Then we're thinking of having some type of a visual cue. That's like a safety indicator that, hey, you might want to check on this person. Because their geo position hasn't moved in so much time.
Shrivan
Other things we're looking at is for each task, we know how long they spent in the field using the geo fence data.
Shrivan
So we're gonna try to map those time in the field to the task type and then do some machine learning in terms of recommending how long the task should take.
Shrivan
And then even doing some analysis in terms of comparing where, hey, when it's vendor A, it takes 30 minutes and when there, when it's vendor B it takes 90 minutes.
Shrivan
So is this real, are they doing some steps that vendor A is not or is vendor B over, you know, just hanging out there to get more money?
Shrivan
You know, those are the types of things that we're looking at doing in the future to further help our customers.
Muiz
Amazing.
Muiz
And now if there's any questions, feel free to drop in the Q and A, everybody in the chat right now. And otherwise, if there's no questions, Shrivan and Mujaheth, it was great having you guys.
Muiz
It was great learning about JOYN and the technology that powers it along with the architecture decisions that you guys made to keep it as efficient as possible.
Shrivan
All right, sounds good.
Muiz
We do have a question in the chat right now. So how does the move to on demand and gig work impact, impact your business?
Shrivan
So we, we're not sure how it impacts us directly.
Shrivan
I mean, I, we're, I got a feeling our customers might be hiring more, you know, on the job contractors, especially some of the smaller customers, who, you know, may not be having.
Shrivan
What do you call those, like approved contractor, list type of business processes where, you know, you can only use an approved contractor based on your, your supply chain groups, agreements and negotiations, you know, some of the smaller companies don't have that.
Shrivan
So I, what they're doing is they're involving, they're giving our app to the vendors, giving them a log in and then the vendors are able to log in directly to our app.
Shrivan
Whether it's on the web or on the mobile app and do the work that the company needs them to do.
Shrivan
I think what helps is when a vendor logs in, we have security available to where they can only see tasks applicable to their vendor company and no other vendor.
Shrivan
So even when you're working with potential gig worker, maybe, you know, you, you could be paying them one rate and another gig worker who's doing this similar thing, another rate without any of them knowing.
Muiz
Amazing. I'm not seeing any other questions coming in.
So on that note, it was great chatting with you guys are getting to learn from both of you. So it was great getting to talk to you guys for getting to learn from you guys. Hope everyone has a great day.
Shrivan
All right, thank you.
