Privacy v/s Monetisation v/s Experience
Let us discuss a unique product challenge about balancing these three seemingly opposite attributes from a marketplace's perspective
Though you can read this article as stand-alone, in order to get full context - consider reading my previous two articles about chat/call features and call masking.
These 3 attributes of a product - Privacy, Monetisation, Experience - are vast topics in themselves. We’ll save ourselves the trouble of diving deep into each one of them individually. Rather, learn about them via a product challenge.
Some context
So let’s get some context about the product in question today - Kaodim.com - a managed service marketplace, with Malaysia being it’s primary market. You can expect to find 200+ types of home services like cleaning, plumbing, electrical repair on the platform.
One might ask - What’s the difference between a run of the mill - marketplace & a ‘managed’ one? Well- marketplaces in general have traditionally been ‘classifieds’ where the ‘sellers’ pay for visibility - the platform doesn’t care what happens to those leads (customers). On the other hand, in a managed marketplace, the platform very much cares about what the sellers do with the leads given to them. In fact majority of a managed marketplace’s monetisation happens when an order is completed with good ratings on the platform.
For example, Mudah.my/services is a service marketplace and Kaodim.com is a managed service marketplace. No points for guessing which one is better for user experience (big time bias!) .
Before we move further, let us take a look at the core loop of Kaodim to understand how customers & service providers (SP) interact on the platform.
You can notice some differences from the core-loops we discussed for food-delivery apps in the previous articles
Longer duration of overlap: Typically it takes anywhere from 30 minutes to 60 minutes to prepare, pick-up and deliver a food order. A service on the other hand can last from a few hours (cleaning) to months (home renovation). The blue dashed area represents the steps that customers & SPs take together during the lifecycle of a service.
And from our previous discussions, we know that an overlap - especially this large - necessitates call/chat feature.Post delivery payment: The services are (usually) not pre-paid, hence the SPs have are the final responsible party for collecting payment. (Why not pre-payment? That’s a topic for a future article)
Multiple orders at the same time: Riders on a food apps, deliver one order at a time (I’m deliberately ignoring multiple pick-ups recently introduced). Whereas typical service providers accept several jobs at the same time & send their teams to serve it.
Now that you have a fair bit of an idea about how Kaodim functions, let’s look at the challenge.
The product challenge
Let us look at the primary issues that can arise with the overlapped core loop for service providers and customers.
The Privacy & Safety problem (High Priority): The duration for which the SPs need access to customer’s contact information, raises the risk of privacy breach. Complicating this matter further - most SPs have workers/staffs that are the actual boots on the ground. SPs will pass on the customer’s contact number to their workers. The risk is practically limitless here.
The Disintermediation problem (Medium Priority): The platform charges a service fee -which is proportional to the amount paid by the customer for the job post completion. To avoid paying this fee, some SPs choose to get the contact number of the customer and cancel the job on the platform. This poses a threat to platform’s monetisation.
The user & SP experience problem (Medium Priority) : As the platform tries to introduce more measures to increase privacy and reduce disintermediation - both UX and SPX suffers. It becomes harder for both parties to contact each other & stay in contact. Several rules & logics impede the speed at which SPs fulfil and complete jobs. It has been marked “medium” priority because any sort of regulation on the platform has an impact on UX - so all we need to do is keep it our sights & manage it.
The solution
Now you’d have to take my word for it that in reality we had to jump through hoops to get to this point, but in the interest of time, we’re going to cut to the chase. And you might have already guessed what the solution looks like - Call masking (sigh! I’m kind of getting tired of it now).
Moving on! Once decided that we want to implement call masking, the next step is to pick the right technology for it - VoIP or VN. Since Kaodim’s primary market is Malaysia, VoIP seems to be the better choice (why? read it here) , but we still went with Virtual Number.
Before the Why , let us understand how VoIP works-
The working of Voice over IP requires three primary steps
Caller device should know how to identify the Receiver device : This is typically achieved by assigning a unique user_id to every user.
Caller device should know how to locate the the Receiver device: Since the transmission happens over a public internet network, the caller device needs to know the IP Address of the receiver before a connection can be established.
Securely transmit and receive: Once connection is established, the caller and receiver can transmit data to each other, but via a server to either encrypt the data or keep a data log (based on use case).
In the diagram above, the TURN (what is this?) server is where this exchange of information happens. For this server to be able to return a specific IP address/Port address to the caller device, it is important that a single user_id should not be connected to multiple IP addresses. How’s that possible you ask? Well, not all platforms restrict multiple device logins with same username and password (Not everyone is Netflix bro).
Of-course you can put in a series of logics & features to determine which instance of a particular user_id’s login you want to consider “primary” to connect the call to - but that raises the complexity and lowers the reliability of the connection.
But Grab uses VoIP, how does it solve for this?
Grab’s users and riders cannot use the product from web. They both need mobile apps. Also, Grab doesn’t allow multiple device logins - it will automatically log you out of a device if you login to a different one. This significantly simplifies the flow to connect a user and a rider via VoIP. Grab’s rule of app only & single login simplifies this mess quite elegantly.
Grab’s daily use-case allows it to demand that its users download an application. Kaodim on the other hand is not a product for daily use- so it is not fair to ask the users to download the application to be able to use it.
Further more, Grab is an e-wallet too- this requires them to secure the login to the application according to regulations. Grab doesn’t mind it because it doesn’t onboard organisations as users or riders (I’m overlooking Grab’s corporate offerings) - so there is no point in allowing logins from multiple devices at the same time.
For Kaodim, service providers are small companies/ SMEs with admins - who typically take the first call, arrange timings, then hand it over to a worker- who contacts the customer to understand more about the problem and last mile issues. All employees of SMEs are not registered yet with the platform. Thus, multiple individuals needs to access the account based on which job they are serving. Complicating this further- there are “SuperUsers” on Kaodim- like concierge of a condominium, who have several individual units under them. So the complexity goes both ways.
Despite all this mess - it is still possible to put in a logic to determine who should primarily receive calls, but as mentioned earlier, it considerably increases the the effort, complexity and reliability. And why do that when you have VN as a viable option!
Phew! Thank you for reading thus far. Now time for some pretty UIs 😍.
Kaodim Virtual Number : The caller (both users and SPs) gets an option to either call a VN directly or share it with an acquaintance (family member or worker). Usually you can only connect to a VN if you are calling from an already registered number. But VN has another ace up its sleeve - PIN. If VN+PIN is dialed together, you don’t need to call from an authenticated number to be connected. PIN is expired at a much faster rate than VN so that risk of unregistered number calling the customer or SP is minimised.
Wrapping it up
Going back to our 3 product challenge statements , did we balance these adequately?
Have we ensured privacy for customers & SPs? Yes, to a large extent. The risk of using VN+PIN will be eliminated soon as Kaodim gets the workers and admins registered on the platform.
Have we eliminated disintermediation? Not completely, but we have created a flow where sharing actual phone numbers is seen as an aberration - as opposed to a norm on other similar platforms. This coupled with a regex to block off & put a ⚠️ on messages from SPs when they send chats with contact information helps further this narrative.
Have we maintained an optimal user and SP experience? To say that user experience is exactly same as calling someone on their personal cell will be an outright lie. Experience does suffer - but a carefully thought out UI/UX manages it to a great extent. This is a compromise we have to strike.
👏 Hope you enjoyed the read! If you did, consider subscribing & sharing.
Another amazing piece! Thanks for sharing, Saurav!