Technical project case study
Memaila Plus was designed as a modern shared-inbox layer that combines email, order and parcel context while keeping credentials server-side and external actions under human control.
01The operational problem
Customer-service agents often move between a shared inbox, Sellercloud, marketplace portals, warehouse screens and carrier tracking sites to answer one message. The fragmentation increases handling time and creates opportunities for an agent to use the wrong order, stale tracking information or an incomplete thread.
Adding AI without an integration boundary would create a second risk: an email or attachment is untrusted input, and a language model must not be allowed to turn message content into unrestricted provider actions.
02What was built
ECom Clarity designed and prototyped a responsive shared-inbox client around a provider-neutral email contract and a server-side Memaila adapter. Threads remain grounded in live Memaila data; there is no fabricated demonstration inbox. The application resolves recognised order references through Sellercloud and exposes marketplace or carrier tracking as separate, clearly labelled context.
The AI copilot can summarise a thread, identify intent and priority, extract order references and prepare a reply. Sending remains an explicit confirmation step. This preserves human judgement while reducing the repetitive reading and lookup work around the decision.
03Technical design
- Server-only Memaila adapter normalises the documented legacy API and richer private API-v2 behaviour behind one internal contract.
- Sellercloud is the primary order source; Amazon and eBay tracking are returned separately to avoid contradictory merged records.
- Shopify supplies an exact-SKU website price only after a matching order is found.
- Carrier integrations include cached parcel status and scan history, with official tracking links as a safe fallback.
- Polling, checkpoints and reconciliation are used because a dependable supported webhook was not confirmed.
- AI tools operate on narrow application functions rather than receiving provider credentials.
04Controls, failure handling and operational safety
- Passwords and one-time codes are not stored by the browser client.
- Every provider route requires an authenticated Memaila session.
- Order and tracking integrations are read-only; cancellation links return the operator to the authoritative system.
- Send, reply and forward require explicit user confirmation.
- Email bodies and attachments are treated as untrusted input and cannot alter tool permissions.
- Private API-v2 production use remains conditional on written vendor support and contract testing.
05Why the design matters
The project shows a measured route to customer-service AI. The first objective is not autonomous email; it is better context, fewer lookups and more consistent drafts with visible evidence.
Separating the provider adapter from the user interface also protects future options. If Memaila cannot support a required contract, another provider can be added without rewriting the email domain and AI policy layers.
06What this project demonstrates
- Email, ERP, marketplace, warehouse and carrier integration design.
- Human-in-the-loop AI applied to a real operational workflow.
- Provider-neutral architecture, permission checks and audit requirements.
- Willingness to document vendor limitations instead of presenting an unsupported feature as production-ready.
07Practical lessons for similar integrations
AI should recommend through the same permissioned application layer used by people. The model is not the security boundary and must never hold the keys to external systems.
A useful shared inbox does not need to merge every provider response into one ambiguous record. Keeping Sellercloud, marketplace and carrier facts separately labelled can be safer and easier for an operator to verify.