Implementing Ordana — Common Questions About Setup, Security, and Configuration

Most Ordana deployments go live within two to six weeks for an initial single-channel configuration — phone ordering, for example. The timeline depends primarily on three variables: ERP complexity and API access, product catalog size and data quality, and the number of channels being configured at launch.

Distributors who start with one channel and expand once that channel is stable typically find the initial deployment moves quickly. The work that takes the most time is usually ERP integration configuration and catalog preparation — not AI training, which happens continuously rather than requiring a lengthy upfront process.

The three core inputs for an Ordana implementation are the product catalog, customer account data, and ERP access credentials. The product catalog provides the item master data — SKUs, descriptions, pack sizes, units of measure — that Ordana uses to match what customers order to the correct products. Customer account data provides account numbers, contact information, pricing tiers, and ordering preferences. ERP access enables the integration for both reading this data in real time and writing completed orders back into the system.

Most of this data already exists in the ERP and can be exported or accessed via API. The implementation process does not typically require building new data structures — it connects to what already exists. The main preparation work is ensuring that the product catalog data is accurate and complete, since Ordana’s ability to correctly identify what customers are ordering depends directly on the quality of the catalog it is matching against.

No. This is one of the most important design principles behind Ordana. Customers order the same way they have always ordered: by phone, by email, by text. The AI processes those orders automatically on the distributor’s side. From the customer’s perspective, nothing changes — they call the same number, email the same address, and text the same contact. The only difference is that orders are processed faster and more consistently.

This no-change-for-the-customer design is intentional. Forcing customers to adopt a new interface or download an application in exchange for faster processing is a friction point that limits adoption and can damage relationships. Ordana is specifically designed to capture the benefits of automation without asking customers to do anything differently.

Not significantly. The order desk team’s primary interaction with Ordana is through the exception queue — orders or items that the AI flagged for human review — and the management dashboard that shows order volume, automation rates, and exception patterns. These interfaces are designed to be intuitive rather than requiring extensive training.

The ERP remains the system of record and the primary tool for the order desk team. Ordana operates alongside it, feeding completed orders in, rather than replacing the ERP interface that the team already knows. The training investment for the order desk is typically a few hours of familiarization with the exception handling workflow, not a weeks-long system migration.

Ordana is trained on the product catalog during implementation using the distributor’s existing item master data. This initial training covers the formal product names, SKUs, pack sizes, and units of measure from the ERP. It is supplemented during the configuration process with the informal names, shorthand, and brand references that the distributor’s specific customers actually use when ordering — which often differ meaningfully from the formal catalog entries.

After go-live, Ordana continues to learn from actual ordering interactions. When a customer uses a product description that is new or unusual, the way it is resolved — either automatically or by a human reviewer — becomes part of the system’s knowledge for that customer and product going forward. The system becomes more accurate over time as it accumulates more ordering history from the distributor’s specific customer base.

Customer data in Ordana — account information, order history, contact details, pricing — is protected through encryption at rest and in transit, access controls that limit data visibility to authorized users and integrations, and security practices consistent with enterprise software standards.

The data that Ordana uses to process orders — product catalog, customer accounts, pricing — is read from the distributor’s ERP and retained within Ordana’s system only as needed for order processing and system training. Ordana does not sell or share customer data with third parties. Data handling practices and security specifications are covered in detail in the Ordana data processing agreement, which is part of the standard commercial relationship.

When Ordana cannot confidently resolve an order item or element, it flags it for human review rather than making an assumption and potentially entering incorrect information. The escalation is specific: it identifies exactly which part of the order is uncertain and presents it to the appropriate person with the context they need to resolve it quickly.

For phone orders, this might mean completing the portions of the order that are clear and flagging a single ambiguous product for a callback. For email orders, it might mean sending a brief reply asking for clarification on one item while processing the rest of the order. The goal is always to minimize the work a human needs to do while ensuring that no order is entered incorrectly because the system guessed rather than confirmed.

Yes. Ordana supports a configurable review workflow that allows distributors to require human approval for certain order types before they are confirmed in the ERP. This can be applied broadly — all orders require review — or selectively, based on criteria like order value above a threshold, orders from new customers, orders with flagged items, or orders in specific product categories.

Most distributors find that requiring review for all orders defeats the efficiency purpose of automation, while requiring no review at all creates more risk than they are comfortable with initially. A common approach is to start with a selective review requirement for a short period after go-live, confirm that the system is performing accurately, and then reduce the review requirement as confidence in the automation quality builds.