After the Southeast Asian beauty products e-commerce platform privatized and deployed its AI customer service, the conversion rate of inquiries in Q2 increased by 27%.

Last month, I helped a team in Singapore that specializes in direct-to-consumer (DTC) beauty products with troubleshooting. They are a small team of five people who were previously using a third-party SaaS-based AI customer service platform. During major promotional events, it took more than 30 seconds for responses to customer inquiries about skin type compatibility. On the worst day of the promotion, the system completely crashed for 40 minutes, resulting in the loss of nearly one-fifth of their orders.

First, let's understand what private deployment really is.

Don’t get confused by the jargon; it simply means that you install all the software, models, and data you need on your own server or in your dedicated cloud instance, without having to share the resources of a service provider with other users. For the customer service large model we deployed this time, we allocated a dedicated computing quota that can handle up to 1200 concurrent consultations at the same time, so you don’t have to compete with hundreds of businesses for the same shared computing resources.

Three tangible benefits in the form of real money

We have run the data for 30 days since our launch, and here are the three most noticeable changes:

• Firstly, the response speed has increased by a factor of 6; 90% of inquiries receive a response within 1 second.The inquiry conversion rate has increased by 27% directly.The problem of many users closing the page before waiting for a reply has basically disappeared.
• Secondly, all the data remains in our own hands; information such as users' skin types, allergy histories, and preferences is not stored in the service provider's public database. This prevents competitors from using the service provider's data to recreate user profiles, and it also complies fully with the PDPA data protection regulations in Southeast Asia.
• Finally, the cost has even decreased. Previously, the fees were charged based on the number of consultations, with the service fee for the month of a major promotion soaring to three times the usual amount. Now, by opting for an annual subscription for the cloud server plus model licensing, we can save approximately four months' worth of SaaS fees in a year.

Don't rush to get in the car; first, see if you can avoid these common mistakes.

We encountered a couple of issues during the deployment process, neither too big nor too small. If you want to try it out, you can avoid these problems in advance:

The first point is that initial adaptation takes time. The customer service scripts from the previous SaaS system couldn't be used directly, so it took a week to fine-tune the user consultation data from the past two years to achieve a better response accuracy than the previous SaaS system. It's not something that can be implemented with just clicking a button.

The second point is to have someone maintain it regularly on a personal basis, without the need to hire dedicated operations and maintenance staff. Their backend engineers only need to spend an hour a week checking the monitoring and updating the script library. If the team doesn't even have anyone who understands servers, problems are more likely to occur.

Who should use it? And who really doesn’t need to touch it at all?

Just draw the boundaries for you and don’t follow the trend:

What you need depends on one of the following scenarios: either you have extremely high requirements for data security, such as in cross-border payments or medical consultations; or you experience significant traffic fluctuations during promotional periods, especially if you run an independent website or engage in cross-border e-commerce, where the public SaaS solutions become overwhelmed and experience throttling or even collapse; or your region has strict compliance requirements regarding the export of user data. If any of these apply to you, then you should consider using this solution.

What shouldn't be used: The team only has two or three people, and none of them understand technology. The business volume is stable, and using SaaS works just fine without any problems. Don't waste money on something just because it's supposedly “technologically advanced.”

Practical tips for first-time users

If you meet the above adaptation criteria, don't make a complete switch from the old system to the new one all at once on your first attempt:

First, direct 20% of the traffic to the new system for two weeks to test the response speed, accuracy of responses, and whether the costs truly meet your expectations. Only after confirming there are no issues should you switch the entire traffic to the new system. There's no need to buy the most expensive server from the start; just allocate resources that are 1.5 times your usual peak traffic volume. You can scale up later if needed, and you won't waste a lot of money.

Several questions you're likely to ask

“Can a small team handle it too?” The team we helped only had one backend developer, but they worked closely with us and completed the deployment in just 3 days. The barriers to entry aren’t as high as you might think.

“Will it be much more troublesome than SaaS?” After the initial debugging, the subsequent maintenance workload can be basically ignored. We have been using it for two months; aside from updating the script library once, we haven’t encountered any issues.

"Is data security really better with SaaS?" As long as the service provider you use is serious about providing private solutions, your data will never leave your servers, which is much safer than having it stored in a pool shared with other users.