Sometimes, It’s The Small (Product) Decisions…

Prior to launching Planit, one of the decisions we had to go over several times was how potential customers were going to reach out to vendors. At the time, after considering several options, we narrowed down our choices to these two:

• Option A (Call-A-Vendor system): Let clients get the phone numbers of vendors without signing up. This is the usual classifieds system.
• Option B (On-site messaging): Set up a messaging system where both parties can initiate conversations but they would still be able to take transactions off the site. The important component of this is that the conversations start on the platform.

At launch, we decided to go with Option B. Here’s what it looked like:

Video recorded 2 months after Planit’s launch. (Cropped video)

However, what we noticed was that usage was low especially when comparing the number of people who triggered the Request Quote action and those who actually went through with sending a request to a vendor.

Also, vendors weren’t replying to potential customers fast enough despite the multiple notifications we sent them(SMS and email).

Back To Option A

The first option (clients being able to call vendors directly) is one I was against for two reasons. I felt it would:

• make it impossible to get accurate data (on platform usage) due to factors such as call connectivity issues, malicious site visitors, etc.
• make us become a classifieds site. This especially worried me as it was/is at opposites with what we’re building Planit to become.

Despite these fears, the low usage on the Request Quote system made us switch to a call-a-vendor system. The one twist was that people had to sign up to view contacts. It wasn’t long before we had people (who were mostly trying to build platforms similar to Planit)abusing the system by copying the numbers of up to 50 vendors at a time.

And Back (Again) To Option B

Mostly due to the platform abuse, we decided we would (and not too long after, actually did) switch back to the Request Quote option. This continued until…

Near-Death

From December 2018 — April 2019, we were almost non-operational. While the site was up and activities (e.g. vendor signup, quotes requested, etc.) were still ongoing, we lacked the capital to fully pay for operations, marketing, and platform development.

In May 2019, we were finally able to restart operations and one of the major changes we made was to temporarily revert back to Option A while trying to figure out ways of driving up platform usage.

Enter Option C

While exploring options, we outlined what our problems were with both Options A and B

• Letting users call vendors directly wouldn’t let us measure analytics properly (e.g. calls that didn’t go through, vendors not picking, etc.). A solution to this would have been to set up call-routing but this is expensive and difficult to implement in Nigeria
• The on-site messaging system was too hectic for users and they (understandably) didn’t want to have to sign up before getting small chops or a photoshoot for their wedding.

So, any solution we were going to come up with had to:

• Provide accurate analytics on how many vendor-client connects were being made
• Provide an easy user experience for both vendors and clients
• Give us visibility into the users making the requests so we’ll be able to follow up to see if the vendor met their needs (among other reasons)

After pondering through this for quite a while, we thought, why not combine the best elements of both? We came up with the dual SMS delivery system (and we looked up and saw another company in India was already using something similar to it).

How Dual SMS Delivery Works On Planit

When a potential client searches for event service providers on Planit (e.g. caterers) and chooses to contact one, they’ll provide their name as well as phone number and we’ll instantly deliver the vendor’s contact via SMS.

We also automatically deliver their contact to the vendor via SMS so that:

• The vendor can follow up with users who requested their contacts
• The potential client will have the vendor’s number on their phone if, for example, an initial attempt at connecting with the vendor fails
• We have accurate analytics as to platform usage (re:client-vendor contacts).
• We are able to follow up with the client to see if they’ve been able to get the service from the vendor.

The SMS the vendor receives VS the SMS the client receives

Some issues we faced were:

1. Failed SMS delivery: We have resolved this by using the long code SMS product by Sling SMS as our main SMS delivery platform as it guarantees delivery to all numbers (including DND numbers).

2. Platform abuse: We’ve found a way around this by limiting the number of vendors that can be contacted by users and we’re alerted when this limit is hit.

While I’m 99% sure that this isn’t always the system we’ll use, for now, we’ve solved some of the major issues we had around clients contacting vendors. We’re making optimizations that are focusing on, among (several) other things, personalization for clients and we’ll need to phase out the current system.

When I get over my laziness, I’d make a sequel to this post that shows how we refined our (proposed) monetization models with each change we made to this tiny feature.

Featured photo by Pablo García Saldaña on Unsplash