Frequently asked questions

Intelligent commerce is useful as an operating model when it connects reasoning to controlled execution. A model might interpret a customer's unusual request, but business permissions should determine whether any resulting change is allowed. In a practical evaluation, ask to see the original request, records used in the decision, applicable policy, authorized action, and resulting commerce state. This sequence is more informative than an abstract claim that the system is intelligent. Decide which parts of the stack remain authoritative and which decisions require employees. Intelligence does not remove the need for reliable identifiers, valid integrations, or financial limits. A deployment can begin with a single post-purchase workflow and expand after the team understands its exceptions. Treat broader category language as positioning, not a guarantee that every possible commerce operation is supported.

Agentic commerce operations focuses on agents carrying out business tasks, not simply helping a shopper discover products. For an operations team, the question is what happens after intent becomes a proposed change to an order, payment, or subscription. Separate planning from authorization: an agent may suggest a sequence, but each consequential step needs a permitted operation and evidence of the result. Test a request that spans two systems, such as cancelling a subscription after its next order has already been created. The subscription and shipment may require separate decisions. An agent should not report complete success merely because one step succeeded. Ask how the provider represents pending, partially completed, and escalated work. These states determine whether the team can trust the system during real operations rather than only during ideal demonstrations.

Agentic commerce operations focuses on agents carrying out business tasks, not simply helping a shopper discover products. For an operations team, the question is what happens after intent becomes a proposed change to an order, payment, or subscription. Separate planning from authorization: an agent may suggest a sequence, but each consequential step needs a permitted operation and evidence of the result. Test a request that spans two systems, such as cancelling a subscription after its next order has already been created. The subscription and shipment may require separate decisions. An agent should not report complete success merely because one step succeeded. Ask how the provider represents pending, partially completed, and escalated work. These states determine whether the team can trust the system during real operations rather than only during ideal demonstrations.

Start with a task people repeat, not a general instruction to automate the business. Document the trigger, required records, policy decision, permitted action, and evidence that proves completion. A practical example is an eligible address correction before warehouse processing begins. An agent can interpret the request, but the workflow still needs structured validation of the address and a current check of the fulfillment cutoff. Introduce automation in stages: observe representative cases, review proposed actions, and permit execution only within an agreed scope. Include requests that should be denied and situations requiring additional customer information. Assign someone to maintain policies when operations change. The goal is to remove repetitive coordination while preserving clear responsibility for decisions, rather than replacing every existing process with open-ended model instructions that nobody can reliably audit.

For an evaluation, begin with the actual event or request that crosses the protocol boundary. Identify the merchant, order, customer authorization, and records available to downstream operations. Then define what the execution layer may do with those records. A checkout authorization should not be interpreted as unlimited permission to modify unrelated orders or issue later financial actions. Test a rejected request, a duplicate event, and a downstream system that is unavailable. Ask the implementation team to distinguish protocol compatibility from merchant policy, fulfillment coordination, and payment reconciliation. The specification is an external technical reference, not an endorsement of StateSet or a guarantee that a particular deployment has been certified. Verify the proposed flow against current documentation and a representative end-to-end test before making production commitments.

A commerce platform can cover several different responsibilities, so ask which ones the proposed deployment actually includes. Reading an order, recommending a response, issuing a refund, and reconciling inventory are different capabilities with different permissions. Map these capabilities onto the systems your team already uses. For example, the helpdesk might own the conversation while a payment provider owns the refund and a warehouse owns shipment state. The platform should explain how it coordinates those responsibilities without claiming authority over records it cannot change. Request a capability matrix listing supported reads, writes, approvals, and failure handling for the selected workflow. This makes comparisons more useful than counting integrations or model choices. It also identifies which work remains with employees, implementation partners, or existing software after the automation is introduced.

Think of an execution layer as the boundary between a proposed action and an authorized change in a system of record. It should make the requested operation explicit, validate the inputs, enforce permissions, and retain the result. For example, a refund proposal needs an order reference, amount, currency, eligibility decision, and a payment operation that can be verified afterward. The model's explanation is useful context but should not become unrestricted authority. Ask how the layer handles a lost response after a successful write, since retrying blindly can create duplicate work. Also ask what happens when a policy changes between proposal and execution. A useful demonstration shows rejected actions as clearly as successful ones. Evaluate the layer against your required operations, because its presence alone does not establish complete workflow coverage.

