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

To handle this, most operations teams run a version of this process:

1. Each morning, a fulfillment analyst opens a list of flagged orders in CRM and filters them by status.

2. For each record, the analyst checks the account in CRM for handling notes, opens Zoho Inventory to see what the order did, and Zoho Desk to see whether the customer has already complained.

3. The analyst remembers the process and decides the right next step.

4. The analyst navigates and acts in whichever system owns that action (Desk or Inventory).

5. Once that is done, they return to CRM to record it.

6. They send emails if another team needs to be notified.

7. They open the next record and repeat from Step 2.
   

That's working across three systems, every morning.

In this session we'll build a kiosk that runs that queue as one flow, so that the analyst can focus on the decision and leave the legwork to the system.

Assembling context across three systems takes time

Assembling the complete picture takes time. Quantities and shipment status sit in Inventory. Complaints and their priority sit in Desk. Instructions on how the customer wants problems handled sit in CRM. Each system holds one part, and the analyst is the one piecing them together.

Skipping one of them changes the answer. An order that's a week late looks like a warehouse problem until you open the ticket and find the customer has already escalated.

How an AI agent helps the analyst decide

A small catalogue and a handful of accounts make these calls easy to standardize. Growth changes that. More products mean more ways an order can go wrong, and more customers mean more commitments made to them individually. The number of combinations an analyst has to hold in their head grows with the business.

Some of the orders in our queue are easy to decide. Shipped in full with no open ticket usually means release. A quantity mismatch means the warehouse acts before anything else happens. Others are more ambiguous. Example, a duplicate check: a customer asks you to confirm their order isn't a duplicate, while warning you not to delay the real one.

Every record goes through an agent configured on Zia Agent Studio and deployed to Zoho CRM. The agent checks each case and comes up with a recommendation based on the factors we've asked it to consider in its instructions.

The analyst then decides on every record, after considering the recommendation and the reasoning behind it.

How the kiosk works

Here's the kiosk running through a morning's queue.

The batch loads

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

The context arrives

A screen presents the assembled context immediately:

1. CRM: The queue record details like exception type, priority, and internal notes

2. CRM: The account and the handling note

3. Inventory: order status, shipped status, quantities, and dates

4. Desk: ticket subject, status, and priority

The handling note on the account in CRM is important. It carries what this customer has agreed with you, such as whether they accept part shipments or who to contact on their side when something goes wrong. Inventory and Desk hold no equivalent, and it often decides what the analyst does with a recommendation once they have it.

The agent recommends the course to be taken

The agent receives that same context and makes two passes over it.

1. In the 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.

2. In the second, it checks the record against clear-cut patterns first. No sales order found means incomplete data. Flagged for review with a high-priority ticket means escalate. Shipped in full with no ticket means release.

3. Where the specific case is more ambiguous, the signal ratings decide. The agent takes the most severe signal it rated, acts on that, and names it in the reason.

The agent returns a JSON payload with the action and the reason.

The analyst makes the final decision

The next screen shows what the agent returned, alongside a picklist of the five actions defaulted to the agent's answer. One click accepts it.

All five actions stay available on every record. An order with no ticket can still warrant contacting the customer. Telling them about a shortfall early beats shipping short and waiting for the complaint.

The kiosk acts

Once the analyst makes a choice, a Decision component branches on the analyst's selection. Each path runs its own actions automatically. For example, most paths involve updating the queue record with the status and final resolution. Then, a note is added with details about what was chosen and what the agent recommended. Where a path needs another team informed, the kiosk sends that email as part of the same run.

On paths that involve Desk (like Support Escalation), creating, updating, or escalating tickets on Zoho Desk happen via Deluge function. The Inventory Action path works the same way. Where the customer accepts part shipments, the analyst can release the available quantity, and a Deluge function packs it and creates the shipment in Zoho Inventory.

Once the present issue is addressed, the loop moves to the next record. A closing screen appears once all the records have been processed.

Configuration

Behind the scenes, the kiosk was built in this order:

1. Create two Connections, one for Zoho Inventory and one for Zoho Desk.
   
   

2. Create a Source for each, holding the base URL. Paths and parameters belong to the Query built on it.

3. Build the Inventory query. It finds the sales order based on its reference number and returns status, shipped status, and quantities.

4. Build the Desk query. It fetches the ticket by ID.

5. Write a serializer for each query, flattening the response into individual values the 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 agent after that screen.
   
   

9. Add the recommendation screen with the agent's output and the picklist that lets the analyst pick the final course.

10. Add the Decision component, branching on the picklist. For each, add the field updates, note addition, and other actions as required. The Desk and Inventory changes are Deluge functions called from their respective paths.

11. Add the closing screen after the loop, and publish the kiosk to the home page.

The audit trail

1. Each processed record holds its own history: the status, the resolution, and the resolution notes, which records the agent's recommendation as well.
   
   

2. Desk keeps a second copy. Comments written by the kiosk sit on the customer's ticket, where the support team will see them.
   
   

3. Inventory holds a third. A released part shipment creates a package and a shipment order against the sales order, and the queue record carries the shipment number.
   
   

4. Zia Agent Studio's Observability tab holds every agent run, with the input the agent received and the output it returned. A recommendation that looks wrong can be traced back to the exact context behind it.
   
   

Work that crosses systems

As you can see, Kiosk Studio suits work that stretches across systems. Queries bring the data in, functions act on the systems that hold it, and an agent goes wherever judgment is needed to keep the analyst moving.

If you're building multi-system operational workflows with Kiosk Studio in Zoho CRM, share your approach below.

If you are new to Kiosk Studio, refer to our documentation.