Table · reads order

Orders

Purchases and fulfillment.

Rows and columns, sortable and filterable.

Build an agent that makes this All modules

One to pack today, one waiting on payment. Sorting by state is how the morning starts.

OrderCustomerItemsTotalState

#1841L. Kowalski2€82Packed, awaiting collection

#1842Café Bellevue12€168To pack

#1843M. Dubois1€180Shipped, FR3391

#1844Atelier Nord4€56Payment pending

What it does

Behaviours, not fields. Choosing between two modules is choosing between these.

The fulfilment state is the working column. Sorting by it is how the morning starts, which a list of what was sold cannot support.

Payment pending is a state rather than an absence, so an unpaid order is visible instead of quietly sitting in the queue.

Recording an order decrements Inventory where it exists, so the two never need reconciling.

Answers "where is my order" from the row, and hands off to Deliveries once there is a tracking reference.

How it works

1
An order is recorded from a conversation, a form or a shop.
2
The state drives the day — sorting by it is how packing starts.
3
Recording an order decrements Inventory where it exists.
4
A tracking reference moves it to Deliveries without re-entering anything.

Best for

Comparing many records across many fields.

Not the right choice for

A phone. A table is the first thing that stops working narrow.

What a row holds

Every field, and what the agent listens for to fill it — which is the difference between a page you type into and one that fills itself.

Field	Type	Filled from
Orderrequired	text	The order number, generated if not given.
Customerrequired	text	Who bought, matched against Contacts or Companies.
Itemsrequired	text	What was bought and how many, as the customer described it.
Totalrequired	money	What the order comes to, summed from the catalogue or stated outright.
Staterequired	text	Where fulfilment has got to. The working column, and how the morning is sorted.

What it does not do

A module chosen for something it cannot do costs more than one that was never offered.

No payment processing. Payment state is recorded, not taken.
No partial fulfilment — an order half-shipped needs splitting.
No returns or refunds workflow.
Item detail is text, so nothing reconciles line items against stock automatically.

Before it works

What you have to provide, if anything.

Nothing.
Pair with Inventory and Deliveries, which are the two ends this sits between.

In practice

A maker shipping two or three orders a day, mostly agreed in messages.

“Bellevue want twelve of the 250g Guji, invoice them as usual.”

What was said to the agent

What the agent built

An order at 168 euros against the café, state To pack, payment marked invoiced rather than pending — the terms were already known from Companies.

What changed

The packing list became a filter rather than a memory. Two orders that had been unpaid for three weeks surfaced the first time it was sorted by state.

Better with

These do a different job on the same data. An agent can have all of them.

InventoryLive

Stock runs out, reordering takes time, and selling something you do not have is a real cost.

DeliveriesLive

Goods travel to customers and "where is my order" is a question the agent should answer without a person.

InvoicesLive

The agent bills clients or is billed by suppliers, and someone needs to see what is unpaid without opening the accounting tool.

Who uses this page

Caterer

Quotes the obvious, captures dietary requirements, and never loses a headcount.

Online shop

Answers sizing, stock and shipping — the three questions that lose a sale.

Artisan or maker

Answers commission questions and captures the brief, while you stay at the bench.

Florist or bakery

Takes custom orders properly — date, size, colours, message — without a queue forming.

Questions

What data does the Orders page use?

It reads order records the agent has collected. Purchases and fulfillment. Nothing has to be imported first — the page appears once there is something to show.

Do I have to build or configure it?

No. You describe what you need in a sentence and the agent chooses the view and fills it. Custom pages exist for the cases no built-in view covers, and those are reviewed before they go live.

When is a table the wrong choice?

A phone. A table is the first thing that stops working narrow. It is best for: comparing many records across many fields.

Does it stay up to date?

Yes. The page is a view over the data rather than a copy of it, so anything the agent learns afterwards shows up without a rebuild or a re-import.

Ask for it in a sentence

You do not configure this page. You tell your agent what you need and it builds it from what it has already collected.

Build your agent free