Orchestration coordinates dependent work across systems whose states may change at different times. A cancellation could require checking an order, contacting fulfillment, releasing inventory, updating payment records, and notifying the customer. Those steps cannot always be treated as one instantaneous transaction. Decide which steps must happen first and which can safely wait. The design should specify timeouts, retries, recovery, and ownership when one system accepts a change and another rejects it. Ask for a timeline that distinguishes a request being accepted from the requested business outcome being achieved. Include a warehouse outage in the evaluation, then inspect how pending work is resumed. The right orchestration platform reduces coordination overhead without concealing incomplete work. It should make dependencies visible to the people responsible for resolving exceptions and explaining outcomes to customers.

Adapt the automation to a real process in your business rather than forcing the business into a generic demonstration. Bring a sample of recent requests, the relevant policies, a system map, and examples that required manual judgment. Identify the desired outcome and the team responsible for it. Ask the provider to show which steps are supported today, which need configuration or engineering, and which should remain human-led. Test the proposed workflow using representative data and explicit permission boundaries. Include customer communication and recovery from incomplete actions in the evaluation, not just the successful write. Measure the baseline and review results with the people who operate the process. A useful proposal explains fit, limitations, commercial units, and ownership in your context. It should make the next decision clearer without claiming that every workflow or business will achieve the same results.

A successful automated outcome is the result agreed for a specific request, supported by evidence outside the model's response. For an information question, that may be an accurate answer from current records. For a cancellation or refund, it requires the relevant systems to reach the intended state. Define whether downstream acknowledgement, settlement, or physical fulfillment is part of completion or a separately tracked stage. Test partial success and later reversal so reporting and billing do not treat every initial acknowledgement as final. Include the customer's intended scope: changing the wrong subscription is not success merely because an API accepted the update. Record the completion criteria with the workflow and review them with operations and finance. This makes the outcome understandable, independently checkable, and less vulnerable to optimistic reporting based on activity rather than the business result requested.

Integration starts with a business action, then works backward to the data and interfaces needed to perform it. For a permitted refund, the agent needs the correct order and payment references, policy eligibility, a supported financial operation, and a way to verify the result. Authentication alone does not supply all of those pieces. Define event triggers, identifier mapping, input validation, and failure handling for the selected workflow. Test a read-only credential, a revoked permission, and an API response that arrives after a timeout. Keep secrets outside model instructions and use scoped access appropriate to the task. Evaluate the engineering and operational work needed to maintain the connection when providers change. A good integration plan makes assumptions explicit and produces a testable workflow, rather than treating the presence of an API or connector as proof that automation is already complete.

An ERP usually remains authoritative for important business records and processes. Introducing an agent layer does not require replacing that authority, but it does require deciding which records the agent may read or change. Map the proposed workflow to the ERP's supported interfaces, permissions, and approval requirements. A connector listed in a catalog is not proof that your customized transaction or field is supported. Test identifiers, custom fields, posting restrictions, and a write rejected by the ERP. Keep the ERP's business rules visible in the execution design rather than trying to bypass them through another system. Measure reconciliation and recovery effort as part of implementation cost. A useful integration reduces manual coordination around existing processes while preserving the system of record, rather than creating a second unofficial version of financial or operational truth outside it.

Deployment timing depends on more than installing a connector or opening a sandbox. The team needs agreed policies, authorized system access, representative test cases, clear completion criteria, and owners for security and operations. Identify these dependencies before committing to a date. A workflow using existing supported actions may require less integration work than one involving custom ERP fields or a new warehouse process. Separate demonstration readiness from approval to execute consequential actions in production. Plan time to test denials, retries, partial completion, and human handoffs. Review the launch scope explicitly so a typical timeline is not interpreted as a promise for every integration. After release, allow for observation and adjustment before expanding permissions. A useful implementation plan lists milestones and unresolved dependencies, making the schedule inspectable rather than presenting a single optimistic number without its assumptions.

Compare pricing using the same set of business outcomes and the same expected request mix. A conversational resolution, an order change, and a financial action may be different billable units. Ask how attempts, denials, retries, reopened cases, and partially completed workflows are treated. Confirm any implementation scope, enterprise commitment, discount, or revenue-recovery arrangement in the current agreement. The published pricing page is the starting point, not a substitute for a scoped commercial proposal. Build a sample reconciliation showing each billed outcome and its completion evidence. Include the cost of retained human review and integration maintenance when comparing alternatives. Outcome-based pricing can align payment with completed work, but it does not establish savings automatically. The evaluation should make the unit economics understandable and show how finance can verify charges without relying on a dashboard total that cannot be traced back to actual cases.

