Automate WooCommerce work with your agents

Trigger: Your bookkeeper finds money paid back to a buyer in WooCommerce, and no credit note for it in the accounts.

With Maplith:

1. The map: get_object on the refunds says each one carries the id of its order, and the order carries the number your accounts book against. The agent lists this month’s refunds in WooCommerce with its own access.
2. Route: route from each refund to the payment provider’s refund by the transaction id on its order, and to the invoice in your accounting system by order number. Each hop says how far Maplith trusts it.
3. Findings: Where a scan saw refunds with nothing matching them in the accounts, a finding names them, with its evidence and a recommendation.
4. The action gate: request_action for a task for the bookkeeper: each refund, its order number, and the credit note it still needs. The key’s policy decides whether it goes straight through.
5. Record and value: record_action records that the list reached the bookkeeper, and later which refunds were booked.

Result: The bookkeeper books each missing credit note against the right order number, from one list.

Trigger: Your marketing list counts one person twice: once as a registered customer, once from orders placed as a guest.

With Maplith:

1. Ask: ask: “how do WooCommerce’s guest orders tie to a registered customer?” The answer cites its joins: a guest order links only by its billing email.
2. Route: route from the WooCommerce customer to the contact in your CRM by customer email, with how much Maplith trusts that hop.
3. The map: get_object on the customers says which fields hold the order count and the total spend, so the agent compares the two records in WooCommerce with its own read access.
4. The action gate: request_action for a task for whoever owns the customer list, with both records and the email that joins them. Merging them stays that person’s call.
5. Record and value: record_action records the task and what the person decided.

Result: A person decides whether the two records are one buyer, with the match and its evidence in front of them.

Trigger: A buyer says the order is paid, and WooCommerce still shows it as pending payment.

With Maplith:

1. Task context: Your agent hands the buyer’s message to get_task_context, and gets back the playbook you wrote for payment questions, if there is one, and what its key may do.
2. Route: route from the WooCommerce order to the payment at Stripe or PayPal by the order’s transaction id.
3. The map: get_object on the order says which field carries its status; the agent reads the order in WooCommerce and the payment in Stripe, each with its own read access.
4. The action gate: request_action for a task for whoever handles payments: the order, the payment found at Stripe or PayPal, and the status the order should have. A person marks it paid in WooCommerce; Maplith never changes the order.
5. Record and value: record_action records the task and how it ended.

Result: The person who handles payments gets the order and the payment that settles it, side by side.