FAQ: Faboxi and modern ecommerce customer service

Product and use case

What is Faboxi?

Faboxi is an ecommerce support workspace connecting channel conversations with customer, order, shipment, and AI-draft context in one operator view.

Who is Faboxi for?

Teams that repeatedly handle order, delivery, return, or complaint questions across several channels or commerce systems.

Does Faboxi replace WMS, ERP, or the store platform?

No. Those systems remain the source of order, payment, and fulfilment truth. Faboxi uses their data in the support workflow.

Is Faboxi a CRM?

Faboxi keeps the customer profile and contact history needed for support, but it is not designed to replace a full sales CRM.

Who may not need Faboxi?

A store with one channel, low case volume, and little need for order lookups may still work well with a shared mailbox. Faboxi becomes more valuable as channels, operators, and commerce-context questions grow.

Must the whole team migrate at once?

No. Start with one frequent workflow, a limited operator group, and read-only access. Expand only after reviewing pre-agreed pilot outcomes.

Channels and integrations

Which channels can Faboxi support?

The architecture covers email, web chat, Messenger, WhatsApp, SMS, and voice. Publicly available and planned integrations are labelled on the product page.

Which commerce systems can connect?

The connector model covers WMS and platforms or aggregators such as IdoSell, WooCommerce, Shopify, Shoper, BaseLinker, and PrestaShop. Actual scope depends on the active connector and provider data.

Does Faboxi need store database access?

No. Data flows through versioned APIs and connectors without direct WMS or CMS database access.

What happens when an integration fails?

The operator should see a degraded state next to the affected context. Missing or stale facts must not be presented as current.

How do we distinguish a live integration from roadmap direction?

Check its product-page status and confirm the exact scope during a demo. A provider name in the integration direction does not mean every data field and action is production-ready.

Can Faboxi connect to a custom WMS?

It depends on a stable API, available fields, authentication, and failure handling. Scope, freshness, limits, test environment, and support ownership need review before pricing.

AI and automation

What does AI do in Faboxi?

AI can summarise, classify intent and risk, explain context, and draft a reply from allowed data.

Does AI send without an operator?

Not by default. An operator approves, edits, or rejects the draft. Greater autonomy requires separate policy and strict safety gates.

Can AI invent order status?

It must not. Order status comes from a current, appropriate commerce source. Missing or conflicting data limits the reply.

Can AI cancel or refund an order?

Not without a controlled process requiring preview, policy, permission, idempotency, audit, and connector confirmation.

Do operator edits automatically change the AI?

No. Feedback enters a controlled quality process. Shared-engine changes require evaluations, while store-specific settings remain tenant-scoped.

How do we test AI quality before launch?

Build an anonymised set of common and difficult cases, define correct facts, permitted actions, and handoff reasons, then measure factual errors, acceptance, edits, and rejection.

Implementation and migration

How long does implementation take?

Timing depends on channels, API quality, and the first workflow. Faboxi does not promise one duration without scope; a plan and acceptance criteria should follow discovery of the store scenario.

Who owns configuration work?

Faboxi owns the agreed product and integration scope; the store provides system access, support policies, decision owners, and acceptance scenarios. The rollout plan should state the exact split.

Can conversation history be imported?

Migration depends on the source system and export quality. Formats, attachments, customer matching, statuses, and required history must be confirmed before making a commitment.

What should a pilot include?

Use one frequent workflow, real anonymised cases, least-privilege data access, and metrics for handling time, manual searches, factual errors, and repeat contact.

Implementation, safety, and billing

How does implementation start?

Choose one frequent process, required channels, and data sources. Launch a safe scope and verify real scenarios before expanding.

Can we start read-only?

Yes. It is the preferred way to validate commerce data and operator workflow before enabling order-changing actions.

How is SaaS customer data isolated?

Data, memberships, integrations, secrets, and background jobs are designed with workspace context. Provider secrets remain server-side.

Will we receive GDPR and subprocessor information?

Processing scope, DPA, retention, data location, and subprocessors should be confirmed in the documents for the specific offer. This FAQ does not replace those documents.

Can data be exported or deleted?

Agree export, retention, and deletion scope before rollout for conversations, attachments, profiles, integration data, and audit evidence. Do not infer this from marketing copy alone.

What support and SLA are provided?

Support channels, hours, priority rules, response targets, and integration ownership must be confirmed in the offer or contract; they may depend on plan and product stage.

How are AI Actions billed?

Allowance depends on the plan. AI usage is classified from the work outcome, while displaying order data is not an AI action.

What affects price?

Plan, users, channels, AI volume, and integration scope may affect cost. Binding limits, overages, implementation cost, and cancellation terms belong in the current offer.

Is a trial available?

Confirm pilot or trial availability for the current offer. In either case, agree the scenario, test data, duration, and decision criteria.

How do we start?

See the demo with a specific store scenario, then choose the first process, integrations, and rollout scope.