A BPO alternative can be software, an internal process change, a different service model, or a combination. Start by identifying the work your current provider actually performs: conversation handling, system changes, exception judgment, quality review, and reporting. Determine which tasks are repeatable enough for controlled automation and which require human expertise. Test representative cases before changing staffing or service coverage. Include difficult requests and peak periods rather than only common low-risk tickets. Compare total cost and accountability, including the people who will supervise the new workflow and resolve failures. An automation deployment may complement an existing BPO rather than replace it entirely. The meaningful outcome is a reliable service operation with less unnecessary coordination, not simply fewer contracted seats or a lower apparent ticket cost that excludes the work transferred back to your own team.

A helpdesk copilot commonly assists an employee by retrieving context, drafting replies, or recommending actions, but actual capabilities vary by product and configuration. Compare it with an execution workflow using the same support cases. Identify whether a person still needs to open another system, validate policy, perform the change, or confirm the result. That remaining work determines the operational difference. Test an incorrect recommendation and inspect whether the human has enough context to catch it. For direct execution, test unauthorized actions and partial failures. A team may benefit from both approaches: assistance for complex judgment and controlled automation for repeatable requests. Avoid treating the categories as mutually exclusive or assuming every copilot is read-only. Evaluate the supported implementation, the team's review capacity, and the evidence that customer issues are resolved rather than merely answered more quickly.

An ecommerce agent combines interpretation with access to a limited set of business tools. The tool set determines whether the agent can only answer questions or can also perform actions such as updating an address or initiating an eligible return. Before connecting an agent, list the exact operations required and the records it may read. Use representative requests that differ in ambiguity, customer identity, and financial impact. A request like 'stop my next delivery' may mean pausing a subscription, cancelling an existing order, or both; the agent should clarify rather than guess when the distinction matters. Review the evidence it records and the information it passes to a human. Model selection matters, but access design, action validation, and operational ownership are equally important parts of deciding whether the agent is appropriate.

Preventing incorrect changes starts by limiting what the agent can propose and what the execution layer will accept. Define supported operations, required fields, ownership checks, amount limits, and approval gates. Validate those conditions using current business records rather than trusting the model's confidence or explanation. Test malicious instructions embedded in customer text, an attempt to access another account, and a request that exceeds authority. The system should reject or escalate these cases without performing the prohibited action. Keep read access and write access separate where practical. Review actual outcomes and near misses to improve controls, but do not assume that logging alone prevents errors. No control design makes every workflow infallible. A credible deployment demonstrates its stop conditions, gives operators a way to pause execution, and assigns responsibility for investigating and correcting mistakes when they occur.

Connecting an ERP, OMS, WMS, and 3PL creates a network of responsibilities rather than one interchangeable database. Build a map of which system owns each field and event involved in the selected workflow. Establish identifiers that connect the same order, shipment, item, and payment across those boundaries. Test delayed updates, rejected writes, and a partner system that is temporarily unavailable. Decide how the workflow recovers when one step succeeds and another cannot proceed. A single connector count does not describe this operational coverage. Ask for an integration matrix with supported operations, permissions, dependencies, and recovery owners. Measure the time required to reconcile partial completion and the manual work left at each boundary. The objective is reliable coordination across the existing stack, not an unsupported assumption that every connected system can be changed consistently at the same instant.

Policy-bounded agents operate within decisions the business has explicitly authorized. A policy might permit a replacement for a verified damaged item under a cost threshold while requiring review for repeat claims. The agent can interpret the request, but the policy should determine the permitted action using structured facts. Specify who owns policy changes and how those changes are reviewed. Test an ambiguous request, conflicting records, and a request that crosses a threshold during processing. Keep the applied policy version with the action record so a later reviewer can understand the decision. Avoid describing policy-bounded behavior as unrestricted autonomy. It is useful precisely because the scope is limited. Measure denied actions, approvals, and successful permitted outcomes together, since a system that safely refuses an invalid request may be behaving correctly even though it did not complete the customer's requested change.

Uncertainty should produce a defined behavior rather than an improvised action. The agent may need more customer information, a fresh system lookup, a policy clarification, or human review. Distinguish uncertainty about intent from uncertainty about permission or execution state. If a customer says 'stop everything,' clarifying which subscription and order they mean is different from deciding whether a known order can still be cancelled. Test contradictory messages, missing identifiers, and unavailable downstream records. The handoff should explain what is known, what was attempted, and what remains undecided. Do not reward the system for confidently completing a request when the required facts are absent. Measure the quality and frequency of escalations alongside completed outcomes. A useful automation can safely stop, preserve context, and resume after clarification without repeating actions or forcing a human to reconstruct the entire case.