Square

Your assistant can list your locations, pull the payments for a date range at each one, and search the orders behind them so the total comes with its detail attached. That gets you past the number on the dashboard to the questions underneath it: which days carried the week, which location is drifting, what the average ticket did. Reading payments and orders changes nothing.

What you end up with. Last week's takings by location and by day, with the orders behind any figure you want to look into.

Start with it bringing you the information and you deciding.

Never without. Ask it whether the figure is gross or net of refunds and fees before you compare it to anything. Payments and orders are different records of the same week, and they do not add up to the same number.

Built on: List Locations / List Payments / Search Orders / Retrieve Order

It can search the catalog for the items you care about, pull the inventory counts for those variations across every location in one request, and read the recent change history on anything that looks wrong. The useful version is not the count. It is which items are moving fast enough that today's count will be zero by Friday.

What you end up with. A reorder list with the current count, the recent rate of movement, and the location each shortage is at.

Start with it bringing you the information and you deciding.

Never without. Check the count against the shelf for anything you are about to order in quantity. Square knows what was sold and what was entered, and it does not know what was dropped, eaten, or handed out.

Built on: Search Catalog Objects / Batch Retrieve Inventory Counts / Retrieve Inventory Changes / List Locations

It can list invoices for a location and read any one of them in full, including its payment requests, who it went to, and its current status. That is enough to separate the genuinely overdue from the drafts nobody ever sent and from the ones already settled, and to put a date against each. It reads only, so nothing on the invoice moves while it looks.

What you end up with. A list of who owes what and since when, with the unsent drafts separated out and the amount outstanding on each.

Start with it bringing you the information and you deciding.

Never without. Read the invoice status rather than the age. Square marks an invoice partly paid when money has landed against it, so an old invoice on this list can already be most of the way settled and chasing it in full is the wrong message to send.

Built on: List Invoices / Get Invoice / List Locations / Retrieve Customer

It can search availability for a service at a location across a date range and come back with the open slots, and it can pull a known booking by ID to check what is on either side of a gap. Team member records tell you who the availability belongs to. What comes back is where the space is, which is the version you can act on when you are deciding whether to run a promotion or move somebody's shift.

What you end up with. The open appointment slots for the week by location and by team member, with the known bookings around them.

Start with it bringing you the information and you deciding.

Never without. Availability is calculated from the service and the team member's working hours, so it reflects what Square has been told rather than who is actually free. Check anything you are about to promise against the person before it becomes a commitment.

Built on: Search Booking Availability / Get Booking / List Locations / Get Team Member

It can search the catalog for the items in scope, show you the current prices, and write the new ones, one object at a time or as a batch. Batches are processed all-or-nothing, which is what you want for a price change, since a half-applied one is worse than none. Have it produce the before-and-after list first and read it, then approve the write.

What you end up with. The new prices live across the items you named, and a saved before-and-after list you can check the register against.

Start with it doing the work and checking with you.

Never without. Read the before-and-after list in full before approving, and make sure the change lands on the item variations rather than the parent item. Prices sit on variations in Square, and a change written at the wrong level either does nothing or does it to everything.

Built on: Search Catalog Objects / Upsert Catalog Object / Batch Upsert Catalog Objects

It can pull the current counts for the items you counted, put your physical counts in against them, and record the adjustments for the gaps, up to a hundred changes in one pass. Square keeps physical counts and adjustments as different kinds of change, so the history afterward still shows which numbers came from a count and which came from a correction.

What you end up with. Inventory matching the shelf, with each change recorded as either a counted figure or an adjustment so the history stays readable.

Start with it doing the work and checking with you.

Never without. Confirm the location on every change before it writes. A physical count sets an absolute number, so one applied to the wrong location overwrites a good figure with another site's stock and the original count is gone.

Built on: Batch Retrieve Inventory Counts / Batch Create Inventory Changes / Retrieve Inventory Changes

It can find the original payment from the location and date range, then issue a refund in full or in part, and read the refund back afterward to confirm it went through and where it went. Square will not let a refund exceed the payment total minus anything already refunded, which catches the double-refund but not the wrong-payment refund.

What you end up with. The refund issued against the right payment, confirmed by reading it back with its amount, status, and destination.

Start with it doing the work and checking with you.

Never without. Approve the specific payment ID and the exact amount yourself, and never let it pick the payment from a description like the last one from that customer. Money leaving the account for a stranger's card is not something the connection can take back, and the person who was actually owed the refund is still owed it.

Built on: List Payments / Search Orders / Create Refund / Get Payment Refund

It can find the dead items from the catalog and the order history, then delete them. Square's own wording is the thing to pay attention to: deleting a catalog object also deletes everything in the graph that depends on it, and it cannot be recovered. A category takes its items. Run it in two moves, the list and then the approved deletion of exactly that list.

What you end up with. The dead items gone from the catalog, with a saved record of what was removed and what depended on it.

Start with it doing the work and checking with you.

Never without. Never delete a category or a modifier without first listing what depends on it, because Square cascades the deletion down the graph and none of it can be recovered. Delete the specific item variations you read and approved, not a rule that describes them.

Built on: Search Catalog Objects / Search Orders / Delete Catalog Object / Delete Catalog Objects (Batch)