Which system should I start with?

Start where it hurts most: no traffic → social media ops; no storefront of your own → the site system; street sales running on legs and memory → field lead-gen; messages piling up unanswered → AI support; old customers going quiet → private-domain ops. Not sure? Book a demo — one conversation makes it clear.

Can I buy just one system?

Yes. Start with the single system that fixes your most painful stage, then add along the growth chain as you go.

Is it a subscription or a one-time purchase?

Most systems run as a monthly subscription; some, like the storefront, start as a project. We'll scope the right model for your case during the demo.

Are the listed prices final quotes?

They're starting anchors, not final totals. Category, market and what you already have in place differ for every business; the exact scope and quote come after the demo.

What does working together look like?

Three steps: book a demo and pin down your most painful stage; run a small pilot on that one stage and watch real results; once it works, sign and go live.

How soon can we go live?

It depends on the system and what you already have in place. We'll give you a timeline for your specific situation at the demo — no blanket promises.

What does "proven on our own brands first" actually mean?

Our own brands run these five systems on real business every day. What you see in a demo isn't a product page — it's a live system and the real content and conversations it produces. If it doesn't work, we don't sell it.

Is the chat bubble in the corner one of your systems?

Yes. The reception you're getting right now is System No. 4 — the AI Customer Service System — running for real. Buy it, and this is exactly what your customers get.

Do you guarantee results?

We don't promise blanket numbers — categories and starting points differ too much, and anyone guaranteeing you a uniform figure deserves suspicion. Our way: see the live systems at the demo, judge the pilot on your own data, then decide.

I'm not technical — can I run this?

Yes. We handle deployment and integration; you and your team make the business calls. During handover we onboard your people — what you need to know is your customers, not code.

We already have a team, or use other tools. Does that clash?

No. The systems enter one stage at a time, so one can take over a single stage and run side-by-side with what you do today. Same team — much bigger throughput.

Why systems instead of hiring more people?

Hiring adds hands; systems add scale. Publishing, reception and follow-up run around the clock, while people handle only the calls that need judgment. The usual pattern is your existing team running the systems for bigger output — not either-or.

Do you offer done-for-you management?

No. We sell systems, not outsourced labor — the system goes to you or your team and lets the same people produce far more. If you need managed services, that's not our business.

Which languages and markets do you support?

Traditional Chinese, English and Vietnamese out of the box, with multilingual reception and content, so one setup serves domestic and overseas customers at once. We'll confirm coverage for your target market at the demo.

Which channels and platforms can you plug into?

The customer service system handles website live chat, WhatsApp, Messenger, Instagram, LINE and Zalo in one place; the social media system turns one asset into native posts for up to nine platforms. We'll map it to your channel mix at the demo.

Where is my data stored?

Your data is encrypted and stays yours; we'll walk you through exactly where it lives and who can access it when we onboard you.

What happens after I submit the form?

Your details get briefed to a teammate so you never have to repeat yourself; we'll reach you through the contact you left to set a demo time.

What actually happens to a customer list when a platform deprecates a messaging feature?

The contacts themselves don't disappear, but the mechanism the business used to reach them does. Message Tags, for example, now return error code 100 instead of sending, according to Meta's changelog — so a flow built on them fails silently rather than throwing a visible error.

Why did Vietnam block Telegram, and what does that have to do with customer lists?

Vietnam's telecom regulator ordered internet providers to block Telegram on 2025-05-21. Any business running customer or prospect conversations inside a Telegram group, with no independent record of who was in it, lost that channel overnight without warning.

How do I know if my flow is relying on a deprecated tag right now?

Check for silent failures first — a deprecated tag typically returns an error code instead of sending, rather than crashing visibly. Cross-reference every channel-dependent flow against that platform's current changelog rather than documentation saved months ago.

What's the difference between a customer list and an owned audience record?

A list that only exists as a platform's send permission — a tag, a group membership, an app that hasn't been blocked — disappears the moment that permission changes. An owned record stores the contact's identity and consent independently, with more than one channel able to reach them.

When a Platform Changes Its Rules, What Happens to Your Customer List?

Three separate rule changes, the same underlying assumption breaking

According to Meta's own changelog, Message Tags — the mechanism that let businesses send order confirmations, account updates and event reminders outside the normal 24-hour messaging window — were deprecated as of 2026-04-27. Tags including CONFIRMED_EVENT_UPDATE, ACCOUNT_UPDATE and POST_PURCHASE_UPDATE now return error code 100 instead of sending. Nothing about the business's list changed that day. The permission to reach it on those terms did.

The same changelog shows Recurring Notifications replaced by Marketing Messages starting 2026-01-07 in most markets, with a short list of regional exceptions. And outside Meta's ecosystem entirely, Vietnam's telecom regulator ordered internet providers to block Telegram on 2025-05-21 — cutting off, overnight, any business running its prospect or customer conversations inside a Telegram group with no other record of who was actually in it.

Each of the three followed the same shape: a platform announced the change in a place businesses were expected to already be watching, gave existing integrations no grace period beyond whatever the changelog itself specified, and left it to each business to notice the failure on its own — usually because a customer mentioned a confirmation or reminder that never arrived.

What actually failed was the definition of 'list,' not the platform

In all three cases, the list itself — the people, the phone numbers, the order history — never disappeared. What disappeared was the mechanism that let a business reach it on the old terms. A Message-Tag-based confirmation flow doesn't throw a visible error when it breaks; it just returns an error code and the message quietly never arrives. A Telegram group blocked at the network level doesn't warn the group admin first — members simply can't connect anymore.

That distinction matters because it changes what 'backing up your list' should mean. Exporting a spreadsheet of names once a quarter doesn't help if the thing that broke was the sending mechanism, not the underlying data. The record has to include a working way to reach each contact that isn't solely dependent on one platform's current terms.

This also isn't a problem specific to one platform or one country. Any messaging channel — a chat app, a marketplace inbox, an ad platform's retargeting audience — can redraw its own terms of access on its own schedule. The businesses that get caught out are consistently the ones that never separated the audience itself from the current permission to reach it.

The migration order that turns a platform permission into an owned record

The fix isn't picking one permanent channel and hoping it never changes — every channel eventually does. It's making sure the contact's identity and consent live in a record the business holds, with more than one way back to that person if any single channel's rules shift.

In practice that means capturing identity — a phone number, a Zalo or WhatsApp ID, an email — at the moment of every conversion, regardless of which channel the conversation started on. It means mirroring anything transactional to a channel the business's own system controls, rather than depending entirely on one platform-issued tag. And it means treating every channel's terms as an interface that can change, with a documented fallback for each flow that depends on it.

Capture identity and consent at every conversion point, not just inside one platform's inbox
Mirror transactional messages to a channel your own system controls, not only a platform's tag
Review each critical flow against its platform's current changelog on a schedule, not after it breaks

A rule change is a Tuesday-afternoon fix for a list that's already owned

For a business whose contact records live in a system it controls, the Message Tags deprecation is a configuration change: swap the dependency, confirm the fallback still fires, move on. For a business whose 'list' only ever existed as a send permission, it's an unplanned outage that looks sudden from the inside — even though the changelog entry was public months before anyone outside Meta noticed.

The cost of skipping this work stays invisible until it's tested. A silently failing flow can run for weeks without tripping any dashboard alert, because nothing crashes — the messages just stop being sent. By the time a business notices, the gap in outreach has usually already cost more than the migration work would have.

The three events above won't be the last ones. The businesses that come out fine on the next one are the ones that already treat the platform as a channel to reach an owned record through, not as the record itself.