Some orders get flagged during fulfilment. One is short by six units with nothing from the warehouse explaining why. Another shipped in full three days ago but still reads as pending, because the carrier never posted a scan. A third has a customer who has already written in twice asking where their delivery is.

The problem

Most operations teams run some version of the same manual process every morning: a fulfilment analyst opens a list of flagged orders in CRM and filters by status, then for each one checks the account in CRM for handling notes, opens Zoho Inventory to see what actually happened to the order, and opens Zoho Desk to see whether the customer has already complained. The analyst then decides the right next step from memory, acts in whichever system owns that action, returns to CRM to record it, sends an email if another team needs to be told, and moves on to the next record. That's three systems, worked by hand, every single morning.

Why assembling the context takes so long

Quantities and shipment status sit in Inventory. Complaints and their priority sit in Desk. Instructions on how a specific customer wants problems handled sit in CRM. Each system only holds one piece of the picture, and the analyst is left to assemble it. Skipping any one of them changes the answer: an order that's a week late looks like a warehouse problem until you open the ticket and discover the customer has already escalated.

How an AI agent helps the analyst decide

With a small catalogue and a handful of accounts, these calls are easy to standardise. Growth changes that: more products create more ways an order can go wrong, and more customers mean more individual commitments to track. The number of combinations an analyst has to hold in their head grows with the business. Some cases in the queue are genuinely easy, shipped in full with no open ticket usually means release, and a quantity mismatch means the warehouse needs to act first. Others are more ambiguous, such as a customer asking you to confirm their order isn't a duplicate while warning you not to delay the real one. Every record passes through an agent built in Zia Agent Studio and deployed to Zoho CRM, which reviews the case and returns a recommendation based on the factors it's been instructed to weigh. The analyst still makes the final call on every record, after seeing the recommendation and the reasoning behind it.

How the kiosk works

The batch loads

The kiosk is published to the CRM home page, so the analyst opens it to start the morning's queue. The first screen explains what the kiosk will do, a GetRecords component fetches every queue record with a status of Open, and a Loop iterates over them one at a time.

The context arrives

A screen presents the assembled context immediately: the CRM queue record's exception type, priority, and internal notes; the account and its handling note; the order status, shipped status, quantities, and dates from Inventory; and the ticket subject, status, and priority from Desk. The handling note on the CRM account matters more than it might seem, since it captures what's actually been agreed with that specific customer, such as whether they accept part shipments or who to contact on their side when something goes wrong, information Inventory and Desk simply don't hold.

The agent recommends a course of action

The agent receives that same context and makes two passes over it. First, it rates a set of named signals, how far stock is blocking the order, how much pressure the customer is applying, whether the data is complete, and so on. Second, it checks the record against clear-cut patterns: no sales order found means incomplete data, a review flag with a high-priority ticket means escalate, shipped in full with no ticket means release. Where a case doesn't match a clear pattern, the signal ratings decide instead, with the agent acting on the most severe signal it identified and naming that signal in its reason. The agent returns a JSON payload containing the recommended action and the reason behind it.

The analyst makes the final decision

The next screen shows the agent's output alongside a picklist of five possible actions, defaulted to the agent's answer, so one click accepts the recommendation. All five actions stay available on every record regardless of what the agent suggested, since even an order with no open ticket can still warrant proactively contacting the customer, telling them about a shortfall early beats shipping short and waiting for the complaint to arrive.

The kiosk acts

Once the analyst chooses, a Decision component branches on that selection, and each path runs its own actions automatically. Most paths update the queue record with the status and final resolution, then add a note recording both what was chosen and what the agent had recommended. Where a path needs another team informed, the kiosk sends that email as part of the same run. Paths that touch Desk, such as Support Escalation, create, update, or escalate tickets via a Deluge function, and the Inventory Action path works the same way: where a customer accepts part shipments, the analyst releases the available quantity, and a Deluge function packs it and creates the shipment in Zoho Inventory. Once that record is handled, the loop moves to the next one, and a closing screen appears once every record in the queue has been processed.

How it's configured

1. Create two Connections, one for Zoho Inventory and one for Zoho Desk.
2. Create a Source for each, holding the base URL, with paths and parameters left to the Query built on top of it.
3. Build the Inventory query, which finds the sales order by its reference number and returns status, shipped status, and quantities.
4. Build the Desk query, which fetches the relevant ticket by ID.
5. Write a serializer for each query to flatten the response into individual values that later screens and the agent can read.
6. In Kiosk Studio, add the first screen, the GetRecords component filtered to open records, and the Loop.
7. Inside the loop, add the Accounts GetRecords element, then the context screen with both queries attached.
8. Add the Zia Agent component after that screen.
9. Add the recommendation screen, showing the agent's output alongside the picklist that lets the analyst pick the final course of action.
10. Add the Decision component, branching on that picklist, with field updates, note additions, and other actions on each path as needed. The Desk and Inventory changes run as Deluge functions called from their respective paths.
11. Add the closing screen after the loop, then publish the kiosk to the home page.

The audit trail

Every processed record is documented in four places. The queue record itself holds its own history, the status, the resolution, and resolution notes that include the agent's original recommendation. Desk keeps a second copy, since comments written by the kiosk sit directly on the customer's ticket where the support team will see them. Inventory holds a third: a released part shipment creates a package and a shipment order against the sales order, and the queue record carries that shipment number. Finally, Zia Agent Studio's Observability tab holds every agent run, including the exact input it received and the output it returned, so a recommendation that looks wrong can always be traced back to the context behind it.

Work that crosses systems

This session shows Kiosk Studio doing what it's particularly suited for: work that stretches across systems. Queries bring the data in from wherever it actually lives, functions act on the system that owns each action, and an agent steps in wherever judgement is genuinely needed, keeping the analyst moving through the queue rather than switching tabs.