One sentence, two systems
“Where is my order? Please leave it with reception.” A service agent hears one request. The business sees two operations: retrieve a shipment status and amend a delivery instruction. In this illustrative order-support design, an authenticated customer has already selected the order. The assistant can therefore keep the conversation short without guessing which record to change.
Assisto’s own multilingual language model provides the conversational layer. Natural-language instructions define the service tone, FAQs cover routine policy questions, and configured tools connect the agent to the order system and CRM. The interesting design question is not whether it can reply. It is whether the reply accurately describes what happened in both systems.
Parallel where possible; sequential where necessary
The status lookup and delivery-note update do not depend on each other, so they can run concurrently after the customer and order are resolved. While they run, the assistant can acknowledge the request. This avoids a silent wait without claiming success early.
An address change would be different. It may depend on dispatch status, a policy check, and explicit confirmation. Those dependencies must stay sequential. Tool calling is not permission to run every available operation at once. The integration contract determines which actions are independent and which require a result from an earlier step.
The difficult case: one tool succeeds
Suppose the order API returns “out for delivery,” but the CRM rejects the write. The right response is specific: “Your order is out for delivery. I couldn’t save the reception note; would you like me to connect you with support?” A fluent “all done” would conceal a failed business action.
The proposed integration uses a request identifier for updates so a retry does not create duplicate notes. Authentication remains scoped to the customer’s account, and tool responses distinguish validation errors, unavailable services, and confirmed writes. These are implementation choices for this workflow, not facts the language model should improvise.
What the service team should test
A useful review set includes a customer switching languages mid-conversation, correcting the order reference, changing their mind, and asking for an action outside the agent’s permissions. Each test checks both the transcript and the system record.
The acceptance criterion is concrete: every claimed update has a corresponding successful tool result, and every unresolved request has a clear next step. Voice can be added through Assisto’s speech stack without creating a second set of business rules. The same tools and confirmation logic should govern both channels.