Zylu Business

View saved version →

---
name: inventory-receiving
description: Record an incoming vendor delivery in Zylu and verify stock changes. Use when a user asks to receive stock, record a delivery invoice, or add purchased inventory.
---

Record an incoming inventory delivery for one Zylu business.

1. Establish the business context. If it is unknown, call `list_accessible_businesses`; ask the user to choose when more than one business is available.
2. Resolve the vendor with `search_vendors` and products with `search_products`. Do not infer IDs from names. If a vendor or product cannot be found, explain the missing record instead of creating one unless the user explicitly asks for that.
3. Collect and restate the receipt details before writing: vendor, invoice number, purchase date, and every line item's product, whole quantity, unit purchase price, optional tax treatment, and optional expiry date.
4. Call `create_inventory_receipt` only after the user has explicitly asked to record the delivery and the details are unambiguous. Do not set `allow_duplicate` unless the user explicitly authorizes a duplicate invoice number.
5. Verify the returned receipt: invoice number, vendor, received lines, total cost, and each product's `new_stock`. Report discrepancies or failed items clearly.

The tool changes product stock. Do not represent a draft as recorded, and do not use a purchase order workflow unless the user specifically asks to create or receive a purchase order.

View saved version →

---
name: lead-follow-up
description: Review Zylu customer enquiries and record a follow-up outcome or task. Use when a user asks to find leads, review follow-ups, log contact activity, or assign a follow-up task.
---

Help users manage a lead follow-up in one selected Zylu business.

1. Establish the business context. If it is unknown, call `list_accessible_businesses`; ask the user to choose when more than one business is available.
2. Use `search_enquiries` to find the target enquiry or list enquiries due for follow-up. Include activity history when it is needed to answer the request.
3. Before recording an activity, call `get_common_codes` to obtain valid `Activity` and, when relevant, `ActivityCallOutcome` identifiers. Do not guess these identifiers.
4. When the user gives the contact outcome, date, and notes, call `create_enquiry_activity`. Include a follow-up date only when the user supplies one or asks to schedule it.
5. Create a task with `create_task` only when the user explicitly asks to assign or create a task. Use `list_staff` first if an assignee must be resolved from a name.
6. Report the enquiry matched, the activity or task created, and any scheduled next step.

Ask a focused question when several enquiries match, the intended outcome is unclear, or the user has not supplied the details required to create a record. Do not send messages, contact leads, or claim a contact occurred; this workflow only reads and updates Zylu records.

View saved version →

---
name: weekly-business-performance-brief
description: Prepare a concise weekly business performance brief from Zylu analytics. Use when a user asks how a business performed, what changed, or what to focus on this week.
---

Prepare an evidence-based weekly brief for one Zylu business.

1. Establish the business context. If the user has not identified a business, call `list_accessible_businesses` and ask them to choose when more than one is available.
2. Establish the reporting period. Use the user's dates when supplied. For a request such as "this week," state the resolved date range. Do not silently compare periods unless the user asks for a comparison.
3. Call `get_analytics_catalog` for the selected business before forming a semantic query. Use only entities, dimensions, metrics, filters, and query instructions returned by that tool.
4. Call `query_analytics` for the smallest set of queries needed to answer the request. Keep pagination in mind and explain when results are incomplete.
5. Report the result in this order: reporting period, key results, meaningful changes or rankings, and up to three actions grounded in the returned data.

Do not invent benchmarks, causes, comparisons, customer behavior, or recommendations not supported by the returned analytics. If the available metrics cannot answer a part of the request, say what is unavailable.