# Blog
Source: https://docs.wayak.io/blog/index
News, updates, and insights from the Wayak team
Stay up to date with the latest from Wayak — product updates, industry deep dives, and lessons from real deployments.
***
## Latest posts
We're publishing detailed walkthroughs of how teams in manufacturing, insurance, retail, and more use Wayak to automate data workflows. Check back soon.
New features, improvements, and release notes from the Wayak platform.
***
## Topics we cover
Real-world stories of how teams deploy Wayak agents across industries.
New features, platform updates, and engineering insights.
Tips for building effective agents, ontologies, and automated workflows.
Want to see a topic covered? Let us know — we write about what our users care about.
# App integrations
Source: https://docs.wayak.io/concepts/agents/app-integrations
Connect agents to the tools your team already uses
App integrations let your Wayak agents interact with the tools your team works in every day. Instead of switching to Wayak to get answers, your team can access the agent where they already are.
![Wayak AI integrations interface]()
## How integrations work
An app integration connects a Wayak agent to an external platform. The agent can:
* **Receive messages** from the platform (a Slack message, an email, a webhook)
* **Respond** with data-driven answers using your connected data sources and ontology
* **Take actions** in the platform (post a message, update a record, trigger a workflow)
## Integration types
Integrations fall into two categories:
| Type | Description | Examples |
| ------------- | ----------------------------------------------------------- | -------------------------------- |
| **Messaging** | Users interact with the agent through a chat interface | Slack, Microsoft Teams, web chat |
| **Action** | The agent pushes data or triggers actions in external tools | Email, webhooks, CRM updates |
Both types use the same underlying agent — the integration just determines where the conversation happens and what actions are available.
# Custom agents
Source: https://docs.wayak.io/concepts/agents/custom-agents
Define AI personas with specific roles, goals, and behaviors
A custom agent is a **persona definition**. It gives the agent a name, a role to enact, a goal to pursue, and behavioral guidelines that shape how it communicates. Where [skills](/concepts/agents/skills) are procedural instructions for *how to do a task*, a custom agent defines *who is doing it* — the identity, context, and guardrails around the agent's behavior.
Think of it this way: you hire a specialist (the agent) and hand them a playbook of tasks (the skills). The agent's persona determines how they approach the work — their expertise, tone, and priorities.
![Custom agents management interface]()
## What makes up a custom agent
| Component | What it defines |
| ------------------ | ------------------------------------------------------------------------------------ |
| **Name** | The agent's identity (e.g., "Production Analyst", "Support Rep") |
| **Role** | What the agent does — its area of expertise |
| **Goal** | The outcome the agent should pursue whenever it is used |
| **Description** | Detailed behavioral instructions — tone, formality, what to emphasize, what to avoid |
| **Data access** | Which data sources and knowledge bases the agent can query |
| **Ontology scope** | Which objects, metrics, and dimensions are relevant |
| **Skills** | Which skills the agent can execute |
## Example
Here is what a custom agent definition looks like in practice:
| Field | Value |
| -------- | -------------------------------------------------- |
| **Name** | Support Rep |
| **Role** | Customer service specialist |
| **Goal** | Resolve customer issues quickly and empathetically |
**Description:**
> You are a customer support specialist. Always greet the customer by name when available. Use a warm, professional tone. Acknowledge the customer's frustration before jumping to a solution. Keep responses concise — no more than three paragraphs. If you cannot resolve an issue, escalate clearly and explain what happens next. Never promise refunds or credits without confirming the policy first.
The description is where you invest the most effort. It tells the agent *how* to behave — the tone, the boundaries, and the priorities that make it effective for a specific team or role.
## Why custom agents
Different teams need different things:
* A **sales agent** that knows your pipeline metrics and CRM data
* A **finance agent** that understands your accounting terminology and reports
* An **ops agent** that monitors operational KPIs and can trigger alerts
Each of these agents might share some of the same skills (like generating a report or looking up a customer), but they differ in the data they access, the terminology they use, and the instructions that shape their responses.
## Custom agents vs. skills
| | Custom agent | Skill |
| ----------- | -------------------------------------------------- | ---------------------------------------------------- |
| **Defines** | *Who* — a persona with identity, tone, and context | *What* — procedural instructions for a specific task |
| **Scope** | Data access, ontology, behavioral guidelines | Trigger, inputs, steps, and output |
| **Reuse** | Each agent is a unique configuration | A single skill can be assigned to many agents |
| **Example** | A finance agent scoped to accounting data | A "calculate work order variance" instruction set |
You build custom agents to match your organizational structure, then equip each one with the [skills](/concepts/agents/skills) it needs.
Browse concrete agent and skill examples for manufacturing, customer service, insurance, and more.
# Examples
Source: https://docs.wayak.io/concepts/agents/examples
Agent and skill examples by industry
Browse concrete examples of [custom agents](/concepts/agents/custom-agents) and [skills](/concepts/agents/skills) organized by industry. Each tab shows what agents and skills look like for a specific domain.
For deeper use case walkthroughs, visit the [Use cases](/use-cases/index) section.
## Agents
| Field | Value |
| -------- | -------------------------------------------------------------- |
| **Role** | Production order analyst |
| **Goal** | Surface cost overruns and variance issues before they escalate |
**Description:**
> You are a production cost analyst. Monitor work orders and flag any where actual costs deviate significantly from estimates. Lead with the numbers — show the variance first, then explain the likely cause. Use direct, factual language. When a variance exceeds 10%, always recommend a specific next step (review labor entries, check material pricing, audit overhead allocation). Do not speculate about root causes you cannot verify from the data.
| Field | Value |
| -------- | ----------------------------------------------- |
| **Role** | Quality control specialist |
| **Goal** | Identify defect patterns and reduce scrap rates |
**Description:**
> You are a quality control analyst focused on reducing defect rates. When asked about quality, always start with the current defect rate trend before diving into specifics. Group defects by category (material, process, operator) and highlight the highest-impact area first. Use precise numbers and percentages. Recommend corrective actions based on data, not assumptions.
## Skills
**Trigger:** User asks about production cost variance or work order costs
> 1. Identify the work order number from the user's request.
> 2. Pull the estimated cost from the work order header (planned labor + planned materials + planned overhead).
> 3. Pull the actual cost by summing all posted transactions against the work order.
> 4. Calculate the variance: actual cost minus estimated cost.
> 5. Break the variance into labor, material, and overhead categories.
> 6. If the total variance exceeds 10%, flag it and list the top contributing line items.
> 7. Present results in a table with estimated, actual, and variance columns.
**Trigger:** End of shift or user request
> 1. Pull production output for the specified shift (units produced, units scrapped).
> 2. Calculate OEE (Overall Equipment Effectiveness) for each line: availability x performance x quality.
> 3. Compare against the target OEE for that line.
> 4. List any unplanned downtime events with duration and cause code.
> 5. Summarize in a table: line, target OEE, actual OEE, units produced, scrap count.
**Trigger:** Scheduled daily or user request
> 1. Query the maintenance schedule for all equipment.
> 2. Identify any items past their scheduled service date.
> 3. Sort by days overdue, highest first.
> 4. For each overdue item, include: equipment name, last service date, days overdue, and criticality rating.
> 5. If any critical equipment is more than 7 days overdue, add an urgent flag.
## Agents
| Field | Value |
| -------- | -------------------------------------------------- |
| **Role** | Customer service specialist |
| **Goal** | Resolve customer issues quickly and empathetically |
**Description:**
> You are a customer support specialist. Always greet the customer by name when available. Use a warm, professional tone. Acknowledge the customer's frustration before jumping to a solution. Keep responses concise — no more than three paragraphs. If you cannot resolve an issue, escalate clearly and explain what happens next. Never promise refunds or credits without confirming the policy first.
| Field | Value |
| -------- | ------------------------------------------------------------------ |
| **Role** | Escalation and root-cause specialist |
| **Goal** | Identify patterns in escalated tickets and recommend process fixes |
**Description:**
> You analyze escalated support tickets. Focus on identifying systemic issues — recurring product bugs, confusing documentation, or policy gaps. When presenting findings, group by root cause category and quantify impact (number of tickets, average resolution time). Use a neutral, analytical tone. Always include a recommended action for each pattern you identify.
## Skills
**Trigger:** User asks to draft a reply or a new support email arrives
> 1. Read the incoming email and identify the issue type (billing, technical, order status, general inquiry).
> 2. Check the customer's history for prior interactions and open tickets.
> 3. Draft a reply that: acknowledges the issue, provides a clear next step, and sets expectations for resolution time.
> 4. Match the company's tone guidelines: professional, empathetic, concise.
> 5. If the issue requires internal action (refund, escalation), note it separately as an internal comment.
> 6. Present the draft for review before sending.
**Trigger:** New ticket created
> 1. Read the ticket subject and body.
> 2. Classify into one of the predefined categories: billing, technical, shipping, returns, account, other.
> 3. Assign a priority: low (informational), medium (action needed), high (revenue impact or SLA risk).
> 4. Tag with relevant product or feature area.
> 5. If the ticket mentions legal action, compliance, or data privacy, auto-escalate to the legal queue.
**Trigger:** User asks about a specific customer or before handling a ticket
> 1. Look up the customer by name, email, or account ID.
> 2. Pull their last 10 interactions (tickets, calls, emails).
> 3. Summarize: total tickets, open tickets, average resolution time, most common issue type.
> 4. Note any VIP status, special agreements, or past escalations.
> 5. Present as a brief profile with a timeline of recent interactions.
## Agents
| Field | Value |
| -------- | ---------------------------------------------------------------- |
| **Role** | Claims intake and classification specialist |
| **Goal** | Process new claims quickly and route them to the correct handler |
**Description:**
> You process incoming insurance claims. Extract key information from submissions (policy number, date of loss, claim type, supporting documents). Classify each claim by type (auto, property, liability, health) and complexity. Use a formal, precise tone — this is regulated work. Flag any missing documentation immediately and specify exactly what is needed. Never make coverage determinations; your job is to intake and route.
| Field | Value |
| -------- | ------------------------------------------------------ |
| **Role** | Fraud pattern identification specialist |
| **Goal** | Flag suspicious claims for investigation before payout |
**Description:**
> You review claims for fraud indicators. Compare claim details against known fraud patterns (duplicate claims, inconsistent timelines, inflated values, staged losses). Present findings as a risk score with supporting evidence. Use precise, objective language — never state that fraud occurred, only that indicators were detected. Always recommend next steps: approve, flag for investigation, or request additional documentation.
## Skills
**Trigger:** New claim documents uploaded
> 1. Read the uploaded documents (FNOL forms, police reports, medical bills, repair estimates).
> 2. Extract: policy number, claimant name, date of loss, loss description, claimed amount.
> 3. Cross-reference the policy number against active policies to confirm coverage.
> 4. List any missing required documents.
> 5. Output a structured claim summary with all extracted fields.
**Trigger:** User requests a reserve estimate or new claim is classified
> 1. Identify the claim type and severity from the intake summary.
> 2. Pull historical data for similar claims (same type, similar loss amount, same region).
> 3. Calculate the average payout for comparable claims.
> 4. Adjust for claim-specific factors: documentation quality, liability clarity, injury severity.
> 5. Present the reserve estimate with a confidence range (low, expected, high).
## Agents
| Field | Value |
| -------- | ----------------------------------------------------------- |
| **Role** | Talent acquisition specialist |
| **Goal** | Move candidates through the pipeline efficiently and fairly |
**Description:**
> You help the recruiting team manage candidates. When screening resumes, focus on skills and experience — not school names or company prestige. Use clear, structured summaries when presenting candidates. When communicating with candidates, be warm and responsive. Always include next steps and expected timelines. Flag any scheduling conflicts or process bottlenecks proactively.
| Field | Value |
| -------- | ------------------------------------------------------------------------------- |
| **Role** | Employee experience and policy specialist |
| **Goal** | Answer employee questions accurately and route complex issues to the right team |
**Description:**
> You answer employee questions about policies, benefits, and HR processes. Always reference the specific policy document when providing an answer. Use a friendly, approachable tone. If a question involves a sensitive topic (termination, harassment, accommodation), do not attempt to resolve it — acknowledge the question and escalate to the appropriate HR partner immediately. Keep answers factual and cite sources.
## Skills
**Trigger:** New application submitted or user requests screening
> 1. Parse the resume for: years of experience, relevant skills, education, and past roles.
> 2. Compare against the job requirements (must-haves and nice-to-haves).
> 3. Score the candidate: strong match, partial match, or no match.
> 4. Write a two-sentence summary highlighting the strongest qualification and the biggest gap.
> 5. If strong match, recommend scheduling an interview and suggest which interviewer panel fits best.
**Trigger:** New hire confirmed
> 1. Pull the new hire's role, department, location, and start date.
> 2. Generate a checklist from the onboarding template for that department.
> 3. Assign tasks to the relevant owners (IT for equipment, manager for introductions, HR for paperwork).
> 4. Set due dates relative to the start date (e.g., equipment ready 2 days before, orientation on day 1).
> 5. Deliver the checklist to the hiring manager and the new hire.
## Agents
| Field | Value |
| -------- | ------------------------------------------------------- |
| **Role** | Stock and demand planning specialist |
| **Goal** | Prevent stockouts and reduce overstock across locations |
**Description:**
> You monitor inventory levels and demand signals. Lead with the data — show current stock levels, sell-through rates, and days of supply before making recommendations. Use concise, action-oriented language. When recommending reorders, specify quantities, supplier lead times, and expected delivery dates. Flag slow-moving inventory that may need markdowns. Never round numbers — precision matters in inventory management.
| Field | Value |
| -------- | ------------------------------------------------------------------------------- |
| **Role** | Product performance analyst |
| **Goal** | Identify top-performing and underperforming products to optimize the assortment |
**Description:**
> You analyze product performance across channels. Compare sales, margins, and return rates by category, brand, and SKU. Present findings as ranked lists with clear metrics. When recommending assortment changes, back them with data: what to keep, what to drop, and what to test. Use a neutral, analytical tone.
## Skills
**Trigger:** Daily schedule or stock drops below safety threshold
> 1. Pull current stock levels for all SKUs at each location.
> 2. Calculate days of supply based on the trailing 14-day sales rate.
> 3. Identify any SKU with fewer than 7 days of supply.
> 4. For each flagged SKU, calculate the recommended reorder quantity: target 30 days of supply minus current stock.
> 5. Check supplier lead times and flag any where lead time exceeds days of supply remaining.
> 6. Output a reorder table: SKU, location, current stock, days of supply, recommended order, supplier, lead time.
**Trigger:** User asks about a promotion or promotion period ends
> 1. Pull sales data for the promotion period and the same period prior year.
> 2. Calculate: revenue lift, unit lift, margin impact, and cannibalization of non-promoted items.
> 3. Compare against the promotion target if one was set.
> 4. Summarize whether the promotion was profitable after accounting for markdowns and incremental costs.
## Agents
| Field | Value |
| -------- | ------------------------------------------------------------ |
| **Role** | Delivery route and fleet analyst |
| **Goal** | Minimize delivery costs and transit times across the network |
**Description:**
> You optimize delivery routes and fleet utilization. When analyzing routes, always factor in: distance, traffic patterns, delivery windows, vehicle capacity, and driver hours. Present route recommendations as comparisons — show the current route vs. the optimized route with estimated savings. Use precise metrics (miles, hours, cost). Flag any delivery at risk of missing its window.
| Field | Value |
| -------- | ------------------------------------------------------------------------ |
| **Role** | Shipment visibility and exception specialist |
| **Goal** | Keep stakeholders informed and catch delays before they impact customers |
**Description:**
> You track shipments across carriers and flag exceptions. When reporting status, lead with the headline: on-time, delayed, or at-risk. For delays, always include the cause, the revised ETA, and the impact on downstream commitments. Use a factual, calm tone — even when reporting problems. Proactively suggest mitigation options (re-route, expedite, notify customer).
## Skills
**Trigger:** User asks about route performance or daily route review
> 1. Pull planned vs. actual route data for the specified period.
> 2. Calculate: planned miles vs. actual miles, planned stops vs. completed stops, planned time vs. actual time.
> 3. Identify routes with more than 15% deviation from plan.
> 4. For each deviation, note the likely cause: traffic, failed delivery attempt, incorrect sequence, unplanned stop.
> 5. Output a route efficiency table with a flag column for underperforming routes.
**Trigger:** Daily schedule or user request
> 1. Pull all shipments with a status of delayed, failed, or at-risk.
> 2. Group by exception type: carrier delay, address issue, customs hold, weather, capacity.
> 3. For each shipment, include: tracking number, origin, destination, original ETA, revised ETA, and carrier.
> 4. Calculate the total number of affected orders and estimated revenue at risk.
> 5. Recommend an action for each group: escalate to carrier, notify customer, re-route, or hold.
# Agent space
Source: https://docs.wayak.io/concepts/agents/index
Configure AI agents that work with your data and tools
The agent space is where you configure the AI agents that interact with your data, your team, and your tools. Wayak agents are more than chatbots — they understand your ontology, connect to your apps, and execute skills you define.
![Wayak custom agents interface]()
***
## What's in the agent space
Define AI personas with specific roles, goals, and behavioral guidelines. Each agent is scoped to the data and tools it needs.
Write procedural instructions that teach agents how to perform specific tasks — step by step, in plain language.
Connect agents to the tools your team already uses — Slack, email, CRMs, and more.
Browse concrete agent and skill examples for manufacturing, customer service, insurance, and more.
***
## How agents use the platform
Every agent in Wayak draws on four layers to do its work:
Query databases, APIs, and uploaded files. The agent has direct access to your structured data and can run queries against it.
Search and read unstructured documents — PDFs, reports, presentations, internal docs. The agent finds relevant passages and cites them.
Understand your business metrics, terminology, and relationships. The ontology tells the agent what "revenue" means and how to compute it.
Execute defined actions and workflows. Skills give agents the procedural knowledge to do things — not just answer questions.
The combination of data access, business understanding, and actionable skills is what makes Wayak agents agentic — they don't just answer questions, they get things done.
***
## Agents vs. skills at a glance
### Custom agents Who
A persona definition — name, role, goal, tone, and behavioral guidelines. Determines *how* the agent acts and *what data* it can see.
### Skills What
Procedural instructions in markdown — trigger, steps, and output. Determines *what tasks* an agent can perform. Reusable across agents.
# Skills
Source: https://docs.wayak.io/concepts/agents/skills
Procedural instructions that teach agents how to perform specific tasks
A skill is a **set of procedural instructions** written in plain language that teaches an agent how to perform a specific task. Skills go beyond answering questions — they tell the agent exactly what steps to follow, what data to pull, and what output to deliver.
Skills are separate from the [ontology](/concepts/ontology/index). The ontology defines *what things are* (metrics, dimensions, entities). A skill defines *how to do something* with that data — the step-by-step procedure an agent follows when a task is triggered.
While a [custom agent](/concepts/agents/custom-agents) defines the persona (*who* is doing the work), skills define the tasks (*what* work gets done). Skills are portable — you write a skill once and assign it to any number of agents.
![Wayak organization skills interface]()
## What a skill looks like
A skill is a markdown description with:
* **A name** — what the skill is called (e.g., "Calculate work order variance")
* **A trigger** — how the skill gets activated (user request, keyword, scheduled)
* **Instructions** — step-by-step procedural guidance in plain language
* **Output** — what the agent returns or delivers
The instructions are the core of a skill. They read like a procedure manual — clear, specific, and actionable.
## Example
Here is what a skill definition looks like in practice:
**Name:** Calculate work order variance
**Trigger:** User asks about production cost variance or work order costs
**Instructions:**
> 1. Identify the work order number from the user's request.
> 2. Pull the **estimated cost** from the work order header (planned labor + planned materials + planned overhead).
> 3. Pull the **actual cost** by summing all posted transactions against the work order (actual labor hours x rate, actual material issues, applied overhead).
> 4. Calculate the variance: actual cost minus estimated cost.
> 5. Break the variance into three categories: labor variance, material variance, and overhead variance.
> 6. If the total variance exceeds 10%, flag it and list the top contributing line items.
> 7. Present results in a table with estimated, actual, and variance columns.
**Output:** A variance summary table with a flag if the variance exceeds the threshold.
Notice how the skill is purely procedural — it doesn't define what a "work order" is (that's the ontology's job) or how to talk to the user (that's the agent's persona). It only describes *how to calculate the variance*.
## More examples
| Skill | What it does |
| ---------------------- | --------------------------------------------------------------------------------------------------------------- |
| Draft customer reply | Reads the incoming email, detects the issue type, and writes a response following the company's tone guidelines |
| Generate weekly report | Queries defined metrics, formats a summary, and delivers to a channel |
| Look up customer | Finds a customer across data sources and returns a consolidated profile |
| Create alert | Monitors a metric and notifies the team when a threshold is crossed |
## Skills vs. custom agents
A skill packages *how* to do something — the instructions for a specific task. A [custom agent](/concepts/agents/custom-agents) packages *who* is doing it — the persona, data access, and behavioral guidelines.
| | Skill | Custom agent |
| ---------------------------- | --------------------------------------------------------- | ---------------------------------------------------- |
| **Defines** | A procedure — *how* to perform a task | A persona — *who* the agent is |
| **Content** | Step-by-step instructions in markdown | Role, goal, tone, and behavioral guidelines |
| **Portability** | Assign to multiple agents | Each agent is a unique configuration |
| **Relationship to ontology** | Separate — uses ontology concepts but doesn't define them | Scopes which parts of the ontology the agent can see |
## Skills vs. playbooks
Skills are individual capabilities — a single action or short sequence. [Playbooks](/concepts/playbooks/what-is-a-playbook) are full automations that chain multiple skills and logic together into complex workflows.
Browse concrete agent and skill examples for manufacturing, customer service, insurance, and more.
# API connections
Source: https://docs.wayak.io/concepts/data-platform/api-connections
Ingest data from external APIs into Wayak
API connections let you pull data from external services into Wayak. Configure endpoints, authentication, and sync schedules to keep your data current.
![Wayak integration hub]()
## When to use API connections
Use API connections when the data you need doesn't live in a database — for example:
* Records from a SaaS tool (CRM, ERP, marketing platforms)
* Data from third-party services
* Internal microservice endpoints
## How it works
1. Configure the API endpoint and authentication method
2. Define the data mapping — how the API response maps to a table structure
3. Set a sync schedule to keep the data up to date
Once synced, the data is queryable by the agent just like any other data source.
# Databases
Source: https://docs.wayak.io/concepts/data-platform/databases
Connect your existing databases to Wayak
Connect your relational databases, data warehouses, and other SQL-compatible systems directly to Wayak. The agent reads your schema and can query your data in real time.
![Wayak integration hub]()
## Supported databases
Wayak supports direct connections to major database systems including PostgreSQL, MySQL, SQL Server, and cloud data warehouses.
## How connections work
1. Provide your connection credentials (host, port, database, user, password)
2. Wayak introspects your schema — tables, columns, types, and relationships
3. The agent can query your database immediately
Wayak uses read-only connections by default. Your data stays in your database — Wayak queries it in place.
# Knowledge bases
Source: https://docs.wayak.io/concepts/data-platform/knowledge-bases
Upload unstructured documents and build searchable knowledge indexes
Knowledge bases store your unstructured data — PDFs, reports, presentations, wiki exports, and other documents. Wayak indexes them for fast retrieval and gives the agent the ability to read and reason over the full content.
![Wayak knowledge bases interface]()
## What knowledge bases do
1. **Retrieval index** — Wayak builds a search index over your documents so the agent can quickly find relevant passages
2. **Full document access** — The agent can pull and read entire files when it needs deeper context, not just matched snippets
## What you can upload
* PDFs and documents
* Presentations and slide decks
* Internal wiki exports
* Research papers and reports
* Any text-based file
## How it differs from the lakehouse
The lakehouse handles structured, tabular data (spreadsheets, CSVs). Knowledge bases handle narrative, free-form content (documents, reports). Use both together for complete coverage of your organization's data.
# Data lakehouse
Source: https://docs.wayak.io/concepts/data-platform/lakehouse
Wayak's built-in storage for uploading and querying structured files
The data lakehouse is Wayak's built-in storage layer. Upload Excel files, CSVs, and other structured documents directly — no external database required. Once uploaded, your files become queryable tables that the agent can access just like any other data source.
![Wayak lakehouse tables]()
## What you can upload
* Excel files (`.xlsx`, `.xls`)
* CSV files (`.csv`)
* Any structured, tabular document
## How it works
1. Upload a file through the Wayak dashboard
2. Wayak parses the file, infers column types, and creates a queryable table
3. The agent can query it immediately — no configuration needed
The lakehouse is the fastest way to get data into Wayak. If you have a spreadsheet, you can be chatting with it in under a minute.
# Why Wayak
Source: https://docs.wayak.io/concepts/index
An agentic platform for organizations that run on data
Large organizations sit on enormous amounts of data spread across dozens of systems — databases, data warehouses, SaaS tools, file shares, internal wikis. The people who need answers from that data rarely have direct access, and when they do, it takes too long.
Wayak changes that equation. It connects an AI agent to all of your company's data — structured and unstructured — and gives it the business context to navigate that data the way your best people do.
![Wayak data platform overview]()
No tickets. No waiting. No SQL. Just ask.
***
## Who Wayak is built for
Spread across multiple databases, APIs, SaaS tools, and document repositories.
Decisions can't wait for a data team backlog.
Recurring reports, alerts, and workflows consume too much manual effort.
Leadership wants AI that creates real operational leverage, not just novelty.
***
## What makes Wayak different
Most AI data tools do one thing — answer a question from a single database. Wayak is a full platform.
Connect every data source your organization uses into one place.
PostgreSQL, MySQL, BigQuery, Snowflake, and more.
Pull data from any REST or GraphQL API.
Upload CSVs, Excel files, and other flat files directly.
Upload PDFs, docs, and presentations for RAG-powered search.
Encode your business logic so the agent answers with precision.
Core entities — customers, orders, products.
Calculations — revenue, churn, conversion.
Attributes — region, status, tier.
Specific instances and identity resolution.
Charts and tables for specific data slices.
Collections of views on a single page.
Build specialized agents that know your data and execute tasks.
Define personas with specific roles, goals, and behaviors.
Procedural instructions that teach agents how to do tasks.
Connect agents to the tools your team already uses.
Browse agent and skill examples by industry.
Automate repeatable work with multi-step workflows.
Understand how playbooks chain skills and logic together.
Build your first automated workflow step by step.
The building blocks — triggers, actions, conditions, and outputs.
***
## The platform at a glance
```mermaid placement="center" theme={null}
flowchart TB
team[Your Team] --> agents[AI Agents]
subgraph intelligence[Intelligence Layer]
direction LR
ontology[Ontology\nMetrics · Terms · Joins]
playbooks[Playbooks\nAutomated Workflows]
skills[Skills\nReusable Actions]
end
agents --> intelligence
subgraph data[Data Platform]
direction LR
db[Databases]
api[APIs]
lake[Lakehouse]
kb[Knowledge Bases]
end
intelligence --> data
```
Start with the [quickstart](/quickstart) to get hands-on, or explore any section above to go deeper.
# Dashboards
Source: https://docs.wayak.io/concepts/ontology/dashboards
Assemble views into shareable, at-a-glance pages
Dashboards are collections of views arranged into a single page. They give your team an at-a-glance picture of a topic — sales performance, operational health, customer activity, or anything else you want to monitor.
![Wayak dashboard with embedded agent]()
## What a dashboard is
A dashboard combines multiple views into one layout. Each view shows a different slice of data, and together they tell a complete story.
For example, a "Sales Performance" dashboard might include:
* A KPI card for total revenue this month
* A line chart of revenue over the last 12 months
* A bar chart of revenue by region
* A table of top 10 deals this quarter
## Building dashboards
1. Create the individual views you want to include
2. Create a new dashboard in the Wayak dashboard
3. Add your views and arrange them in a layout
4. Share the dashboard with your team
## Live data
Dashboards always show live data. Because views are built on your ontology and connected to your data sources, the numbers update automatically as your data changes.
# Dimensions
Source: https://docs.wayak.io/concepts/ontology/dimensions
Categorize and slice your data with descriptive attributes
Dimensions are the attributes that describe, categorize, and segment your objects. They're what you group by, filter on, and break down — region, status, product category, date, customer tier.
## How dimensions work
A dimension is a property of an object that the agent can use to slice data. When someone asks "revenue by region," the agent uses the Region dimension to group results.
| Object | Dimension | Source column | Description |
| -------- | --------- | ------------------- | ---------------------------- |
| Customer | Region | `accounts.region` | Geographic area |
| Customer | Tier | `accounts.tier` | Gold, Silver, Bronze |
| Order | Status | `orders.status` | Pending, Complete, Cancelled |
| Order | Date | `orders.created_at` | When the order was placed |
## Dimensions vs. metrics
Dimensions describe *what* you're looking at. Metrics measure *how much* or *how many*. You group by dimensions and aggregate metrics.
* "Revenue **by region**" → Region is the dimension, Revenue is the metric
* "Customer count **by tier**" → Tier is the dimension, Count is the metric
# Entities
Source: https://docs.wayak.io/concepts/ontology/entities
Identify and resolve specific instances across your data sources
Entities are specific instances of objects — a particular customer, a specific order, an individual product. Entity definitions tell the agent how to identify and resolve them, especially when the same entity appears across multiple data sources.
## What entities solve
Your data often refers to the same real-world thing in different places with different identifiers. A customer might be `account_id` in your database, an email address in your CRM, and a company name in your documents.
Entities define how to resolve these references so the agent treats them as a single thing.
## Entity resolution
When you define an entity, you specify:
* **The object it belongs to** — e.g. Customer
* **Identifiers** — the fields that uniquely identify it across sources (account ID, email, domain, etc.)
* **Resolution rules** — how to match when identifiers differ (e.g. fuzzy match on company name)
This means when someone asks "Tell me about Acme Corp," the agent can pull data from every source that mentions Acme — even if each source uses a different identifier.
# What is an ontology?
Source: https://docs.wayak.io/concepts/ontology/index
How Wayak's semantic layer teaches AI to understand your data like your team does
An ontology is the map of your business logic. It's how you teach Wayak's agent to understand your data the same way a person at your company would — what things are called, how they relate, and what they mean.
In Wayak, the ontology is the semantic layer. It sits between your raw data and the AI agent, translating business language into precise data operations.
![Wayak semantic objects interface]()
***
## Why you need one
### Without an ontology
The agent guesses. A table called `txn_ledger` with a column `amt_net_usd` means nothing without context. Results are inconsistent and unreliable.
### With an ontology
The agent answers with the same precision as your best analyst. It knows "revenue" means `SUM(amt_net_usd) WHERE txn_type = 'sale'` and applies that consistently.
***
## The building blocks
The ontology is made up of six components that work together in a hierarchy:
The core entities in your business — customers, orders, products, employees.
The attributes that describe and categorize your objects — region, status, tier.
Specific instances and how they're identified and resolved across data sources.
The calculations your team cares about — revenue, churn, conversion rate.
Standalone charts and tables that visualize specific slices of your data.
Collections of views assembled into a single, shareable page.
***
## How it all fits together
```mermaid placement="center" theme={null}
flowchart TD
objects[Objects\nCustomers · Orders · Products] --> dimensions[Dimensions\nRegion · Status · Tier]
objects --> entities[Entities\nIdentity Resolution]
objects --> metrics[Metrics\nRevenue · Churn · Conversion]
metrics --> views[Views\nCharts · Tables]
views --> dashboards[Dashboards\nShareable Pages]
```
The agent uses this hierarchy to navigate from a user's question down to the exact data operation needed to answer it.
Start by defining your most important [objects](/concepts/ontology/objects) and [metrics](/concepts/ontology/metrics) — those two alone give the agent enough context to answer most business questions accurately.
# Metrics
Source: https://docs.wayak.io/concepts/ontology/metrics
Define the calculations and KPIs your team relies on
Metrics are the measurements your business runs on — revenue, churn rate, conversion, active users, average order value. In Wayak's ontology, a metric is a precise calculation definition that the agent uses every time someone asks about that measurement.
![Wayak metrics studio]()
## Why define metrics
Without defined metrics, the agent has to guess how to calculate "revenue." It might sum the wrong column, miss a filter, or use a different aggregation than your team expects. Defined metrics eliminate that ambiguity.
Every time someone asks about a metric, the agent uses the exact same formula. Same question, same answer, every time.
## Anatomy of a metric
A metric definition includes:
| Component | Description | Example |
| ---------------- | -------------------------------- | --------------- |
| **Name** | What your team calls it | "Revenue" |
| **Source table** | Where the raw data lives | `transactions` |
| **Aggregation** | How to compute it | SUM |
| **Column** | What to aggregate | `amount_usd` |
| **Filters** | Conditions that scope the metric | `type = 'sale'` |
| **Time grain** | Default time granularity | Monthly |
## Composing metrics
Metrics can build on each other. For example:
* **Revenue** = `SUM(amount_usd) WHERE type = 'sale'`
* **Cost** = `SUM(amount_usd) WHERE type = 'expense'`
* **Profit** = Revenue - Cost
* **Margin** = Profit / Revenue
The agent understands these dependencies and computes derived metrics correctly.
## Metrics vs. dimensions
Metrics are *what you measure*. Dimensions are *how you slice it*. They work together:
* "**Revenue** by **region** for **last quarter**"
* Revenue = metric
* Region = dimension
* Last quarter = time filter
# Objects
Source: https://docs.wayak.io/concepts/ontology/objects
Define the core entities that make up your business domain
Objects are the fundamental building blocks of your ontology. They represent the real things in your business — customers, orders, products, employees, transactions, campaigns.
![Wayak semantic objects interface]()
## What an object represents
An object maps to one or more tables in your data sources. It defines what a "thing" is in your business and how it's stored. For example:
| Object | Maps to | Description |
| -------- | ---------------- | ------------------------------------ |
| Customer | `accounts` table | A business or individual you sell to |
| Order | `orders` table | A completed purchase |
| Product | `products` table | Something you sell |
## Why objects matter
When someone asks "How many customers do we have?", the agent needs to know what "customer" means in your data. The object definition tells it exactly which table to query and what filters to apply.
Objects are the anchor point for everything else in the ontology — dimensions describe them, entities identify them, and metrics measure them.
# Views
Source: https://docs.wayak.io/concepts/ontology/views
Standalone charts and tables that visualize your data
Views are individual visualizations — a chart, a table, a KPI card. Each view represents a specific slice of your data, defined by a combination of metrics, dimensions, and filters.
![Wayak views interface]()
## What a view is
A view is a saved visualization that answers a specific question. It can be:
* A **line chart** showing revenue over time
* A **bar chart** comparing sales by region
* A **table** listing top customers by spend
* A **KPI card** displaying a single number like total active users
Views are standalone. You can use them on their own or combine them into dashboards.
## How views use the ontology
Views are built on top of your ontology definitions. A view references:
* **Metrics** — what to measure (revenue, count, average)
* **Dimensions** — how to break it down (by region, by month, by product)
* **Filters** — what to scope (last 90 days, active customers only)
Because views use your defined metrics, the numbers are always consistent with what the agent reports in conversation.
## Views vs. ad hoc answers
When you ask the agent a question in chat, it generates an answer on the fly. A view is a saved, reusable version of that answer — pinned so you can check it anytime without re-asking.
# Playbook components
Source: https://docs.wayak.io/concepts/playbooks/components
The building blocks you use to assemble playbook workflows
Playbooks are built from components — modular pieces that you connect into a workflow. Each component type handles a different part of the automation.
## Data components
| Component | Description |
| ---------- | ---------------------------------------------------------------------------- |
| **Query** | Run a query against a data source using your ontology metrics and dimensions |
| **Search** | Search a knowledge base for relevant documents or passages |
| **Lookup** | Find a specific entity across your data sources |
## Logic components
| Component | Description |
| ------------- | ------------------------------------------------------------------------------- |
| **Condition** | Branch the workflow based on a true/false check (e.g. "if revenue > threshold") |
| **Loop** | Repeat a set of steps for each item in a list (e.g. for each overdue invoice) |
| **Filter** | Narrow down a dataset before passing it to the next step |
| **Transform** | Reshape or format data between steps |
## Action components
| Component | Description |
| ----------------- | --------------------------------------------------- |
| **Send email** | Deliver formatted content to one or more recipients |
| **Post to Slack** | Send a message to a Slack channel or user |
| **Webhook** | Call an external URL with a payload |
| **Update record** | Write back to a connected data source |
| **Run skill** | Execute an agent skill as part of the workflow |
## How components connect
Components are arranged in sequence. Each component receives the output of the previous step and passes its own output forward. Branching components (like Condition) create parallel paths that can merge back together downstream.
```
Trigger
→ Query (get overdue invoices)
→ Loop (for each invoice)
→ Condition (is amount > $10,000?)
→ Yes: Send email to account manager
→ No: Post to Slack channel
→ Transform (summarize results)
→ Send email (weekly summary to leadership)
```
# Creating a playbook
Source: https://docs.wayak.io/concepts/playbooks/creating-playbooks
How to build an automated workflow in Wayak
This guide walks you through creating a playbook from scratch — defining a trigger, adding steps, and activating it.
## Step 1: Create a new playbook
1. Go to **Playbooks** in the Wayak dashboard
2. Click **New playbook**
3. Give it a name and description
## Step 2: Set a trigger
Choose what kicks off the playbook:
| Trigger type | Description |
| ------------ | --------------------------------------------------------------------------------- |
| **Schedule** | Runs at a set time — daily, weekly, monthly, or custom cron |
| **Event** | Runs when something happens — a new record, a threshold crossed, a sync completed |
| **Manual** | Runs when a user or agent explicitly triggers it |
## Step 3: Add steps
Build the workflow by adding steps in sequence. Each step performs one action:
1. **Data step** — query a data source or search a knowledge base
2. **Logic step** — filter, branch, or loop based on conditions
3. **Skill step** — execute an agent skill
4. **Action step** — send an email, post to Slack, call a webhook, update a record
Steps pass data forward. The output of one step becomes available as input to the next.
## Step 4: Test and activate
1. Click **Test run** to execute the playbook with live data
2. Review the output of each step to verify correctness
3. When satisfied, click **Activate** to put it on its trigger schedule
Activated playbooks run automatically. You can monitor runs, view logs, and pause or edit playbooks at any time from the dashboard.
# What is a playbook?
Source: https://docs.wayak.io/concepts/playbooks/what-is-a-playbook
Automated workflows that chain data, logic, and actions together
A playbook is an automation in Wayak. It defines a sequence of steps that run automatically — triggered by a schedule, an event, or a user request. Playbooks chain together data queries, logic, agent skills, and actions into end-to-end workflows.
![Wayak playbook studio]()
## Playbooks vs. skills
A skill is a single capability — one action the agent can do. A playbook is a full workflow that can use multiple skills, branch on conditions, loop over data, and orchestrate complex processes.
| | Skill | Playbook |
| -------------- | -------------------- | -------------------------------------------------------------------------------------------- |
| **Scope** | Single action | Multi-step workflow |
| **Complexity** | Simple | Can include branching, loops, conditions |
| **Trigger** | Usually user request | Schedule, event, or user request |
| **Example** | "Look up a customer" | "Every Monday, check all overdue invoices, email each customer, and post a summary to Slack" |
## What playbooks can do
* **Query data** from any connected data source
* **Read documents** from knowledge bases
* **Apply logic** — conditions, filters, loops, branching
* **Call skills** — trigger agent capabilities as steps
* **Deliver results** — send emails, post to Slack, update records, call webhooks
## When to use playbooks
Use a playbook when you want something to happen automatically and reliably, without someone having to ask the agent every time. Common examples:
* Weekly reports generated and delivered on Monday morning
* Alerts when a metric crosses a threshold
* Data quality checks that run after every sync
* Onboarding sequences triggered when a new customer is created
# What is Wayak?
Source: https://docs.wayak.io/index
The agentic data and automation platform
Wayak is an agentic data and automation platform. Connect all your company's data, talk to it in plain language, and automate the work that keeps your teams busy.
![Wayak chat interface]()
Databases, APIs, files, documents — bring it all into one place.
Ask questions in plain language. Get answers backed by real data.
Turn repeatable work into automated workflows that run on their own.
***
## How it works
Bring in everything — databases, APIs, spreadsheets, PDFs, internal docs. Wayak connects to your data wherever it lives. Upload a CSV or plug in a data warehouse — it all works the same way.
Define your business metrics, terminology, and relationships in the ontology. The agent learns what "revenue" means, how to calculate churn, and which tables to join — so it answers with the same precision as your best analyst.
Ask questions in plain language and get answers from your actual data. No SQL. No tickets. No waiting for the data team. Just ask.
Build playbooks that generate reports, send alerts, and run workflows on a schedule — so the work gets done without anyone having to ask.
***
## Why Wayak
### Unified data access
Connect every data source your organization uses — databases, APIs, file uploads, and unstructured documents — into one platform. No more switching between tools to get a complete picture.
### Business-grade accuracy
The ontology encodes your business logic so the agent computes metrics, joins tables, and interprets terminology correctly — every time. No hallucinated numbers.
### Agents that act
Wayak agents don't just answer questions. They connect to your tools, execute skills, and work across your entire data estate. Build specialized agents for each team.
### Automation at scale
Playbooks turn repeatable work into automated workflows — reports, alerts, data checks, onboarding flows — running reliably without manual effort.
***
## Explore the platform
Jump right in with a hands-on tutorial.
Connect a data source and ask your first question in minutes.
Walk through a full data conversation from start to finish.
Define metrics, entities, and relationships the agent can use.
Create a playbook that generates and delivers a report on schedule.
Learn how the platform is designed and why.
Databases, APIs, the lakehouse, and knowledge bases.
Objects, metrics, dimensions, and the semantic layer.
Custom agents, skills, and app integrations.
Automated workflows that chain skills and logic together.
Explore how teams in different industries use Wayak.
Production costs, quality, shift performance.
Email drafting, ticket classification, customer insights.
Claims intake, reserves, fraud detection.
Recruiting, onboarding, policy support.
Inventory, promotions, product assortment.
Route optimization, shipment tracking, exceptions.
# Quickstart
Source: https://docs.wayak.io/quickstart
Get your data connected and your first agent conversation running
Get Wayak up and running in three steps: connect a data source, set up a knowledge space, and ask your first question.
***
Start by connecting your first data source. This gives the agent access to your structured data.
1. Navigate to **Data Sources** in the Wayak dashboard
2. Choose your connection type — database, API, or file upload
3. Enter your connection details and test the connection
4. Wayak automatically introspects your schema
![Wayak data upload interface]()
The built-in lakehouse is the fastest way to get started — just drag and drop a CSV or Excel file.
Upload your unstructured documents so the agent can search and read them.
1. Navigate to **Knowledge Spaces** in the dashboard
2. Create a new knowledge space and give it a name
3. Upload your documents (PDFs, reports, presentations, etc.)
4. Wayak indexes the content automatically
Your documents are now searchable by the agent. It can find specific passages, summarize content, and answer questions grounded in your actual docs.
Open the Wayak chat and ask a question about your data. The agent uses your connected data sources, knowledge spaces, and semantic layer to find the answer.
![Wayak chat interface]()
Try something like:
* "What were our top 10 customers by revenue last quarter?"
* "How many new accounts were created this month?"
* "Show me the average order value by region for the past 6 months"
* "Summarize the key points from the Q3 board deck"
* "What does our expense policy say about international travel?"
* "Find any mention of pricing changes in the sales playbook"
* "Break that down by quarter"
* "Which of those customers churned?"
* "Show me a chart instead"
***
## Keep going
Walk through a full data conversation from start to finish.
Define metrics, entities, and relationships the agent can use.
Create a playbook that generates and delivers a report on schedule.
Learn about databases, APIs, the lakehouse, and knowledge bases.
Understand objects, metrics, dimensions, and the semantic layer.
Build custom agents with specific roles, skills, and data access.
Automate workflows that chain skills and logic together.
# Automate a report
Source: https://docs.wayak.io/quickstart/automate-a-report
Schedule the agent to generate and deliver reports on a recurring basis
Once your data is connected and your semantic layer is defined, you can put the agent to work. This guide walks you through setting up an automated report that runs on a schedule and delivers results to your team.
## What you'll do
1. Create a report from a conversation
2. Configure a schedule
3. Set up delivery
## Step 1: Create a report
Start by asking the agent the question you want to automate. Get the answer looking exactly how you want it — this becomes your report template.
1. Open the Wayak chat
2. Ask your question, e.g. "Show me weekly revenue by region for the last 4 weeks, with week-over-week change"
3. Refine until the output is what you'd want delivered to your team
4. Click **Save as report**
5. Give it a name (e.g. "Weekly Revenue by Region")
The agent saves both the question and the output format, so it reproduces the same report structure every time it runs.
## Step 2: Set a schedule
1. Go to **Reports** in the Wayak dashboard
2. Find your saved report and click **Schedule**
3. Choose the frequency:
* **Daily** — runs every day at a set time
* **Weekly** — runs on a specific day and time
* **Monthly** — runs on a specific date
4. Set the time and timezone
5. Click **Save schedule**
The agent runs the report at the scheduled time using live data, so results are always current.
## Step 3: Set up delivery
Configure where the report gets sent when it runs.
1. On the report schedule page, click **Add delivery**
2. Choose a delivery channel:
* **Email** — send to specific recipients or a distribution list
* **Slack** — post to a channel
* **Webhook** — send to any endpoint
3. Configure the recipients or destination
4. Click **Save**
You can add multiple delivery channels to the same report. Send it to Slack for the team and email for leadership.
## Step 4: Verify
Wait for the first scheduled run, or click **Run now** to test immediately. Check that:
* The data is correct and current
* The format matches what you saved
* Delivery arrives at the configured destination
## What's next
You've gone from connecting data to chatting with it to automating reports. Explore the platform concepts to understand how everything fits together.
Understand all the ways to bring data into Wayak.
Deep dive into how the semantic layer works.
# Build your first dashboard
Source: https://docs.wayak.io/quickstart/build-a-dashboard
Create views, arrange them into a dashboard, and share it with your team
You've connected data, chatted with it, and built a semantic layer. Now turn your most important questions into a dashboard your team can check anytime — no need to re-ask the agent.
## What you'll do
1. Create individual views (charts and tables)
2. Assemble them into a dashboard
3. Share it with your team
## Step 1: Create your first view
A view is a single visualization — a chart, table, or KPI card — that answers one specific question.
1. Go to **Views** in the Wayak dashboard
2. Click **New view**
3. Choose what you want to visualize:
Pick a single metric (e.g. "Revenue this month"). Wayak displays it as a headline number with optional comparison to a previous period.
Choose a metric and a dimension to break it down by. For example, "Revenue by region" as a bar chart or "Revenue over time" as a line chart.
Select your chart type:
* **Line** — trends over time
* **Bar** — comparisons across categories
* **Pie** — proportions of a whole
Display detailed rows of data. Useful for top-N lists, recent activity, or any view where users need to scan individual records.
4. Configure filters (e.g. "last 90 days", "active customers only")
5. Name your view and click **Save**
Start with the questions your team asks most often. Each one becomes a view.
## Step 2: Build the dashboard
Now combine your views into a single page.
1. Go to **Dashboards** in the Wayak dashboard
2. Click **New dashboard**
3. Give it a name (e.g. "Sales Performance", "Ops Overview")
4. Click **Add view** and select from your saved views
5. Arrange the layout — drag views to reorder and resize them
A typical dashboard might include:
| Position | View | Type |
| -------- | ----------------------------- | ---------- |
| Top row | Revenue this month | KPI card |
| Top row | New customers this month | KPI card |
| Top row | Active users | KPI card |
| Middle | Revenue over time (12 months) | Line chart |
| Middle | Revenue by region | Bar chart |
| Bottom | Top 10 customers by spend | Table |
6. Click **Save** when you're happy with the layout
## Step 3: Share it
1. On your saved dashboard, click **Share**
2. Choose who gets access:
* **Specific users** — invite by email
* **Team** — share with an entire team
* **Link** — generate a shareable URL
3. Recipients can view the dashboard with live data — it updates automatically as your data changes
## What's next
You now have a live dashboard built on real data and your semantic layer definitions. From here you can:
* Add more views as new questions come up
* Set up a [playbook](/quickstart/automate-a-report) to deliver the dashboard by email or Slack on a schedule
* Explore the [concepts](/concepts/index) to understand the platform in depth
Learn more about how views work under the hood.
Understand dashboard configuration and sharing options.
# Build a semantic layer
Source: https://docs.wayak.io/quickstart/build-semantic-layer
Define your business logic so the agent always gets the right answer
A semantic layer teaches the agent how your business thinks about data. Without one, the agent guesses. With one, it answers like your best analyst. This guide walks you through building your first semantic layer.
## What you'll do
1. Define a business metric
2. Map business terminology to your schema
3. Set up table relationships
4. Test the semantic layer in a conversation
## Step 1: Define a metric
Metrics are the calculations your team cares about — revenue, churn rate, conversion, active users. Start with one.
1. Go to **Semantic Layer** in the Wayak dashboard
2. Click **Add metric**
3. Give it a name your team actually uses (e.g. "Revenue")
4. Define the calculation:
* **Source table** — the table that contains the raw data
* **Aggregation** — how to compute it (SUM, COUNT, AVG, etc.)
* **Column** — the column to aggregate
* **Filters** — any conditions that scope the metric (e.g. `txn_type = 'sale'`)
Name your metrics the way your team talks. If everyone says "MRR" not "monthly recurring revenue," name it "MRR." The agent matches user questions to metric names.
## Step 2: Map your terminology
Your team uses business language. Your database uses column names. The semantic layer bridges the two.
1. Go to **Terminology** in the semantic layer settings
2. Add mappings between business terms and schema objects:
| Business term | Maps to |
| -------------- | ------------------------------------------ |
| "Customers" | `accounts` table where `status = 'active'` |
| "Sales rep" | `users` table where `role = 'sales'` |
| "Last quarter" | Dynamic date filter: previous 3 months |
When someone asks "How many customers do we have?", the agent knows exactly which table and filter to use.
## Step 3: Define table relationships
Tell the agent how your tables connect so it can join them correctly.
1. Go to **Relationships** in the semantic layer settings
2. Add joins between your tables:
* **From table** and **To table**
* **Join key** — the columns that link them
* **Join type** — inner, left, etc.
This prevents the agent from guessing joins or producing incorrect results when questions span multiple tables.
## Step 4: Test it
Open the Wayak chat and ask a question that uses your new metric or terminology.
* "What's our revenue this month?" — should use your defined Revenue metric
* "How many customers signed up last quarter?" — should use your Customers terminology mapping
* "Revenue by sales rep" — should join tables using your defined relationships
If the answer matches what you expect, your semantic layer is working. If not, refine the definitions and test again.
## What's next
Your agent now understands your business logic. Next, turn your most important questions into a dashboard.
Create views, arrange them into a dashboard, and share it with your team.
# Chat with your data
Source: https://docs.wayak.io/quickstart/chat-with-your-data
Connect a data source and start asking questions in minutes
This guide walks you through connecting your first data source and having a conversation with your data. By the end, you'll have an agent answering real questions from your own databases and files.
## What you'll do
1. Connect a data source to Wayak
2. Ask the agent a question about your data
3. Explore follow-up queries and drill into results
## Step 1: Connect a data source
1. Go to **Data Sources** in the Wayak dashboard
2. Click **Add data source** and select your database type
3. Enter your connection credentials (host, port, database, user, password)
4. Click **Test connection** to verify
5. Click **Connect**
Wayak reads your schema automatically. You'll see your tables and columns listed once the connection is established.
1. Go to **Data Sources** in the Wayak dashboard
2. Click **Add data source** and select **File upload**
3. Drag and drop a CSV or Excel file
4. Wayak parses the file and creates a queryable table
This is the fastest way to get started if you don't have a database ready. Any spreadsheet works.
## Step 2: Ask your first question
Open the Wayak chat and type a question in plain language. The agent figures out which tables to query, builds the right query, and returns the answer.
Try questions like:
* "How many rows are in \[your table name]?"
* "What are the top 10 records by \[a numeric column]?"
* "Show me a breakdown of \[column A] grouped by \[column B]"
The agent responds with the answer and shows you the query it ran, so you can verify the logic.
## Step 3: Go deeper
Once you get your first answer, keep going. The agent maintains context across the conversation, so you can:
* **Drill down** — "Now filter that to just the last 30 days"
* **Compare** — "How does that compare to the previous quarter?"
* **Pivot** — "Break that down by region instead"
* **Export** — "Give me that as a table I can copy"
Each follow-up builds on the previous answer. You're having a conversation with your data, not writing one-off queries.
## What's next
You've connected data and started chatting. To get more accurate and consistent answers, define a semantic layer that teaches the agent your business logic.
Teach the agent your metrics, terminology, and table relationships.
# Customer history lookup
Source: https://docs.wayak.io/use-cases/customer-service/customer-history-lookup
Consolidate a customer's interactions, open tickets, and account details into a single profile
When a customer contacts support, the agent handling the case needs context fast. But that context is scattered across systems — the CRM has account details, the helpdesk has ticket history, the billing system has invoices, and the email system has recent correspondence. Switching between tabs to piece together a customer profile wastes time and leads to missed details that frustrate the customer ("I already explained this to someone last week").
This use case creates an agent that resolves a customer's identity across your data sources and presents a unified profile in seconds. Ask "Tell me about customer Acme Corp" and you get their account tier, recent tickets, open issues, lifetime value, and any special agreements — all in one response.
***
## What you need
* **CRM system** — Customer accounts, contacts, contract terms, and purchase history
* **Helpdesk system** — Ticket history, interaction logs, CSAT scores, and SLA records
* **Billing system** — Invoice history, payment status, and outstanding balances
* **Customer agreements** — Upload special terms, SLA amendments, and negotiated policies for key accounts
* **Account management playbook** — Internal guidelines for handling VIP, enterprise, and at-risk accounts
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------------- | --------------------------------------------------------------------------------------------------------- |
| Object | Customer | Maps to the CRM account table. Represents a customer entity with contact info, tier, and contract details |
| Object | Interaction | Maps to helpdesk interaction logs. Represents a single touchpoint: ticket, call, email, or chat |
| Metric | Lifetime Value | Total revenue from a customer account across all invoices |
| Metric | Average Resolution Time | Mean time to resolve tickets for a specific customer, in hours |
| Dimension | Account Tier | Segments customers as enterprise, business, or standard |
| Dimension | Channel | Categorizes interactions by channel: email, phone, chat, social |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------ |
| **Name** | Customer Context Agent |
| **Role** | Customer intelligence specialist |
| **Goal** | Provide instant, comprehensive customer profiles to support agents |
> You provide instant customer profiles to support agents. When asked about a customer, start with the account basics (tier, contract status, lifetime value), then list open tickets and recent interactions. Highlight anything unusual: recent escalations, overdue invoices, or expiring contracts. If the customer has a special agreement in the knowledge space, mention it prominently. Keep the profile concise but complete — the goal is to give the support agent everything they need in one view without requiring follow-up questions.
Grant access to:
* CRM system data source (accounts, contacts, contracts)
* Helpdesk system data source (tickets and interactions)
* Billing system data source (invoices and payments)
* Customer agreements knowledge space
* Account management playbook knowledge space
* Customer and Interaction objects in the semantic layer
**Trigger:** User asks about a specific customer or before handling a ticket
1. Look up the customer by name, email, or account ID across CRM, helpdesk, and billing systems.
2. Pull account details: tier, contract status, account manager, and lifetime value.
3. Retrieve the last 10 interactions from the helpdesk (tickets, calls, emails).
4. Summarize: total tickets, open tickets, average resolution time, and most common issue type.
5. Note any VIP status, special agreements from the knowledge space, or past escalations.
6. Check for overdue invoices or expiring contracts that might affect the current interaction.
7. Present as a brief profile with a timeline of recent interactions.
**Trigger:** User asks how a customer compares to others or whether their experience is typical
1. Identify the customer's account tier and segment.
2. Pull aggregate metrics for that segment: average ticket volume, average resolution time, average CSAT.
3. Compare the individual customer's metrics against the segment averages.
4. Highlight any metric where the customer is more than one standard deviation from the average.
5. Present a comparison table with the customer's numbers alongside segment benchmarks.
***
## Automation
### Playbook: Pre-populate ticket context
Set the playbook to trigger when a ticket is assigned to an agent.
The playbook automatically pulls the customer profile and attaches it to the ticket as an internal note, so the agent has context before they even open the conversation.
1. **Query step** — Pull the customer email from the ticket and look them up in the CRM.
2. **Query step** — Pull the customer's last 5 tickets and their outcomes from the helpdesk.
3. **Query step** — Check for overdue invoices or expiring contracts in the billing system.
4. **Format step** — Compile a concise customer profile: account tier, lifetime value, open issues, recent interactions, and any flags.
5. **Action step** — Post the profile as an internal note on the ticket.
The profile is posted directly to the ticket as an internal note. No additional delivery channel is needed.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Identify systemic issues driving repeated escalations and recommend fixes.
See the full list.
# Email reply drafting
Source: https://docs.wayak.io/use-cases/customer-service/email-reply-drafting
Draft context-aware customer email replies that follow your brand voice and resolve issues faster
Drafting quality email replies is one of the most time-consuming tasks in customer service. Each response requires reading the incoming message, understanding the issue, checking customer history, referencing the right policy, and writing in a consistent brand voice. Even experienced agents spend 5-10 minutes per reply. Multiply that across hundreds of daily emails and you have a team that spends more time writing than solving.
This use case gives your support team an agent that reads incoming emails, pulls relevant customer history and policy information, and drafts a reply ready for human review. The agent follows your brand voice guidelines from the knowledge space and flags any email that requires escalation instead of a standard response.
***
## What you need
* **Helpdesk system (Zendesk, Freshdesk, or similar)** — Ticket records with email threads, status, and assigned agent
* **CRM system** — Customer account details, contract status, and purchase history
* **Brand voice guidelines** — Upload your tone guide, approved phrases, and language to avoid
* **Email templates** — Standard response templates for common issue types (billing, shipping, returns, technical)
* **Refund and credit policies** — Upload your current policies so the agent can reference them accurately
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Object | Ticket | Maps to the helpdesk ticket table. Represents a customer issue with status, category, and full conversation thread |
| Object | Customer | Maps to the CRM account table. Represents a customer with contact info, account tier, and history |
| Metric | First Response Time | Minutes between ticket creation and the first agent reply |
| Metric | Customer Lifetime Value | Total revenue from a customer's account, used to prioritize high-value customers |
| Dimension | Issue Type | Categorizes tickets as billing, technical, shipping, returns, account, or general inquiry |
| Dimension | Customer Tier | Segments customers by account level: enterprise, business, standard |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | -------------------------------------------------- |
| **Name** | Support Rep |
| **Role** | Customer service specialist |
| **Goal** | Resolve customer issues quickly and empathetically |
> You are a customer support specialist. Always greet the customer by name when available. Use a warm, professional tone. Acknowledge the customer's frustration before jumping to a solution. Keep responses concise — no more than three paragraphs. If you cannot resolve an issue, escalate clearly and explain what happens next. Never promise refunds or credits without confirming the policy first.
Grant access to:
* Helpdesk system data source (ticket records and email threads)
* CRM system data source (customer accounts and purchase history)
* Brand voice guidelines knowledge space
* Email templates knowledge space
* Refund and credit policies knowledge space
* Ticket and Customer objects in the semantic layer
**Trigger:** User asks to draft a reply or a new support email arrives
1. Read the incoming email and identify the issue type (billing, technical, shipping, returns, account, general inquiry).
2. Check the customer's history in the CRM for prior interactions, open tickets, and account tier.
3. Pull the relevant email template from the knowledge space based on the issue type.
4. Draft a reply that acknowledges the issue, provides a clear next step, and sets expectations for resolution time.
5. Match the company's tone guidelines from the brand voice knowledge space: professional, empathetic, concise.
6. If the issue requires internal action (refund, escalation, engineering ticket), note it separately as an internal comment.
7. Present the draft for review before sending.
**Trigger:** Customer requests a refund or credit
1. Identify the customer and order from the email or ticket context.
2. Pull the order details from the CRM, including purchase date, amount, and item.
3. Check the refund policy from the knowledge space for the applicable time window and conditions.
4. Determine eligibility: within policy (approve), outside policy (deny with reason), or edge case (escalate).
5. Draft the appropriate response, citing the specific policy clause.
***
## Automation
### Playbook: Auto-draft for new emails
Set the playbook to trigger on a new inbound email event from the helpdesk system.
The playbook reads the incoming email, classifies it, pulls context, and generates a draft reply saved back to the ticket.
1. **Query step** — Pull the email content and any existing ticket context from the helpdesk.
2. **Query step** — Look up the customer in the CRM by email address to get account details and history.
3. **AI step** — Classify the issue type and generate a draft reply following the brand voice guidelines.
4. **Condition step** — If the issue type is "legal" or "data privacy," skip the draft and route directly to the legal queue.
5. **Action step** — Save the draft reply as an internal note on the ticket for agent review.
The draft is saved directly to the helpdesk ticket. Send a Slack notification to the assigned agent's channel letting them know a draft is ready for review.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Automatically categorize and prioritize tickets the moment they arrive.
See the full list.
# Escalation pattern analysis
Source: https://docs.wayak.io/use-cases/customer-service/escalation-pattern-analysis
Identify systemic issues driving repeated escalations and recommend process fixes
Escalations are not just individual customer problems — they are signals. When the same type of issue gets escalated repeatedly, it points to a systemic failure: a confusing billing page, a recurring product bug, a policy gap, or inadequate agent training. But spotting these patterns manually means exporting ticket data, building pivot tables, and hoping someone has time to analyze the results. Most teams only review escalations reactively, one at a time.
This use case deploys an agent that analyzes escalated tickets across time, category, and root cause. A monthly playbook uses Python to run trend analysis on escalation data, group by root cause, quantify the impact, and deliver a report with recommended actions. You move from fighting individual fires to fixing the systems that cause them.
***
## What you need
* **Helpdesk system** — Ticket records with escalation flags, escalation reason codes, resolution notes, and timestamps
* **CRM system** — Customer account data to identify whether escalations cluster around specific segments or tiers
* **Escalation policies** — Upload your escalation criteria, SLA definitions, and routing rules
* **Product known issues** — Documented bugs, workarounds, and planned fixes so the agent can cross-reference escalations against known problems
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Object | Escalated Ticket | Maps to helpdesk tickets with escalation flag set to true. Represents an issue that exceeded frontline resolution |
| Object | Resolution | Maps to ticket resolution records. Includes resolution type, time, and agent notes |
| Metric | Escalation Rate | Escalated tickets divided by total tickets, as a percentage, over a given period |
| Metric | Mean Time to Escalation | Average minutes between ticket creation and escalation event |
| Dimension | Root Cause | Groups escalations by underlying reason: product bug, policy gap, training gap, process failure |
| Dimension | Product Area | Associates escalations with a specific product or feature |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------ |
| **Name** | Escalation Analyst |
| **Role** | Escalation and root-cause specialist |
| **Goal** | Identify patterns in escalated tickets and recommend process fixes |
> You analyze escalated support tickets. Focus on identifying systemic issues — recurring product bugs, confusing documentation, or policy gaps. When presenting findings, group by root cause category and quantify impact (number of tickets, average resolution time, estimated cost). Use a neutral, analytical tone. Always include a recommended action for each pattern you identify. Cross-reference escalations against the known issues list and note when a pattern matches a documented bug.
Grant access to:
* Helpdesk system data source (ticket records with escalation data)
* CRM system data source (customer segments)
* Escalation policies knowledge space
* Product known issues knowledge space
* Escalated Ticket and Resolution objects in the semantic layer
**Trigger:** User asks about escalation trends, root causes, or systemic issues
1. Identify the time range from the user's request, defaulting to the last 30 days.
2. Pull all escalated tickets for that period with their reason codes and resolution notes.
3. Group escalations by root cause category and count occurrences.
4. Rank root cause categories by frequency, with the highest first.
5. For the top three categories, calculate average resolution time and identify the most common product area.
6. Cross-reference against the product known issues knowledge space to flag matches.
7. Present a summary table with root cause, count, percentage of total escalations, average resolution time, and recommended action.
**Trigger:** User asks whether escalation rates vary by customer type or segment
1. Pull escalated tickets and total tickets for the specified period.
2. Join with CRM data to get customer tier and segment.
3. Calculate escalation rate for each segment.
4. Identify segments with escalation rates significantly above the overall average.
5. Present a comparison table with segment, total tickets, escalated tickets, escalation rate, and deviation from average.
***
## Automation
### Playbook: Monthly escalation trend report
Schedule the playbook to run on the first business day of each month at 8:00 AM.
The playbook analyzes the previous month's escalation data, identifies trends, and generates a report for leadership.
1. **Query step** — Pull all escalated tickets from the previous calendar month with reason codes, resolution data, and timestamps.
2. **Query step** — Pull the same data for the month before that (for trend comparison).
3. **Python code step** — Group escalations by root cause, calculate month-over-month change, and run a trend analysis to identify categories that are increasing.
4. **Python code step** — Calculate the estimated cost impact by multiplying escalation count by average handle time and agent cost per hour.
5. **Format step** — Build the report with three sections: overall escalation rate trend, top root causes with month-over-month change, and estimated cost impact.
The **Python code steps** use Python code blocks to compute trend analysis (percentage change, moving averages) and cost impact estimates. You can customize the agent cost-per-hour variable and add additional statistical measures.
Send the report via email to the VP of Customer Experience and Support team leads. Include the overall escalation rate and trend direction in the subject line.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Track response and resolution times and catch at-risk tickets before they breach.
See the full list.
# Customer service
Source: https://docs.wayak.io/use-cases/customer-service/index
Draft replies, classify tickets, and uncover escalation patterns with AI agents
Customer service teams are under constant pressure to respond faster, resolve on first contact, and maintain quality across every channel. The data they need — customer history, ticket context, brand guidelines, SLA timers — lives in separate systems that are slow to navigate. Every minute an agent spends searching for information is a minute a customer spends waiting.
Wayak connects your helpdesk, CRM, and knowledge bases into a unified layer that agents can query instantly. AI agents draft replies that follow your brand voice, classify incoming tickets automatically, and surface escalation patterns your team would otherwise miss. Playbooks automate the monitoring work — SLA tracking, trend analysis, ticket routing — so your team focuses on the conversations that matter.
## Use cases
Read incoming emails, detect the issue type, and draft context-aware responses that follow your tone guidelines.
Automatically categorize, prioritize, and tag new tickets the moment they arrive in your helpdesk.
Consolidate a customer's interactions, open tickets, and account details into a single profile in seconds.
Identify systemic issues driving repeated escalations and recommend process fixes backed by data.
Track response and resolution times against targets and flag at-risk tickets before they breach.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Data sources | Helpdesk system (tickets, interactions, SLA timers), CRM (customer accounts, contacts, contract details), email system (inbound/outbound messages) |
| Knowledge spaces | Brand voice guidelines, email templates, product FAQ documents, escalation policies, refund and credit policies |
| Semantic layer | Objects for tickets, customers, and interactions. Metrics for first response time, resolution time, CSAT score, and escalation rate. Dimensions for category, priority, channel, and agent |
| Agents | Support Rep for customer-facing interactions and reply drafting. Escalation Analyst for pattern identification and root-cause analysis |
| Playbooks | Event-triggered ticket classification, scheduled SLA monitoring scans, monthly escalation trend reports |
# SLA monitoring
Source: https://docs.wayak.io/use-cases/customer-service/sla-monitoring
Track response and resolution times against targets and flag at-risk tickets before they breach
SLA breaches damage customer trust and often trigger financial penalties in B2B contracts. The problem is not that teams ignore SLAs — it is that they only find out about a breach after it happens. By the time a manager notices a ticket has been open for 23 hours against a 24-hour SLA, there is almost no time to act. A proactive system that flags tickets approaching their deadlines gives your team the window they need to prevent breaches, not just report them.
This use case deploys a scheduled playbook that scans open tickets every hour, calculates time remaining against SLA targets, and alerts the team about tickets at risk of breaching. Python code handles the time calculations, accounting for business hours, weekends, and holidays. Tickets within 2 hours of their SLA deadline trigger an urgent Slack alert.
***
## What you need
* **Helpdesk system** — Open tickets with creation timestamps, first response timestamps, priority levels, and SLA policy assignments
* **CRM system** — Customer contract details with SLA terms (response time, resolution time by priority)
* **SLA policy definitions** — Upload your SLA tiers with response and resolution targets by priority and customer tier
* **Business hours calendar** — Upload your support team's working hours, holidays, and timezone rules
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------- | ----------------------------------------------------------------------------------------------- |
| Object | Ticket | Maps to the helpdesk ticket table. Represents an open support request with SLA timer data |
| Object | SLA Policy | Maps to SLA configuration records. Defines response and resolution targets by priority and tier |
| Metric | Time to SLA Breach | Business hours remaining until the ticket's SLA deadline, calculated in real time |
| Metric | SLA Compliance Rate | Percentage of tickets resolved within their SLA target over a given period |
| Dimension | Priority | Ticket priority: critical (1-hour response), high (4-hour), medium (8-hour), low (24-hour) |
| Dimension | SLA Status | Current SLA state: on track, at risk (less than 2 hours remaining), breached |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ---------------------------------------------------------------------------- |
| **Name** | SLA Monitor |
| **Role** | SLA compliance analyst |
| **Goal** | Prevent SLA breaches by tracking deadlines and alerting the team proactively |
> You monitor SLA compliance across all open tickets. When asked about SLA status, always show tickets closest to breaching first. Calculate time remaining in business hours, not calendar hours. For each at-risk ticket, show the ticket number, customer, priority, SLA target, time remaining, and assigned agent. If a ticket has already breached, note it clearly and recommend immediate action. Use precise timestamps and never round time remaining — 1 hour 42 minutes, not "about 2 hours."
Grant access to:
* Helpdesk system data source (open tickets with timestamps)
* CRM system data source (customer contracts with SLA terms)
* SLA policy definitions knowledge space
* Business hours calendar knowledge space
* Ticket and SLA Policy objects in the semantic layer
**Trigger:** User asks about SLA compliance or at-risk tickets
1. Pull all open tickets with their creation timestamps, first response timestamps, and assigned SLA policies.
2. Look up the SLA target for each ticket based on its priority and the customer's contract tier.
3. Calculate elapsed business hours since ticket creation, accounting for business hours, weekends, and holidays.
4. Compute time remaining until the SLA deadline for each ticket.
5. Classify each ticket as on track, at risk (less than 2 hours remaining), or breached.
6. Sort by time remaining, shortest first, and present a table with ticket number, customer, priority, SLA target, elapsed time, time remaining, and status.
**Trigger:** User asks for an SLA compliance summary or performance report
1. Pull all tickets closed in the specified period.
2. Determine whether each ticket was resolved within its SLA target.
3. Calculate the overall SLA compliance rate as a percentage.
4. Break down compliance by priority level and customer tier.
5. Identify the top three reasons for SLA breaches from resolution notes.
6. Present a summary with compliance rate, breakdown table, and recommendations.
***
## Automation
### Playbook: Hourly SLA scan
Schedule the playbook to run every hour during business hours (e.g., 8:00 AM to 8:00 PM on weekdays).
The playbook scans all open tickets, calculates SLA time remaining, and alerts the team about at-risk tickets.
1. **Query step** — Pull all open tickets with creation timestamps, priorities, and SLA policy assignments.
2. **Python code step** — Calculate business hours elapsed and time remaining for each ticket. Account for the business hours calendar (working hours, weekends, holidays). Classify each ticket as on track, at risk, or breached.
3. **Condition step** — Filter to tickets that are at risk (less than 2 hours remaining) or already breached.
4. **Format step** — Build an alert message with ticket number, customer name, priority, time remaining, and assigned agent.
The **Python code step** uses a Python code block to compute business-hours elapsed time, factoring in your working hours schedule, weekends, and holidays. You can customize the at-risk threshold (default 2 hours) and the business hours definition.
Send at-risk ticket alerts to the #support-sla Slack channel. For breached tickets, also send a direct message to the assigned agent's manager with the ticket details and recommended action.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Draft context-aware customer replies that match your brand voice.
See the full list.
# Ticket classification
Source: https://docs.wayak.io/use-cases/customer-service/ticket-classification
Automatically categorize, prioritize, and tag incoming support tickets in real time
Manual ticket classification is slow, inconsistent, and prone to error. One agent tags a billing question as "account," another tags the same issue as "payment." Priorities get assigned based on gut feel rather than data. The result is misrouted tickets, unreliable reporting, and SLA breaches that could have been prevented with accurate triage.
This use case deploys an event-triggered playbook that classifies every new ticket the moment it arrives. The playbook reads the ticket subject and body, assigns a category, priority, and product tag, and updates the record in your helpdesk — all without human intervention. Edge cases like legal mentions or data privacy concerns get auto-escalated to the right queue.
***
## What you need
* **Helpdesk system** — Ticket records with subject, body, status, tags, and priority fields that can be written back via API
* **CRM system** — Customer account details for priority context (enterprise customers may receive elevated priority)
* **Classification taxonomy** — Upload your category definitions, priority criteria, and product/feature area list
* **Escalation policies** — Rules for when a ticket should bypass normal triage (legal, security, VIP)
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------------- | ---------------------------------------------------------------------------------------------------- |
| Object | Ticket | Maps to the helpdesk ticket table. Represents a support request with category, priority, and tags |
| Object | Customer | Maps to the CRM account table. Includes account tier for priority elevation rules |
| Metric | Classification Accuracy | Percentage of auto-classified tickets where the category was not changed by an agent within 24 hours |
| Metric | Triage Time | Seconds between ticket creation and classification completion |
| Dimension | Category | Predefined categories: billing, technical, shipping, returns, account, other |
| Dimension | Priority | Low (informational), medium (action needed), high (revenue impact or SLA risk) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------ |
| **Name** | Ticket Triage Agent |
| **Role** | Support ticket classification specialist |
| **Goal** | Accurately classify and route every incoming ticket within seconds |
> You classify incoming support tickets. Read the subject and body carefully. Assign exactly one category from the approved taxonomy — never invent new categories. Set priority based on business impact: high if there is revenue at risk or an SLA in danger, medium if action is required, low if informational. Tag with the relevant product or feature area. If the ticket mentions legal action, compliance, or data privacy, auto-escalate to the legal queue regardless of other classifications. Be consistent — the same type of issue should always get the same classification.
Grant access to:
* Helpdesk system data source (ticket records)
* CRM system data source (customer accounts for tier-based priority)
* Classification taxonomy knowledge space
* Escalation policies knowledge space
* Ticket and Customer objects in the semantic layer
**Trigger:** New ticket created in the helpdesk
1. Read the ticket subject and body text.
2. Classify the ticket into one of the predefined categories: billing, technical, shipping, returns, account, or other.
3. Check the customer's account tier in the CRM — elevate priority for enterprise accounts.
4. Assign a priority: low (informational), medium (action needed), or high (revenue impact or SLA risk).
5. Tag the ticket with the relevant product or feature area.
6. If the ticket mentions legal action, compliance, or data privacy, override all other assignments and route to the legal queue.
7. Update the ticket record in the helpdesk with category, priority, and tags.
**Trigger:** Ticket receives a new customer reply that changes the nature of the issue
1. Read the new customer reply in the context of the full ticket thread.
2. Determine if the issue type has changed from the original classification.
3. If the issue has shifted, update the category and priority accordingly.
4. Add an internal note explaining the reclassification reason.
5. If the new priority is higher than the original, notify the assigned agent.
***
## Automation
### Playbook: Real-time ticket classification
Set the playbook to trigger on a new ticket creation event from the helpdesk system API.
The playbook reads the new ticket, classifies it, and updates the helpdesk record — all within seconds of ticket creation.
1. **Query step** — Pull the new ticket's subject, body, and customer email.
2. **Query step** — Look up the customer in the CRM by email to get account tier.
3. **AI step** — Classify the ticket using the taxonomy from the knowledge space. Output: category, priority, product tag.
4. **Condition step** — If keywords match the escalation policy (legal, compliance, data privacy), route to the legal queue.
5. **Action step** — Write the category, priority, and tags back to the helpdesk ticket via API.
No separate delivery needed — the ticket is updated in place. For high-priority tickets, send a Slack notification to the #support-urgent channel with the ticket number and category.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Pull a complete customer profile from CRM and helpdesk data in seconds.
See the full list.
# Asset health monitoring
Source: https://docs.wayak.io/use-cases/energy/asset-health-monitoring
Track equipment condition scores from sensor data and alert maintenance teams before failures occur
Unplanned equipment failures in energy infrastructure are costly — both financially and in terms of service reliability. Transformers, turbines, switchgear, and distribution lines degrade over time, but the warning signs are often buried in SCADA readings and IoT sensor streams that nobody monitors continuously. By the time a failure occurs, the damage is done: outages, safety incidents, and expensive emergency repairs.
Wayak connects your SCADA and IoT data, computes equipment health scores using Python-based degradation models in a playbook, and delivers real-time alerts when assets trend toward failure. An agent gives maintenance engineers instant access to any asset's condition history, trend analysis, and recommended maintenance actions.
***
## What you need
* **SCADA system** — real-time and historical sensor readings (temperature, load, oil levels, vibration), alarm events, and equipment status
* **IoT platform** — supplementary sensor data from field-deployed devices (ambient temperature, humidity, corrosion sensors)
* **CMMS (maintenance system)** — maintenance work orders, service history, inspection records, and spare parts inventory
* **Equipment maintenance manuals** — upload manufacturer specifications, recommended maintenance intervals, and failure mode documentation for each asset class
* **Operating procedures** — upload condition-based maintenance policies, criticality rankings, and escalation protocols
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Object | Asset | Maps to the `assets` table in the CMMS. Represents a physical piece of equipment (transformer, breaker, turbine) |
| Object | Sensor Reading | Maps to `readings` in the SCADA system. Represents a timestamped measurement from a single sensor point |
| Metric | Health Score | Composite score (0-100) calculated from normalized sensor readings weighted by criticality, where 100 is perfect condition |
| Metric | Mean Time Between Failures (MTBF) | Average operating hours between failure events for an asset class, computed from maintenance history |
| Dimension | Asset Type | Categorizes assets by equipment class (transformer, circuit breaker, turbine, distribution line) |
| Dimension | Criticality | Ranks assets as critical, high, medium, or low based on service impact and replacement cost |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Asset Health Analyst |
| **Role** | Equipment Condition Monitoring Specialist |
| **Goal** | Monitor equipment health scores, identify degradation trends, provide maintenance recommendations, and answer ad-hoc queries about asset condition |
> You are an equipment condition monitoring specialist who interprets SCADA and IoT sensor data to assess asset health. You track degradation trends, compare current readings against manufacturer thresholds, and recommend maintenance actions based on condition-based policies. You prioritize assets by criticality and service impact. You present findings with supporting sensor data and reference maintenance manuals when recommending interventions. You never dispatch crews — you provide the evidence maintenance planners need.
Grant access to:
* SCADA system (sensor readings, alarm events, equipment status)
* IoT platform (supplementary sensor data)
* CMMS (work orders, service history, inspection records)
* Equipment maintenance manuals knowledge space
* Operating procedures knowledge space
* Asset and Sensor Reading objects, Health Score and MTBF metrics
**Trigger:** User asks the agent for the condition of a specific asset or asset group.
1. Retrieve the asset record from the CMMS, including type, criticality, installation date, and last service date.
2. Pull the latest sensor readings from the SCADA system (temperature, load, oil level, vibration as applicable).
3. Compute the current health score using the weighted composite formula from the semantic layer.
4. Compare current readings against manufacturer thresholds from the equipment maintenance manuals knowledge space.
5. Pull the asset's maintenance history and calculate MTBF.
6. Return a condition report with the health score, individual sensor readings vs. thresholds, trend direction, and recommended next action.
**Trigger:** User asks about the trend or trajectory of an asset's condition.
1. Retrieve 90 days of sensor reading history for the specified asset from the SCADA system.
2. Calculate the rate of change for each key sensor parameter (e.g., temperature rising at 0.5 degrees per week).
3. Project the time to threshold breach at the current degradation rate.
4. Compare the degradation pattern against known failure modes from the equipment maintenance manuals.
5. Return a trend analysis with the projected failure window, confidence level, and recommended preventive action with timing.
**Trigger:** User asks for a summary of health across all assets or a specific asset class.
1. Query the CMMS for all assets of the specified type or in the specified region.
2. Pull the latest health scores from the most recent scan.
3. Rank assets from worst to best health score.
4. Identify assets with scores below the maintenance threshold or trending downward.
5. Return a fleet summary table with asset name, location, health score, trend, and priority ranking.
***
## Automation
### Playbook: Daily asset health scan
Set the trigger to **Schedule — Daily** at 5:00 AM, before the day shift begins, to give maintenance planners an updated view of asset condition.
The workflow computes health scores for all monitored assets and alerts on degradation:
1. **Query** all active assets from the CMMS with their criticality level and sensor point mappings.
2. **Query** the latest 24 hours of sensor readings from the SCADA system and IoT platform for each asset.
3. **Python code block** — compute the health score for each asset. The code normalizes each sensor reading against its manufacturer-specified operating range, applies criticality-based weights, and produces a composite score on a 0-100 scale. Assets scoring below 60 are flagged as "degraded," and those below 40 as "critical." The code also calculates the 7-day trend (improving, stable, or declining).
The **health score computation** step uses a Python code block to normalize sensor readings, apply weighted scoring, and detect degradation trends. You can customize the scoring thresholds, sensor weights, and trend detection window.
4. **Condition** — if any asset is flagged as "critical," generate an immediate alert with the asset details and recommended maintenance action.
5. **Loop** — for each "degraded" asset, check the CMMS for any open work orders. If no work order exists, create a new maintenance request.
6. **Delivery** — distribute the daily health report.
* **Email** — send the full daily health report to the maintenance planning team
* **Slack** — post critical asset alerts to `#maintenance-urgent` immediately
* **Email escalation** — if any critical-criticality asset scores below 40, notify the Operations Director
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Forecast energy demand using historical meter data and weather patterns for better generation planning.
See the full list.
# Demand forecasting
Source: https://docs.wayak.io/use-cases/energy/demand-forecasting
Forecast energy demand using historical consumption data and weather patterns for optimized generation and grid balancing
Accurate demand forecasting is the foundation of efficient grid operations. Over-forecasting leads to excess generation costs and wasted fuel. Under-forecasting risks brownouts, expensive spot-market purchases, and grid instability. Traditional forecasting methods rely on static models and manual adjustments, which struggle to account for changing weather patterns, seasonal shifts, and evolving customer behavior.
Wayak runs a Python-based forecasting model inside a playbook that combines historical meter data with weather API feeds to produce daily and weekly demand projections. An agent lets grid operators query forecasts conversationally, drill into specific zones or time periods, and understand what is driving the forecast — so they can make informed dispatch decisions.
***
## What you need
* **Meter data management system** — historical consumption readings at 15-minute or hourly intervals, aggregated by zone, feeder, and customer class
* **Weather API** — temperature, humidity, wind speed, cloud cover, and precipitation forecasts (hourly and daily)
* **Operations database** — generation schedules, planned outages, and demand response event history
* **Forecasting methodology** — upload your forecasting model documentation, including variable definitions, seasonal adjustment rules, and accuracy targets
* **Rate schedules and tariffs** — upload current rate structures that influence demand patterns (time-of-use pricing, demand charges)
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
| Object | Meter Zone | Maps to the `zones` table in the meter data management system. Represents a geographic or electrical grouping of meters |
| Object | Forecast | Maps to `forecasts` in the operations database. Represents a predicted demand value for a zone and time period |
| Metric | Peak Demand | Maximum hourly demand in MW for a zone or the entire system, measured over a rolling 24-hour window |
| Metric | Forecast Accuracy (MAPE) | Mean Absolute Percentage Error between forecasted and actual demand, calculated daily |
| Dimension | Customer Class | Groups consumption by customer type (residential, commercial, industrial, municipal) |
| Dimension | Zone | Groups meters and demand by geographic or electrical zone |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Name** | Grid Operations Analyst |
| **Role** | Demand Forecasting Specialist |
| **Goal** | Provide demand forecasts by zone and time period, explain forecast drivers, and assess forecast accuracy against actuals |
> You are a demand forecasting specialist who combines historical consumption patterns with weather data to project energy demand. You explain forecast results clearly — identifying the key drivers (temperature, day of week, season, special events) behind each projection. You compare forecasts against actuals to track accuracy and flag when model performance degrades. You support grid operators with the data they need for dispatch decisions but do not make dispatch recommendations directly.
Grant access to:
* Meter data management system (consumption readings, zone aggregations)
* Weather API (forecasts and historical weather data)
* Operations database (generation schedules, demand response events)
* Forecasting methodology knowledge space
* Rate schedules and tariffs knowledge space
* Meter Zone and Forecast objects, Peak Demand and Forecast Accuracy metrics
**Trigger:** User asks for the demand forecast for a specific zone, time period, or the entire system.
1. Retrieve the latest forecast data for the requested zone and time period from the operations database.
2. Pull the weather forecast for the same period from the weather API.
3. Identify the primary drivers of the forecast (temperature sensitivity, day-of-week pattern, seasonal trend).
4. Compare the forecast to the same period in the prior year for context.
5. Return the forecast values (hourly or daily), peak demand expected, key drivers, and year-over-year comparison.
**Trigger:** User asks about forecast accuracy or model performance.
1. Retrieve the forecasted and actual demand values for the requested period from the operations database and meter data system.
2. Calculate MAPE and identify the hours or days with the largest forecast errors.
3. Correlate the largest errors with weather forecast misses or unexpected events (e.g., unplanned outages, demand response activations).
4. Compare current accuracy against the accuracy target from the forecasting methodology knowledge space.
5. Return an accuracy summary with MAPE, error distribution, root causes for large misses, and trend over time.
**Trigger:** User asks how weather is affecting or will affect demand.
1. Retrieve the current and forecasted weather conditions from the weather API.
2. Query historical demand data for similar weather conditions from the meter data management system.
3. Estimate the demand impact of the weather event (e.g., a heat wave increases residential cooling load by X MW).
4. Identify the zones and customer classes most affected.
5. Return a weather impact assessment with estimated demand change, affected zones, and historical comparisons.
***
## Automation
### Playbook: Daily demand forecast generation
Set the trigger to **Schedule — Daily** at 4:00 AM, providing grid operators with updated forecasts before the morning load ramp.
The workflow generates 48-hour demand forecasts for all zones and flags any expected peaks:
1. **Query** the meter data management system for the most recent 30 days of hourly consumption data by zone and customer class.
2. **Query** the weather API for the 48-hour hourly forecast (temperature, humidity, wind speed, cloud cover).
3. **Python code block** — run the demand forecasting model. The code uses a combination of historical load patterns, temperature regression coefficients, and day-of-week/holiday adjustments to produce hourly demand projections for each zone. It also calculates the expected system peak and the probability of exceeding the seasonal peak record.
The **forecasting model** step uses a Python code block to combine weather-adjusted regression with historical load patterns. You can customize the temperature sensitivity coefficients, holiday calendars, and peak probability thresholds.
4. **Condition** — if the forecasted peak exceeds 90% of system capacity, flag a peak warning.
5. **Action** — write the forecast values to the `forecasts` table in the operations database for downstream consumption.
6. **Delivery** — distribute the forecast report.
* **Email** — send the full 48-hour forecast report to the grid operations team
* **Slack** — post a summary to `#grid-ops` with today's expected peak, tomorrow's expected peak, and any peak warnings
* **Email escalation** — if a peak warning is triggered, notify the VP of Operations and the demand response team
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Detect outages from SCADA events and coordinate dispatch response with automated escalation.
See the full list.
# Energy consumption optimization
Source: https://docs.wayak.io/use-cases/energy/energy-consumption-optimization
Analyze consumption patterns across buildings and facilities to identify waste and recommend efficiency improvements
Energy costs are a significant line item for commercial and industrial facilities, yet most organizations lack visibility into where energy is wasted. Consumption data sits in meter systems and building management platforms, but translating raw readings into actionable efficiency recommendations requires analytical effort that facility managers rarely have time for. The result is persistent waste — HVAC running in unoccupied spaces, lighting schedules misaligned with usage, and equipment operating outside optimal ranges.
Wayak connects your meter data and building systems, runs Python-based consumption analysis in a playbook, and delivers facility-specific efficiency recommendations. An agent gives facility managers instant access to consumption breakdowns, benchmarking comparisons, and cost impact estimates — making it easy to prioritize the improvements that save the most money.
***
## What you need
* **Meter data management system** — interval consumption readings (15-minute or hourly) by meter, building, and end-use category
* **Building management system (BMS)** — HVAC schedules, setpoints, lighting controls, and equipment run-time data
* **Weather API** — historical and forecast temperature, humidity, and solar radiation for normalization
* **Energy efficiency standards** — upload ASHRAE standards, ENERGY STAR benchmarks, and internal efficiency targets by building type
* **Building profiles** — upload building specifications including square footage, occupancy schedules, equipment inventories, and retrofit history
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Object | Facility | Maps to the `facilities` table in the building management system. Represents a building or campus with location, type, and specifications |
| Object | Meter | Maps to `meters` in the meter data management system. Represents a consumption measurement point with end-use category |
| Metric | Energy Use Intensity (EUI) | Total energy consumption (kBtu) / gross floor area (sq ft), measured annually or over a rolling 12-month window |
| Metric | Cost per Square Foot | Total energy cost / gross floor area, using current utility rate schedules |
| Dimension | Building Type | Categorizes facilities by use (office, warehouse, retail, data center, manufacturing) |
| Dimension | End Use | Groups consumption by category (HVAC, lighting, plug loads, process equipment) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Energy Efficiency Analyst |
| **Role** | Facility Energy Optimization Specialist |
| **Goal** | Analyze facility energy consumption, identify waste patterns, benchmark against standards, and recommend efficiency improvements with cost impact estimates |
> You are a facility energy optimization specialist who analyzes consumption data to find savings opportunities. You break down energy use by end-use category, compare facilities against ASHRAE and ENERGY STAR benchmarks, and identify anomalies like after-hours consumption or weather-inconsistent HVAC behavior. You quantify the cost impact of each finding and prioritize recommendations by payback period. You present data clearly with supporting comparisons so facility managers can justify improvement investments.
Grant access to:
* Meter data management system (interval consumption data)
* Building management system (HVAC schedules, setpoints, equipment data)
* Weather API (historical and forecast weather data)
* Energy efficiency standards knowledge space
* Building profiles knowledge space
* Facility and Meter objects, EUI and Cost per Square Foot metrics
**Trigger:** User asks for an energy breakdown of a specific facility or group of facilities.
1. Retrieve the facility profile from the building profiles knowledge space (square footage, type, occupancy schedule).
2. Pull interval consumption data from the meter data management system for the requested period.
3. Break down consumption by end-use category (HVAC, lighting, plug loads, process).
4. Calculate EUI and cost per square foot for the facility.
5. Compare against the applicable ENERGY STAR or ASHRAE benchmark from the energy efficiency standards knowledge space.
6. Return a consumption profile with total usage, end-use breakdown, EUI, benchmark comparison, and month-over-month trend.
**Trigger:** User asks the agent to identify energy waste or anomalies.
1. Pull 90 days of interval consumption data for the specified facility.
2. Retrieve the occupancy schedule and HVAC setpoints from the building management system.
3. Identify after-hours consumption that exceeds the baseload threshold.
4. Detect weather-inconsistent patterns (e.g., cooling load increasing when outdoor temperature drops).
5. Estimate the annual cost of each identified waste pattern.
6. Return a waste analysis with each pattern, its frequency, cost impact, and recommended corrective action.
**Trigger:** User asks how a facility compares to peers or standards.
1. Calculate the EUI for the specified facility.
2. Retrieve the ENERGY STAR benchmark for the facility type from the energy efficiency standards knowledge space.
3. Compare against other facilities in the portfolio of the same building type.
4. Rank the facility within the portfolio by EUI performance.
5. Return a benchmarking report with the facility's EUI, benchmark target, portfolio ranking, and the gap to the median and best performer.
***
## Automation
### Playbook: Weekly energy efficiency report
Set the trigger to **Schedule — Weekly** on Monday at 7:00 AM to give facility managers an efficiency update at the start of each week.
The workflow analyzes consumption across all facilities and surfaces the highest-impact savings opportunities:
1. **Query** the meter data management system for the prior week's interval consumption data across all monitored facilities.
2. **Query** the weather API for the corresponding week's actual weather conditions for normalization.
3. **Python code block** — compute weather-normalized EUI, cost per square foot, and after-hours consumption for each facility. The code normalizes consumption using heating and cooling degree days, calculates the delta from the prior week and the same week last year, and flags facilities with consumption increases exceeding 10% after normalization.
The **consumption analysis** step uses a Python code block to perform weather normalization using degree-day calculations and detect anomalous consumption patterns. You can customize the normalization method, comparison periods, and anomaly thresholds.
4. **Condition** — if any facility has a weather-normalized consumption increase exceeding 10%, flag it for investigation and include it in a priority list.
5. **Loop** — for each flagged facility, generate a brief analysis identifying the likely cause (HVAC schedule change, equipment fault, occupancy spike).
6. **Delivery** — distribute the weekly efficiency report.
* **Email** — send each facility manager their building's weekly efficiency report with benchmarking and flagged items
* **Slack** — post a portfolio-wide summary to `#facilities` with the top 5 facilities needing attention and the estimated weekly savings opportunity
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Track equipment condition scores from sensor data and catch degradation before failures occur.
See the full list.
# Energy & Utilities
Source: https://docs.wayak.io/use-cases/energy/index
Monitor asset health, forecast demand, and automate compliance reporting with AI agents
Energy and utility companies operate complex physical infrastructure spread across vast geographies. SCADA systems, IoT sensors, meter networks, and dispatch databases generate enormous data volumes, but turning that data into timely operational decisions remains a challenge. Delayed outage detection, inaccurate demand forecasts, and manual compliance reporting all increase costs and regulatory risk.
Wayak connects your operational data sources, applies engineering and business logic through a semantic layer, and deploys agents that monitor assets, forecast demand, and support compliance workflows. Playbooks automate the recurring analysis — daily health checks, demand projections, outage escalations — so your operations and compliance teams can act on data instead of assembling it.
## Use cases
Track equipment condition scores from SCADA and IoT data, detect degradation trends, and alert maintenance teams before failures occur.
Forecast energy demand using historical meter data and weather patterns to optimize generation dispatch and grid balancing.
Detect outages from SCADA events, coordinate dispatch response, and escalate unresolved incidents through defined channels.
Compile and format regulatory submissions from operations data and regulation documents on a recurring schedule.
Analyze consumption patterns across buildings and facilities to identify waste and recommend efficiency improvements.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data sources | SCADA system (sensor readings, alarm events, equipment status), IoT platform (temperature, vibration, pressure sensors), meter data management system (consumption readings, interval data), weather API (temperature, humidity, wind, precipitation forecasts), dispatch database (work orders, crew assignments, outage tickets) |
| Knowledge spaces | Equipment maintenance manuals, regulatory compliance documents (NERC, FERC, state PUC), operating procedures, safety protocols |
| Semantic layer | Objects for assets, meters, outages, and facilities. Metrics for health score, peak demand, SAIDI/SAIFI, and energy intensity. Dimensions for asset type, voltage level, region, and facility type |
| Agents | Asset Health Analyst for equipment monitoring and degradation detection. Grid Operations Analyst for demand and outage analysis |
| Playbooks | Scheduled daily asset health scans, hourly demand forecasting, event-triggered outage escalation, quarterly regulatory report compilation |
# Outage management
Source: https://docs.wayak.io/use-cases/energy/outage-management
Detect outages from SCADA events, coordinate dispatch response, and escalate unresolved incidents automatically
When an outage occurs, every minute of delay extends the impact — lost revenue, customer dissatisfaction, and potential safety hazards. Outage management requires rapid detection, accurate scope assessment, efficient crew dispatch, and clear escalation when restoration timelines slip. Manual coordination across SCADA alarms, dispatch boards, and communication channels introduces delays at every step.
Wayak automates the outage response workflow from detection to resolution. A playbook monitors SCADA events for outage indicators, correlates alarms to identify the affected area, dispatches the appropriate crew, and escalates if restoration exceeds the target window. An agent gives dispatchers and operations managers real-time visibility into outage status, crew locations, and estimated restoration times.
***
## What you need
* **SCADA system** — real-time alarm events, breaker status, voltage readings, and fault indicators
* **Dispatch database** — outage tickets, crew assignments, estimated restoration times, and work order status
* **GIS (geographic information system)** — network topology, asset locations, customer counts per segment, and feeder maps
* **Outage response procedures** — upload your storm/outage playbooks, crew dispatch rules, priority ranking criteria, and escalation timelines
* **Safety protocols** — upload field safety requirements, energized-line procedures, and clearance protocols
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | -------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Object | Outage | Maps to the `outages` table in the dispatch database. Represents a confirmed service interruption with scope, cause, and status |
| Object | Crew | Maps to `crews` in the dispatch database. Represents a field team with location, skillset, and availability status |
| Metric | SAIDI | System Average Interruption Duration Index — total customer-minutes of interruption / total customers served, measured monthly |
| Metric | SAIFI | System Average Interruption Frequency Index — total customer interruptions / total customers served, measured monthly |
| Dimension | Cause | Classifies outages by cause (weather, equipment failure, animal contact, vegetation, third-party damage) |
| Dimension | Priority | Ranks outages by priority (critical infrastructure, hospital/emergency, residential high-count, residential low-count) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Name** | Outage Operations Analyst |
| **Role** | Outage Management Specialist |
| **Goal** | Provide real-time outage status, support dispatch decisions with scope and crew data, and track restoration progress against targets |
> You are an outage management specialist who monitors service interruptions across the distribution network. You correlate SCADA alarms to determine outage scope, identify affected customers and critical facilities, and track crew deployment and restoration progress. You flag outages that exceed restoration targets for escalation. You present data concisely for fast decision-making during storm and emergency events. You never dispatch crews directly — you provide dispatchers with the information they need to make optimal assignments.
Grant access to:
* SCADA system (alarm events, breaker status, fault indicators)
* Dispatch database (outage tickets, crew assignments, work orders)
* GIS (network topology, customer counts, asset locations)
* Outage response procedures knowledge space
* Safety protocols knowledge space
* Outage and Crew objects, SAIDI and SAIFI metrics
**Trigger:** User asks for the current outage status or a specific outage update.
1. Query the dispatch database for all active outages with their current status, scope, and assigned crews.
2. Pull the latest SCADA readings for the affected areas to verify continued interruption.
3. Retrieve customer counts and critical facility flags from the GIS for each outage area.
4. Check each outage's elapsed time against the restoration target from the outage response procedures knowledge space.
5. Return a status briefing with each outage's ID, location, cause, customers affected, assigned crew, elapsed time, and restoration target status.
**Trigger:** User asks which crews are available or which crew to send to a new outage.
1. Query the dispatch database for all crews with their current assignment status and location.
2. Filter for crews with the required skillset (e.g., high-voltage, underground, substation).
3. Calculate travel time from each available crew's current location to the outage site using GIS data.
4. Rank available crews by travel time and match priority.
5. Return a ranked list of available crews with skillset, current location, estimated travel time, and current assignment.
**Trigger:** User asks about the impact of current or historical outages on reliability metrics.
1. Query the dispatch database for outage records over the requested time period.
2. Calculate SAIDI and SAIFI using the customer interruption data from the GIS.
3. Break down the metrics by cause, region, and month.
4. Compare against regulatory targets and prior-year performance.
5. Return an impact analysis with current metrics, year-to-date trend, regulatory target status, and the top contributing outage events.
***
## Automation
### Playbook: Outage detection and escalation
Set the trigger to **Event — New alarm** on the SCADA system. The playbook fires when a fault or breaker-open alarm is received.
The workflow detects outages, assesses scope, and coordinates the response:
1. **Query** the SCADA alarm event details, including the affected equipment, fault type, and timestamp.
2. **Query** the GIS for the network topology downstream of the affected equipment to determine the outage scope (number of customers, critical facilities).
3. **Condition** — check if a related outage ticket already exists in the dispatch database (e.g., a downstream alarm for an already-known outage). If so, update the existing ticket and skip crew dispatch.
4. **Action** — create a new outage ticket in the dispatch database with the scope, priority (based on customer count and critical facilities), and estimated restoration time per the outage response procedures.
5. **Action** — identify the nearest available crew with the required skillset and assign them to the outage ticket.
6. **Condition** — set a timer for the restoration target. If the outage is not resolved within the target window, trigger an escalation step.
7. **Delivery** — notify dispatch and management of the new outage and crew assignment.
* **Slack** — post new outage alerts to `#outage-dispatch` with location, scope, priority, and assigned crew
* **Email** — notify the on-call supervisor of any critical-priority outages (hospitals, emergency services)
* **Slack escalation** — if restoration exceeds the target window, post to `#ops-management` with the outage details and elapsed time
Click **Run now** to test with a recent SCADA event, then toggle to **Active**.
***
## What's next
Automate the compilation of regulatory submissions from operations data and compliance documents.
See the full list.
# Regulatory compliance reporting
Source: https://docs.wayak.io/use-cases/energy/regulatory-compliance-reporting
Compile and format regulatory submissions from operations data and regulation documents on a recurring schedule
Energy utilities operate under extensive regulatory oversight from NERC, FERC, state public utility commissions, and environmental agencies. Compliance reporting requires pulling data from SCADA, meter systems, operations databases, and environmental monitoring — then formatting it to exact regulatory specifications. Each report cycle demands weeks of analyst time for data gathering, validation, and formatting, and a single error can trigger penalties or mandatory re-filings.
Wayak automates the reporting pipeline. A playbook queries your operational data sources, validates the figures against regulatory definitions stored in a knowledge space, and produces formatted reports on a recurring schedule. An agent lets compliance officers investigate data points, trace figures back to source records, and answer ad-hoc regulatory questions.
***
## What you need
* **Operations database** — generation output, capacity factors, forced outage rates, and dispatch records
* **Meter data management system** — customer consumption totals, peak demand readings, and loss calculations
* **Environmental monitoring system** — emissions readings, discharge measurements, and permit compliance data
* **Regulatory requirements** — upload NERC reliability standards, FERC filing templates, state PUC reporting requirements, and EPA emissions reporting guidelines
* **Internal reporting procedures** — upload your data validation checklists, signoff workflows, and filing calendars
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| Object | Filing | Maps to the `filings` table in the compliance system. Represents a single regulatory submission with period, type, and status |
| Object | Generation Unit | Maps to `units` in the operations database. Represents a power generation asset with capacity, fuel type, and operating characteristics |
| Metric | Capacity Factor | Actual generation output / maximum possible output for a unit over a reporting period |
| Metric | Forced Outage Rate | Hours of forced outage / (hours of forced outage + operating hours) for each generation unit |
| Dimension | Regulatory Body | Groups filings by regulator (NERC, FERC, State PUC, EPA) |
| Dimension | Filing Frequency | Classifies reports by submission frequency (monthly, quarterly, annual) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Regulatory Compliance Analyst |
| **Role** | Energy Regulatory Reporting Specialist |
| **Goal** | Compile regulatory report data from operations systems, validate figures against regulatory definitions, trace data lineage, and answer compliance queries |
> You are a regulatory reporting specialist for an energy utility. You compile data from generation, transmission, distribution, and environmental systems for regulatory submissions. You validate every figure against the applicable regulatory definition, flag discrepancies, and provide data lineage so auditors can trace any number back to its source. You reference the specific regulatory standard or filing requirement for every data point. You prepare validated drafts — final signoff is always a human responsibility.
Grant access to:
* Operations database (generation output, outage records, dispatch logs)
* Meter data management system (consumption totals, peak demand, losses)
* Environmental monitoring system (emissions, discharge data)
* Regulatory requirements knowledge space
* Internal reporting procedures knowledge space
* Filing and Generation Unit objects, Capacity Factor and Forced Outage Rate metrics
**Trigger:** User asks the agent to compile data for a specific regulatory filing.
1. Identify the filing type and reporting period from the user's request.
2. Load the applicable regulatory template and required data fields from the regulatory requirements knowledge space.
3. Query the operations database for generation, outage, and dispatch data for the reporting period.
4. Query the meter data management system for consumption, peak demand, and loss figures.
5. If the filing includes environmental data, query the environmental monitoring system for emissions and discharge readings.
6. Aggregate and format the data according to the regulatory template structure.
7. Return the compiled data with cell-level source references for audit traceability.
**Trigger:** User asks the agent to validate a compiled report or a specific data point.
1. Load the compiled data for the specified filing.
2. Run cross-checks defined in the internal reporting procedures (e.g., generation output must reconcile with fuel consumption, losses must fall within expected ranges).
3. Compare calculated metrics against regulatory thresholds and prior-period values for reasonableness.
4. Flag any validation failures with the specific check, expected range, and actual value.
5. Return a validation summary with pass/fail results and items requiring manual review.
**Trigger:** User asks the agent to trace a specific figure in a report back to its source.
1. Identify the data point in the compiled report.
2. Trace the aggregation path from the report cell back to the source query and table.
3. Pull the individual source records that contribute to the aggregated figure.
4. Document the calculation method and any transformations applied.
5. Return the lineage chain from report cell to source record, with the calculation formula at each step.
***
## Automation
### Playbook: Quarterly regulatory filing preparation
Set the trigger to **Schedule — Quarterly** on the 10th day after quarter-end, allowing time for operational data to settle before compilation begins.
The workflow compiles, validates, and packages quarterly regulatory submissions:
1. **Query** generation output, forced outage hours, and capacity data for the quarter from the operations database.
2. **Query** customer consumption totals, peak demand, and system loss calculations from the meter data management system.
3. **Query** emissions and environmental compliance data from the environmental monitoring system.
4. **Action** — aggregate and format the data according to each regulatory template (NERC, FERC, state PUC, EPA as applicable).
5. **Condition** — run validation checks. If any check fails, create a review task and flag the affected filing section.
6. **Action** — generate the formatted draft report for each regulatory body.
7. **Delivery** — distribute draft reports for review and signoff.
* **Email** — send each draft report to the assigned compliance analyst for review and signoff
* **Slack** — post a summary to `#regulatory-reporting` with filing status, validation results, and any flagged items
* **Email** — notify the VP of Regulatory Affairs when all drafts are ready for final review
Click **Run now** to test with the most recent quarter's data, then toggle to **Active**.
***
## What's next
Analyze consumption patterns across facilities to identify waste and recommend efficiency improvements.
See the full list.
# Finance & Banking
Source: https://docs.wayak.io/use-cases/finance/index
Automate loan processing, monitor portfolio risk, and detect transaction anomalies with AI agents
Financial institutions manage enormous volumes of transactions, regulatory obligations, and customer data across core banking systems, market data feeds, and compliance databases. The real challenge is not data availability — it is the speed and accuracy required to act on it. Delayed risk alerts, manual loan reviews, and labor-intensive compliance reports create operational drag and expose the institution to unnecessary risk.
Wayak connects your banking data sources, applies business logic through a semantic layer, and deploys agents that analyze, monitor, and report across your financial operations. Your teams get real-time insights instead of end-of-day summaries, and playbooks automate the repetitive workflows that traditionally require dedicated analysts.
## Use cases
Streamline the intake and evaluation of loan applications by combining applicant data with document review and automated routing decisions.
Track portfolio-level risk metrics daily using live market data, flag breaches against risk limits, and deliver alerts to portfolio managers.
Compile and format regulatory submissions automatically from transaction data and compliance documentation on a recurring schedule.
Detect statistically unusual transactions in real time using outlier analysis and route flagged items for immediate review.
Score new and existing customers using a composite credit model that blends internal CRM history with bureau data.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data sources | Core banking system (accounts, transactions, balances), loan origination system (applications, decisions, documents), market data API (prices, rates, indices), CRM (customer profiles, interaction history), credit bureau API (scores, trade lines) |
| Knowledge spaces | Regulatory guidelines (Basel III, Dodd-Frank), internal credit policies, loan underwriting manuals, compliance checklists |
| Semantic layer | Objects for accounts, loans, portfolios, and customers. Metrics for VaR, Sharpe ratio, default probability, and approval rate. Dimensions for product type, risk rating, branch, and regulatory category |
| Agents | Loan Intake Analyst for application review and routing. Risk Monitor for portfolio surveillance and alerting |
| Playbooks | Scheduled daily risk snapshots, event-triggered loan routing, weekly regulatory report generation, real-time anomaly detection alerts |
# Loan application processing
Source: https://docs.wayak.io/use-cases/finance/loan-application-processing
Accelerate loan intake by combining applicant data review with document analysis and automated routing
Loan origination is one of the most document-heavy workflows in banking. Each application requires pulling credit data, verifying income documents, cross-checking against underwriting policies, and routing the file to the right decision-maker. Manual handling introduces delays, inconsistent evaluations, and bottlenecks during peak volume periods.
With Wayak, you build an agent that reviews incoming applications against your underwriting criteria, extracts key data points from uploaded documents, and routes each file based on risk tier and product type. A playbook monitors new submissions and triggers the intake workflow automatically, so your team focuses on decisions rather than data gathering.
***
## What you need
* **Loan origination system** — application records, applicant demographics, requested amounts, and decision history
* **Credit bureau API** — credit scores, trade lines, delinquency history, and inquiries
* **Core banking system** — existing account balances, deposit history, and relationship tenure
* **Underwriting policy manual** — upload your current credit policy, including approval thresholds by product type and risk tier
* **Regulatory guidelines** — fair lending requirements, disclosure rules, and documentation checklists
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------------- | ----------------------------------------------------------------------------------------------------- |
| Object | Loan Application | Maps to the `applications` table in the loan origination system. Represents a single borrower request |
| Object | Customer | Maps to `customers` in the core banking system. Represents an individual or business entity |
| Metric | Approval Rate | Count of approved applications / total applications, segmented by product and branch |
| Metric | Average Processing Time | Mean elapsed days from submission to decision across all applications |
| Dimension | Product Type | Categorizes applications by mortgage, personal, auto, or commercial |
| Dimension | Risk Tier | Groups applications into low, medium, high, and very-high risk based on credit score bands |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Loan Intake Analyst |
| **Role** | Loan Application Reviewer |
| **Goal** | Review incoming loan applications, verify completeness, assess preliminary risk, and route to the appropriate underwriting queue |
> You are a detail-oriented loan intake analyst. You evaluate each application against underwriting policies, flag missing documents or data discrepancies, and classify risk tier using credit bureau data and internal account history. You prioritize accuracy and regulatory compliance over speed, and you never approve or deny an application — you prepare it for human decision-making.
Grant access to:
* Loan origination system (applications table, decision history)
* Credit bureau API (scores, trade lines)
* Core banking system (customer accounts, deposit history)
* Underwriting policy manual knowledge space
* Regulatory guidelines knowledge space
* Loan Application and Customer objects, Approval Rate metric
**Trigger:** User asks the agent to review a specific application or batch of applications.
1. Retrieve the application record from the loan origination system.
2. Compare submitted fields against the required-documents checklist from the underwriting policy manual.
3. Flag any missing or inconsistent fields (income verification, employment letter, identification).
4. Pull the applicant's credit score and trade line summary from the credit bureau API.
5. Look up the applicant's existing account relationship in the core banking system.
6. Generate a completeness summary with a pass/fail status and a list of items needing follow-up.
**Trigger:** User asks the agent to classify an application by risk level.
1. Retrieve the applicant's credit score, debt-to-income ratio, and trade line count from bureau data.
2. Pull deposit history and average balance from the core banking system.
3. Match the product type to the corresponding risk-tier thresholds in the underwriting policy manual.
4. Assign a risk tier (low, medium, high, or very-high) based on the combined criteria.
5. Return a structured summary with the assigned tier, contributing factors, and the applicable policy section reference.
**Trigger:** User asks the agent where to route an application.
1. Check the application's completeness status and risk tier from previous assessments.
2. Look up the routing rules in the underwriting policy manual for the given product type and risk tier.
3. Identify the correct underwriting queue (auto-approve, standard review, senior review, or decline queue).
4. Flag any regulatory holds (e.g., fair lending review triggers).
5. Return the recommended queue, expected SLA, and any special handling instructions.
***
## Automation
### Playbook: New application intake router
Set the trigger to **Event — New record** on the `applications` table in the loan origination system. The playbook fires each time a new application is submitted.
The workflow performs a multi-step evaluation of each new application:
1. **Query** the application record and join it with the applicant's credit bureau data and core banking profile.
2. **Condition** — check whether all required documents are present. If documents are missing, branch to a notification step that emails the applicant with a list of outstanding items.
3. **Condition** — evaluate risk tier. If the risk tier is "low" and all documents are present, route to the auto-approve queue. Otherwise, route to the appropriate review queue.
4. **Action** — update the application status in the loan origination system with the assigned queue and tier.
5. **Delivery** — send a Slack notification to the underwriting channel with the application ID, applicant name, product type, risk tier, and assigned queue.
* **Slack** — send to the `#loan-underwriting` channel with application summary
* **Email** — notify the assigned underwriter with a detailed intake report
* **Email to applicant** — send a confirmation with application ID and expected timeline
Click **Run now** to test with a recent application, then toggle to **Active**.
***
## What's next
Build a composite credit scoring model that feeds directly into your loan application workflow.
See the full list.
# Portfolio risk monitoring
Source: https://docs.wayak.io/use-cases/finance/portfolio-risk-monitoring
Track daily portfolio risk metrics and receive alerts when positions breach defined thresholds
Portfolio managers need timely visibility into risk exposure across asset classes, sectors, and individual positions. Manually pulling market data, computing Value at Risk, and comparing against limits is slow and error-prone — especially when markets move quickly. By the time a spreadsheet-based risk report is ready, the window for corrective action may have already closed.
Wayak connects your holdings database and market data feeds, computes risk metrics through a playbook with Python code execution, and delivers daily risk snapshots to the right people. An agent lets portfolio managers query risk metrics conversationally, drilling into specific positions or sectors without waiting for a scheduled report.
***
## What you need
* **Holdings database** — current positions, cost basis, allocation targets, and asset class tags
* **Market data API** — daily closing prices, benchmark indices, interest rates, and volatility measures
* **Core banking system** — fund-level metadata, client mandates, and risk limit definitions
* **Investment policy statements** — upload fund mandates, risk tolerance parameters, and allocation constraints
* **Risk management guidelines** — internal procedures for limit breaches, escalation protocols, and reporting standards
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------- | ----------------------------------------------------------------------------------------------------- |
| Object | Portfolio | Maps to the `portfolios` table in the holdings database. Represents a managed fund or account |
| Object | Position | Maps to `positions` in the holdings database. Represents a single security holding within a portfolio |
| Metric | Value at Risk (VaR) | 1-day 95% parametric VaR calculated from position weights and historical return covariance |
| Metric | Sharpe Ratio | (Portfolio return - risk-free rate) / portfolio standard deviation, annualized |
| Metric | Tracking Error | Standard deviation of the difference between portfolio and benchmark returns |
| Dimension | Asset Class | Categorizes positions as equity, fixed income, commodity, or alternative |
| Dimension | Sector | Groups equity positions by GICS sector classification |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Risk Monitor |
| **Role** | Portfolio Risk Analyst |
| **Goal** | Monitor portfolio risk metrics daily, identify limit breaches and concentration risks, and answer ad-hoc risk queries from portfolio managers |
> You are a quantitative risk analyst focused on portfolio surveillance. You compute and interpret risk metrics including VaR, Sharpe ratio, and tracking error. You flag any positions or sectors that exceed defined limits and provide concise, data-driven explanations. You avoid making investment recommendations and instead present risk data objectively so portfolio managers can make informed decisions.
Grant access to:
* Holdings database (portfolios, positions)
* Market data API (prices, indices, rates)
* Core banking system (fund metadata, risk limits)
* Investment policy statements knowledge space
* Risk management guidelines knowledge space
* Portfolio and Position objects, VaR, Sharpe Ratio, and Tracking Error metrics
**Trigger:** User asks for a risk summary of a specific portfolio or all portfolios.
1. Pull current positions and weights from the holdings database for the requested portfolio.
2. Retrieve the latest closing prices and benchmark index levels from the market data API.
3. Calculate 1-day VaR, Sharpe ratio, and tracking error using the semantic layer metrics.
4. Compare each metric against the risk limits defined in the core banking system.
5. Highlight any breaches or near-breaches (within 10% of limit).
6. Return a formatted summary table with portfolio name, each metric value, limit, and status.
**Trigger:** User asks about sector, asset class, or single-name concentration.
1. Query position weights grouped by the requested dimension (sector, asset class, or individual security).
2. Retrieve the concentration limits from the investment policy statement knowledge space.
3. Rank exposures from highest to lowest weight.
4. Flag any that exceed or approach the concentration limit.
5. Return a ranked table with the dimension value, current weight, limit, and overweight/underweight status.
**Trigger:** User asks about portfolio drawdown or peak-to-trough loss.
1. Pull daily portfolio NAV history from the holdings database.
2. Retrieve the benchmark return series from the market data API.
3. Calculate the maximum drawdown, current drawdown from peak, and recovery period.
4. Compare portfolio drawdown to benchmark drawdown over the same period.
5. Return a summary with drawdown figures, dates, and relative performance versus benchmark.
***
## Automation
### Playbook: Daily portfolio risk report
Set the trigger to **Schedule — Daily** at 7:00 AM, after markets have closed and end-of-day prices are available.
The workflow computes risk metrics across all active portfolios and delivers a consolidated report:
1. **Query** all active portfolios and their current positions from the holdings database.
2. **Query** the latest closing prices, risk-free rate, and benchmark returns from the market data API.
3. **Python code block** — compute VaR, Sharpe ratio, and tracking error for each portfolio. The code uses position weights and a covariance matrix built from 252-day historical returns to calculate parametric VaR at the 95% confidence level. You can customize the lookback window and confidence interval.
The **risk metrics computation** step uses a Python code block to calculate Value at Risk using variance-covariance methodology, Sharpe ratio from annualized returns, and tracking error against the benchmark. You can customize the confidence level, lookback period, and risk-free rate source.
4. **Condition** — check each portfolio for limit breaches. If any metric exceeds its defined threshold, flag the portfolio as "breach" and include it in an escalation list.
5. **Loop** — for each breached portfolio, generate a detailed breakdown showing which metric breached, by how much, and the top contributing positions.
6. **Delivery** — compile results into a formatted daily risk report.
* **Email** — send the full daily risk report to the risk management distribution list
* **Slack** — post a summary to `#risk-alerts` with breach highlights only
* **Email escalation** — if any portfolio has a VaR breach, send an immediate escalation to the Chief Risk Officer
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Detect unusual transactions that may signal fraud or operational errors across your accounts.
See the full list.
# Regulatory reporting
Source: https://docs.wayak.io/use-cases/finance/regulatory-reporting
Automate the compilation and formatting of regulatory submissions from transaction data and compliance documentation
Regulatory reporting in banking is a recurring, high-stakes obligation. Each submission — whether for Basel III capital adequacy, anti-money laundering filings, or consumer lending disclosures — requires pulling data from multiple systems, cross-referencing against regulatory definitions, and formatting the output to exact specifications. Manual compilation is slow, error-prone, and consumes significant analyst time every reporting cycle.
Wayak automates this workflow end to end. You connect your transaction database and compliance documentation, define the regulatory metrics in your semantic layer, and schedule a playbook that compiles, validates, and delivers formatted reports on a recurring basis. An agent lets compliance officers query the underlying data conversationally to investigate flagged items or answer ad-hoc questions from regulators.
***
## What you need
* **Transaction database** — completed transactions, posting dates, counterparties, amounts, and currency codes
* **General ledger** — account balances, capital ratios, and reserve allocations
* **Core banking system** — customer classifications, product mappings, and branch hierarchy
* **Regulatory guidelines** — upload Basel III framework documents, Dodd-Frank requirements, and local regulatory filing templates
* **Internal compliance procedures** — data validation checklists, exception handling rules, and signoff workflows
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------------- | --------------------------------------------------------------------------------------------------------------- |
| Object | Transaction | Maps to the `transactions` table. Represents a single financial transaction with amount, type, and counterparty |
| Object | Regulatory Filing | Maps to `filings` in the compliance system. Represents a single report submission with status and period |
| Metric | Capital Adequacy Ratio | Total qualifying capital / risk-weighted assets, as defined by Basel III Pillar 1 |
| Metric | Large Exposure Ratio | Aggregate exposure to a single counterparty / total capital, subject to 25% regulatory ceiling |
| Dimension | Regulatory Category | Classifies transactions by reporting category (credit risk, market risk, operational risk) |
| Dimension | Filing Period | Groups data by reporting period (monthly, quarterly, annual) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Name** | Compliance Reporter |
| **Role** | Regulatory Reporting Analyst |
| **Goal** | Compile regulatory report data, validate figures against defined rules, and answer compliance queries using transaction data and regulatory guidelines |
> You are a meticulous regulatory reporting analyst. You compile data for regulatory submissions by cross-referencing transaction records against regulatory definitions and internal validation rules. You flag any data inconsistencies or threshold breaches and cite the specific regulation or policy section that applies. You never finalize a submission — you prepare validated drafts for human review and signoff.
Grant access to:
* Transaction database (all transaction types)
* General ledger (balances, capital accounts)
* Core banking system (customer classifications, product mappings)
* Regulatory guidelines knowledge space
* Internal compliance procedures knowledge space
* Transaction and Regulatory Filing objects, Capital Adequacy Ratio and Large Exposure Ratio metrics
**Trigger:** User asks the agent to compile data for a specific regulatory report and period.
1. Identify the reporting template and required fields from the regulatory guidelines knowledge space.
2. Query the transaction database for all transactions within the specified reporting period.
3. Classify each transaction by regulatory category using the semantic layer dimension.
4. Aggregate figures according to the report template structure (e.g., risk-weighted assets by category).
5. Pull supporting balances from the general ledger to calculate capital ratios.
6. Return a structured data summary aligned to the report template, with cell-level references to source data.
**Trigger:** User asks the agent to validate a compiled report.
1. Load the compiled data for the specified report and period.
2. Run cross-checks defined in the internal compliance procedures (e.g., assets must equal liabilities plus equity).
3. Compare calculated ratios against regulatory thresholds (e.g., capital adequacy must exceed 8%).
4. Flag any validation failures with the specific rule reference and the magnitude of the discrepancy.
5. Return a validation summary with pass/fail status for each check and a list of items requiring manual review.
**Trigger:** User asks a question about a specific regulation or reporting requirement.
1. Search the regulatory guidelines knowledge space for the relevant regulation or section.
2. Extract the applicable rules, thresholds, and definitions.
3. If the query involves data, pull the relevant figures from the transaction database or general ledger.
4. Return the regulatory text with interpretation and any supporting data.
***
## Automation
### Playbook: Quarterly regulatory report
Set the trigger to **Schedule — Quarterly** on the 5th business day after quarter-end, allowing time for transaction settlement and reconciliation.
The workflow compiles, validates, and packages the quarterly regulatory submission:
1. **Query** all transactions from the reporting quarter, joined with customer classifications and product mappings from the core banking system.
2. **Query** the general ledger for quarter-end balances, capital accounts, and reserve positions.
3. **Action** — classify and aggregate transactions by regulatory category using the semantic layer definitions.
4. **Condition** — run validation checks against internal compliance rules. If any check fails, branch to an exception handling step that creates a review task and halts the report.
5. **Action** — format the validated data into the regulatory report template, populating each required field.
6. **Delivery** — send the draft report to the compliance team for review and signoff.
* **Email** — send the formatted draft report to the Chief Compliance Officer and regulatory reporting team
* **Slack** — post a summary to `#compliance-reporting` with report status, key ratios, and any flagged items
Click **Run now** to test with the most recent quarter's data, then toggle to **Active**.
***
## What's next
Automate the intake and routing of loan applications using document review and risk classification.
See the full list.
# Transaction anomaly detection
Source: https://docs.wayak.io/use-cases/finance/transaction-anomaly-detection
Identify statistically unusual transactions in real time and route flagged items for immediate review
Fraud, operational errors, and money laundering all leave traces in transaction data — but those traces are easy to miss among millions of daily transactions. Rule-based systems catch known patterns, but novel anomalies slip through. Analysts reviewing alerts manually face high false-positive rates and fatigue, which means genuine threats get buried in the noise.
Wayak takes a data-driven approach to anomaly detection. A playbook runs Python-based statistical analysis on your transaction stream to identify outliers by amount, frequency, counterparty behavior, and timing patterns. Flagged transactions are routed to an agent that provides context — pulling account history, counterparty information, and similar past cases — so your investigations team can act quickly and decisively.
***
## What you need
* **Transaction database** — real-time or near-real-time transaction records including amounts, timestamps, counterparties, channels, and geolocation
* **Core banking system** — customer profiles, account types, typical transaction patterns, and historical baselines
* **Watchlist database** — sanctioned entities, PEP lists, and internal flagged accounts
* **AML compliance manual** — anti-money laundering rules, suspicious activity indicators, and reporting thresholds
* **Investigation procedures** — internal protocols for alert triage, escalation paths, and case documentation standards
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | --------------------- | ------------------------------------------------------------------------------------------------------------ |
| Object | Transaction | Maps to the `transactions` table. Represents a single financial movement with amount, channel, and timestamp |
| Object | Alert | Maps to `alerts` in the monitoring system. Represents a flagged transaction pending investigation |
| Metric | Anomaly Score | Z-score of the transaction amount relative to the customer's 90-day rolling mean and standard deviation |
| Metric | Alert Conversion Rate | Percentage of alerts that result in a confirmed suspicious activity report (SAR) |
| Dimension | Channel | Categorizes transactions by origination channel (branch, ATM, online, mobile, wire) |
| Dimension | Alert Priority | Classifies alerts as critical, high, medium, or low based on anomaly score thresholds |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Transaction Investigator |
| **Role** | Fraud and Anomaly Analyst |
| **Goal** | Provide context and analysis for flagged transactions, help investigators assess alerts, and surface related patterns across accounts |
> You are a transaction investigation analyst specializing in anomaly detection and fraud analysis. When presented with a flagged transaction, you pull the customer's historical transaction profile, identify what makes the transaction unusual, and check for related activity across linked accounts. You present findings objectively with supporting data, and you flag any matches against watchlists. You never make a final determination — you equip investigators with the evidence they need.
Grant access to:
* Transaction database (all channels and transaction types)
* Core banking system (customer profiles, account history)
* Watchlist database (sanctions, PEP lists)
* AML compliance manual knowledge space
* Investigation procedures knowledge space
* Transaction and Alert objects, Anomaly Score and Alert Conversion Rate metrics
**Trigger:** User asks the agent to investigate a specific flagged transaction or alert.
1. Retrieve the flagged transaction details from the transaction database.
2. Pull the customer's 90-day transaction history and compute baseline statistics (mean amount, frequency, typical channels).
3. Identify why the transaction was flagged — which dimensions (amount, timing, counterparty, channel) deviated from the baseline.
4. Check the counterparty against the watchlist database for sanctions or PEP matches.
5. Search for similar transactions across linked accounts or the same counterparty in the last 30 days.
6. Return a structured investigation report with the transaction details, anomaly explanation, watchlist results, and related activity.
**Trigger:** User asks about transaction patterns for a customer, counterparty, or account group.
1. Query the transaction database for all activity involving the specified entity over the requested time period.
2. Compute descriptive statistics (volume, average amount, channel distribution, time-of-day patterns).
3. Identify structuring indicators (e.g., multiple transactions just below reporting thresholds).
4. Compare the entity's behavior to peer group baselines from the core banking system.
5. Return a behavioral profile with charts-ready data, flagged patterns, and comparison to norms.
**Trigger:** User asks the agent to screen a name, entity, or account against watchlists.
1. Search the watchlist database for exact and fuzzy matches against the provided name or entity.
2. If a match is found, retrieve the full watchlist entry (reason, source list, effective date).
3. Pull any existing alerts or cases linked to the matched entity from the monitoring system.
4. Check the AML compliance manual for the required response protocol for the match type.
5. Return the screening result with match confidence, supporting details, and recommended next steps per policy.
***
## Automation
### Playbook: Real-time anomaly detection scan
Set the trigger to **Schedule — Hourly** to scan the latest batch of transactions. For higher-frequency environments, set it to every 15 minutes.
The workflow applies statistical outlier detection to recent transactions and routes anomalies for investigation:
1. **Query** all transactions posted since the last scan from the transaction database.
2. **Query** the 90-day rolling baseline statistics (mean, standard deviation, typical channels) for each transacting customer from the core banking system.
3. **Python code block** — compute the anomaly score for each transaction. The code calculates a Z-score based on the customer's historical mean and standard deviation, then applies additional flags for unusual channel usage, atypical counterparties, and timing anomalies (e.g., transactions outside normal business hours). Transactions exceeding a configurable Z-score threshold are flagged.
The **anomaly scoring** step uses a Python code block to compute Z-scores and apply multi-dimensional outlier detection. You can customize the Z-score threshold (default: 3.0), the lookback window for baselines, and the weighting of each anomaly dimension.
4. **Condition** — check each flagged transaction against the watchlist database. If there is a match, escalate priority to critical.
5. **Loop** — for each flagged transaction, create an alert record in the monitoring system with the anomaly score, contributing factors, and priority level.
6. **Delivery** — notify the investigations team of new alerts.
* **Slack** — post critical and high-priority alerts to `#fraud-alerts` immediately
* **Email** — send a digest of all new alerts to the fraud investigations team lead
* **Webhook** — push alert data to your case management system for automatic case creation
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Monitor portfolio-level risk metrics daily and catch limit breaches before they escalate.
See the full list.
# Appointment scheduling
Source: https://docs.wayak.io/use-cases/healthcare/appointment-scheduling
Coordinate appointment bookings across providers and departments using availability data, patient preferences, and scheduling rules
Scheduling in healthcare is far more complex than finding an open time slot. It involves matching patient needs with provider specialties, respecting insurance network requirements, sequencing multi-visit care plans, and minimizing no-shows. When scheduling is handled manually, the result is underutilized provider time, long patient wait times, and frequent rescheduling.
Wayak automates scheduling coordination with a playbook that monitors appointment requests, checks provider availability, applies scheduling rules, and sends confirmations and reminders. An agent handles conversational scheduling queries — helping staff find the right slot for complex cases or rescheduling patients when conflicts arise.
***
## What you need
* **EHR system** — patient records, referral orders, care plans, and visit history
* **Scheduling API** — provider availability, appointment slots, room assignments, and equipment bookings
* **Insurance eligibility API** — network status, authorization requirements, and visit limits
* **Scheduling policies** — upload your organization's scheduling rules, including time-block allocations, new vs. returning patient slots, and multi-visit sequencing guidelines
* **Provider directory** — upload provider profiles with specialties, accepted insurance plans, and location assignments
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------- | --------------------------------------------------------------------------------------------------------------- |
| Object | Appointment | Maps to the `appointments` table in the scheduling system. Represents a booked or requested time slot |
| Object | Provider | Maps to `providers` in the scheduling system. Represents a clinician with specialty, availability, and location |
| Metric | No-Show Rate | Percentage of confirmed appointments where the patient did not arrive, measured over a rolling 30-day window |
| Metric | Utilization Rate | Percentage of available appointment slots that are booked, by provider and department |
| Dimension | Visit Type | Categorizes appointments as new patient, follow-up, procedure, imaging, or telehealth |
| Dimension | Department | Groups appointments by clinical department (primary care, cardiology, orthopedics, etc.) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Name** | Scheduling Coordinator |
| **Role** | Appointment Scheduling Specialist |
| **Goal** | Find optimal appointment slots by matching patient needs with provider availability, insurance requirements, and scheduling policies |
> You are a scheduling coordinator who matches patients to the right provider and time slot. You consider provider specialty, insurance network status, patient location preferences, and care plan sequencing when recommending slots. You flag scheduling conflicts, highlight high no-show risk patients for overbooking consideration, and suggest alternatives when the preferred slot is unavailable. You are efficient and patient-centric — minimizing wait time and maximizing provider utilization.
Grant access to:
* EHR system (patient records, referrals, care plans)
* Scheduling API (provider availability, appointment slots)
* Insurance eligibility API (network status, visit limits)
* Scheduling policies knowledge space
* Provider directory knowledge space
* Appointment and Provider objects, No-Show Rate and Utilization Rate metrics
**Trigger:** User asks the agent to find available slots for a patient.
1. Retrieve the patient's referral or care plan details from the EHR system.
2. Identify the required provider specialty and visit type.
3. Check the patient's insurance network status against the provider directory.
4. Query the scheduling API for available slots matching the specialty, location, and visit type.
5. Apply scheduling policies (e.g., new patient time blocks, required equipment availability).
6. Rank available slots by proximity to the patient's preferred date and time.
7. Return the top three recommended slots with provider name, location, date, time, and any preparation instructions.
**Trigger:** User asks the agent to reschedule an existing appointment.
1. Retrieve the existing appointment details from the scheduling API.
2. Check the cancellation policy window and any associated authorization constraints.
3. Query available alternative slots for the same provider or an equivalent provider.
4. If the original provider has no availability, find the next available same-specialty provider in the patient's insurance network.
5. Return the alternative options with the impact on any care plan sequencing.
**Trigger:** User asks about scheduling utilization or no-show patterns.
1. Query the scheduling API for appointment data over the requested time period.
2. Calculate utilization rate by provider and department.
3. Compute the no-show rate and identify high no-show risk patterns (day of week, visit type, patient segment).
4. Compare utilization against department targets from the scheduling policies knowledge space.
5. Return a utilization summary with recommendations for overbooking adjustments or slot reallocation.
***
## Automation
### Playbook: Appointment reminder and no-show prevention
Set the trigger to **Schedule — Daily** at 8:00 AM to process reminders for the next two business days.
The workflow sends appointment reminders, identifies high no-show risk patients, and manages waitlist backfill:
1. **Query** all confirmed appointments for the next two business days from the scheduling API.
2. **Loop** — for each appointment, retrieve the patient's contact preferences and no-show history from the EHR system.
3. **Condition** — check the patient's historical no-show rate. If it exceeds 30%, flag the appointment for overbooking consideration and add the time slot to a waitlist backfill queue.
4. **Action** — send a reminder to each patient via their preferred channel (email, SMS, or both) with the appointment date, time, provider, location, and preparation instructions.
5. **Condition** — if a patient responds to cancel, automatically release the slot and notify the first patient on the waitlist.
6. **Delivery** — summarize the day's reminder activity for the scheduling team.
* **Email/SMS to patients** — personalized appointment reminders with confirmation links
* **Slack** — post a daily summary to `#scheduling` with the count of reminders sent, high no-show risk appointments, and waitlist fills
* **Email** — notify providers of any overbooking flags on their schedule
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Scan your operational data against regulatory requirements and catch gaps before audits.
See the full list.
# Clinical documentation
Source: https://docs.wayak.io/use-cases/healthcare/clinical-documentation
Draft clinical notes and encounter summaries from EHR data and clinical guidelines to reduce physician documentation burden
Physicians spend a significant portion of their day on documentation — writing progress notes, discharge summaries, and referral letters. This administrative load contributes to burnout and takes time away from patient care. Clinical notes must be thorough, accurate, and compliant with coding requirements, which makes shortcuts risky. The challenge is reducing the effort without sacrificing quality.
Wayak deploys an agent that drafts clinical documentation by pulling structured data from your EHR and referencing clinical practice guidelines stored in a knowledge space. The agent produces note drafts that clinicians review and finalize, cutting documentation time while maintaining clinical accuracy and coding compliance.
***
## What you need
* **EHR system** — patient encounters, diagnoses, orders, lab results, vital signs, medications, and problem lists
* **Billing database** — historical claim codes, reimbursement outcomes, and denial reasons
* **Clinical practice guidelines** — upload condition-specific guidelines (e.g., AHA for cardiovascular, ADA for diabetes) that inform documentation standards
* **Documentation templates** — upload your organization's note templates for progress notes, H\&P, discharge summaries, and referral letters
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Object | Encounter | Maps to the `encounters` table in the EHR. Represents a single patient visit with diagnoses, orders, and notes |
| Object | Patient | Maps to `patients` in the EHR. Represents a patient with their complete medical record |
| Metric | Documentation Completion Rate | Percentage of encounters with finalized notes within 24 hours of the visit |
| Metric | Average Note Turnaround | Mean elapsed hours from encounter close to note finalization |
| Dimension | Visit Type | Categorizes encounters as office visit, inpatient, emergency, telehealth, or procedure |
| Dimension | Specialty | Groups encounters by clinical specialty (cardiology, orthopedics, primary care, etc.) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Clinical Documentation Assistant |
| **Role** | Medical Documentation Specialist |
| **Goal** | Draft clinical notes from EHR encounter data and clinical guidelines, structured according to organizational templates, for physician review and finalization |
> You are a clinical documentation specialist who drafts medical notes from structured EHR data. You follow organizational note templates and reference clinical practice guidelines to ensure completeness and accuracy. You use precise medical terminology, include all relevant clinical data points (vitals, labs, medications, assessments), and structure notes for downstream coding compliance. You always produce drafts — never final notes — and flag any data gaps that the clinician should address during review.
Grant access to:
* EHR system (encounters, diagnoses, orders, labs, vitals, medications)
* Billing database (claim codes, denial reasons)
* Clinical practice guidelines knowledge space
* Documentation templates knowledge space
* Encounter and Patient objects, Documentation Completion Rate metric
**Trigger:** User asks the agent to draft a progress note for a specific encounter.
1. Retrieve the encounter record from the EHR, including chief complaint, vitals, active medications, and orders.
2. Pull the patient's problem list, recent lab results, and relevant prior encounters.
3. Load the appropriate note template from the documentation templates knowledge space based on visit type.
4. Reference clinical practice guidelines for the primary diagnosis to ensure documentation covers guideline-recommended elements.
5. Draft the note following the SOAP structure (Subjective, Objective, Assessment, Plan) using data from the encounter.
6. Flag any missing data points (e.g., vitals not recorded, labs pending) that the clinician should complete.
7. Return the draft note with flagged items highlighted for review.
**Trigger:** User asks the agent to draft a discharge summary.
1. Retrieve the full inpatient encounter from the EHR, including admission diagnosis, procedures performed, and daily progress.
2. Pull the patient's medication reconciliation, follow-up orders, and discharge instructions.
3. Load the discharge summary template from the documentation templates knowledge space.
4. Compile the hospital course narrative from daily progress entries.
5. Include the discharge medication list, pending lab results, and follow-up appointment details.
6. Return the draft discharge summary formatted for the receiving provider.
**Trigger:** User asks the agent to draft a referral letter to a specialist.
1. Retrieve the referring encounter and the reason for referral from the EHR.
2. Pull the patient's relevant medical history, current medications, and recent diagnostics.
3. Load the referral letter template from the documentation templates knowledge space.
4. Include pertinent positive and negative findings related to the referral reason.
5. Return the draft referral letter addressed to the receiving specialist with all supporting clinical data.
***
## Automation
### Playbook: End-of-day documentation reminder
Set the trigger to **Schedule — Daily** at 6:00 PM to catch encounters with missing documentation before the end of the business day.
The workflow identifies encounters with incomplete documentation and sends reminders:
1. **Query** all encounters from the current day that do not have a finalized note in the EHR system.
2. **Loop** — for each incomplete encounter, pull the encounter details and the assigned provider.
3. **Condition** — check if a draft note already exists. If not, generate a draft using the encounter data and documentation template.
4. **Action** — save the generated draft to the EHR system's note queue for the provider.
5. **Delivery** — notify providers of their outstanding documentation.
* **Email** — send each provider a list of their encounters pending documentation, with links to pre-populated drafts
* **Slack** — post a department-level summary to `#clinical-ops` showing the count of incomplete notes by provider
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Validate medical codes against clinical documentation to reduce claim denials.
See the full list.
# Compliance monitoring
Source: https://docs.wayak.io/use-cases/healthcare/compliance-monitoring
Scan operational data against regulatory requirements on a recurring schedule and alert teams to compliance gaps
Healthcare compliance is not a one-time exercise — it is ongoing surveillance across HIPAA privacy rules, CMS conditions of participation, state licensing requirements, and internal policies. Compliance teams are typically small relative to the scope of what they must monitor. Manual audits are periodic and reactive, which means gaps often surface only when an external auditor finds them or an incident occurs.
Wayak automates compliance monitoring by running scheduled scans across your operational data and checking findings against regulatory requirements stored in a knowledge space. A playbook identifies non-compliant items, scores their severity, and routes alerts to the appropriate teams. An agent lets compliance officers investigate flagged items in real time, pulling supporting documentation and regulatory citations on demand.
***
## What you need
* **Audit database** — compliance check history, findings, remediation actions, and audit schedules
* **EHR system** — patient consent records, access logs, documentation completeness, and training records
* **HR system** — staff credentialing, license expiration dates, and mandatory training completion
* **Regulatory compliance documents** — upload HIPAA regulations, CMS conditions of participation, state-specific requirements, and Joint Commission standards
* **Internal compliance policies** — upload your organization's compliance manual, audit procedures, and incident response protocols
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Object | Compliance Check | Maps to the `compliance_checks` table in the audit database. Represents a single regulatory check with pass/fail status |
| Object | Finding | Maps to `findings` in the audit database. Represents a non-compliant item with severity, owner, and remediation deadline |
| Metric | Compliance Score | Percentage of checks that pass in a given scan period, weighted by severity |
| Metric | Open Findings Count | Total number of unresolved findings, segmented by severity and age |
| Dimension | Regulatory Category | Groups checks by regulation (HIPAA Privacy, HIPAA Security, CMS, State, Internal Policy) |
| Dimension | Severity | Classifies findings as critical, major, minor, or observation |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Compliance Monitor |
| **Role** | Healthcare Compliance Analyst |
| **Goal** | Monitor compliance status across regulatory domains, investigate flagged findings, and provide regulatory guidance with supporting citations |
> You are a healthcare compliance analyst who monitors operational data against regulatory requirements. You identify non-compliant items, assess their severity, and cite the specific regulation or policy section that applies. You provide remediation guidance based on internal compliance policies and track open findings to resolution. You are thorough and precise — every finding includes a regulatory reference and a clear description of the gap.
Grant access to:
* Audit database (compliance checks, findings, remediation tracking)
* EHR system (consent records, access logs, documentation status)
* HR system (credentialing, license dates, training records)
* Regulatory compliance documents knowledge space
* Internal compliance policies knowledge space
* Compliance Check and Finding objects, Compliance Score and Open Findings Count metrics
**Trigger:** User asks the agent for the current compliance status or a summary of open findings.
1. Query the audit database for the most recent compliance scan results.
2. Calculate the overall compliance score using the weighted formula from the semantic layer.
3. Group open findings by regulatory category and severity.
4. Identify the top three areas with the lowest compliance scores.
5. Return a compliance dashboard summary with the overall score, findings breakdown, and priority areas.
**Trigger:** User asks the agent to investigate a specific compliance finding.
1. Retrieve the finding record from the audit database, including the check that generated it.
2. Pull the relevant regulatory text from the regulatory compliance documents knowledge space.
3. Gather the supporting operational data (e.g., the access log entry, the expired credential, the missing consent).
4. Look up the remediation guidance in the internal compliance policies knowledge space.
5. Return a detailed investigation report with the regulatory citation, evidence, remediation steps, and deadline.
**Trigger:** User asks a question about a specific regulation or compliance requirement.
1. Search the regulatory compliance documents knowledge space for the relevant regulation or section.
2. Extract the applicable requirements, definitions, and enforcement guidance.
3. Cross-reference with internal compliance policies for the organization's implementation approach.
4. If the query involves data, pull the relevant operational metrics from the audit database.
5. Return the regulatory text with plain-language interpretation and any supporting data.
***
## Automation
### Playbook: Weekly compliance scan
Set the trigger to **Schedule — Weekly** on Monday at 6:00 AM, providing compliance teams with a fresh report at the start of each week.
The workflow scans operational data across all regulatory domains and generates a findings report:
1. **Query** the EHR system for patient consent records due for renewal, documentation completeness rates, and access log anomalies (e.g., after-hours access by non-clinical staff).
2. **Query** the HR system for staff with credentials or licenses expiring within 30 days and overdue mandatory training.
3. **Query** the audit database for open findings from prior scans and their remediation status.
4. **Condition** — for each check, compare the result against the regulatory requirement. If non-compliant, create or update a finding record with the appropriate severity.
5. **Action** — calculate the overall compliance score and score by regulatory category.
6. **Loop** — for each new critical or major finding, assign an owner based on the department responsible and set a remediation deadline per the internal compliance policy.
7. **Delivery** — distribute the weekly compliance report.
* **Email** — send the full compliance report to the Chief Compliance Officer and department heads
* **Slack** — post a summary to `#compliance` with the overall score, new findings count, and any critical items
* **Email** — send individual finding notifications to assigned owners with deadlines
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Coordinate appointment bookings across providers and departments with automated scheduling logic.
See the full list.
# Healthcare
Source: https://docs.wayak.io/use-cases/healthcare/index
Automate patient intake, streamline clinical documentation, and monitor compliance with AI agents
Healthcare organizations juggle complex clinical workflows, strict regulatory requirements, and growing patient volumes — all while maintaining quality of care. Data lives across EHR systems, scheduling platforms, billing databases, and clinical knowledge bases. Extracting timely insights from these fragmented systems requires significant manual effort, which takes clinicians and staff away from patient care.
Wayak connects your healthcare data sources, applies clinical and operational logic through a semantic layer, and deploys agents that automate documentation, route patients, and monitor compliance. Playbooks handle the repetitive operational tasks — intake processing, appointment coordination, coding validation — so your staff can focus on the work that matters most.
## Use cases
Automate the processing of new patient registrations by validating forms, checking insurance eligibility, and routing to the right department.
Draft clinical notes and summaries from EHR data and clinical guidelines, reducing documentation burden on physicians.
Scan operational data against regulatory requirements on a scheduled basis and alert compliance teams to gaps before audits.
Coordinate appointment bookings across providers and departments using availability data, patient preferences, and scheduling rules.
Validate medical codes against clinical documentation to reduce claim denials and improve reimbursement accuracy.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data sources | EHR system (patient records, encounters, orders), scheduling API (appointments, provider availability), billing database (claims, codes, reimbursements), audit database (compliance checks, findings) |
| Knowledge spaces | Clinical practice guidelines, regulatory compliance documents (HIPAA, CMS), coding manuals (ICD-10, CPT), internal policies and procedures |
| Semantic layer | Objects for patients, encounters, appointments, and claims. Metrics for wait time, no-show rate, coding accuracy, and compliance score. Dimensions for department, provider, insurance type, and visit type |
| Agents | Intake Coordinator for patient registration and routing. Clinical Documentation Assistant for note drafting and coding support |
| Playbooks | Event-triggered intake processing, scheduled compliance scans, appointment reminder workflows, weekly coding accuracy reports |
# Medical coding review
Source: https://docs.wayak.io/use-cases/healthcare/medical-coding-review
Validate medical codes against clinical documentation to reduce claim denials and improve reimbursement accuracy
Medical coding errors are one of the largest sources of revenue leakage in healthcare. Mismatched diagnosis codes, missing modifiers, and unsupported procedure codes lead to claim denials, delayed reimbursements, and compliance risk. Coding teams review hundreds of encounters daily, and the complexity of ICD-10, CPT, and HCPCS coding systems makes manual review both slow and error-prone.
Wayak deploys an agent that cross-references coded claims against the clinical documentation in the EHR, flags discrepancies, and suggests corrections. A playbook runs Python-based validation logic to batch-check coding accuracy across your daily claim submissions, catching errors before claims go out the door.
***
## What you need
* **Billing database** — submitted claims, assigned ICD-10 and CPT codes, modifiers, reimbursement amounts, and denial history
* **EHR system** — encounter records, clinical notes, diagnoses, procedures performed, and order details
* **Coding manuals** — upload ICD-10-CM, CPT, and HCPCS reference materials with code descriptions, inclusion/exclusion notes, and coding guidelines
* **Payer-specific rules** — upload billing requirements for major payers, including documentation standards, modifier rules, and bundling logic
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Object | Claim | Maps to the `claims` table in the billing database. Represents a submitted insurance claim with codes, amounts, and status |
| Object | Encounter | Maps to `encounters` in the EHR. Represents the clinical visit that supports the claim |
| Metric | Coding Accuracy Rate | Percentage of claims where assigned codes match the documented diagnoses and procedures, validated by audit |
| Metric | Denial Rate | Percentage of submitted claims that are denied by payers, segmented by denial reason |
| Dimension | Payer | Groups claims by insurance payer (Medicare, Medicaid, Blue Cross, Aetna, etc.) |
| Dimension | Denial Reason | Classifies denials by category (medical necessity, missing documentation, coding error, authorization) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Coding Review Specialist |
| **Role** | Medical Coding Analyst |
| **Goal** | Validate medical codes against clinical documentation, identify coding errors, suggest corrections, and explain the rationale using coding guidelines and payer rules |
> You are a certified medical coding analyst who reviews claims for accuracy before submission. You cross-reference assigned ICD-10 and CPT codes against the clinical documentation in the encounter record, checking for supported diagnoses, correct modifiers, and proper code sequencing. You flag discrepancies with specific references to coding guidelines and payer rules. You suggest corrected codes when errors are found and explain the rationale. You never submit or modify claims directly — you provide validated recommendations for the coding team.
Grant access to:
* Billing database (claims, codes, denial history)
* EHR system (encounter records, clinical notes, diagnoses, procedures)
* Coding manuals knowledge space
* Payer-specific rules knowledge space
* Claim and Encounter objects, Coding Accuracy Rate and Denial Rate metrics
**Trigger:** User asks the agent to review a specific claim or encounter for coding accuracy.
1. Retrieve the claim record from the billing database, including all assigned diagnosis and procedure codes.
2. Pull the corresponding encounter record from the EHR with clinical notes, diagnoses, and procedures performed.
3. Cross-reference each assigned code against the clinical documentation to verify support.
4. Check code specificity — ensure the most specific ICD-10 code is used (e.g., laterality, episode of care).
5. Validate modifier usage against payer-specific rules from the knowledge space.
6. Check for bundling issues — identify code pairs that should be bundled or require modifier 59.
7. Return a validation report listing each code, its support status, any suggested corrections, and the guideline reference.
**Trigger:** User asks the agent to analyze a denied claim or a batch of denials.
1. Retrieve the denial details from the billing database, including the payer's denial reason code and remarks.
2. Pull the original claim codes and the supporting encounter documentation.
3. Map the denial reason to the payer-specific rules to understand the requirement that was not met.
4. Identify the root cause (missing documentation, unsupported code, authorization gap, or coding error).
5. Recommend the corrective action — whether to appeal with additional documentation, recode, or write off.
**Trigger:** User asks a question about coding rules, guidelines, or payer requirements.
1. Search the coding manuals knowledge space for the relevant code, guideline, or category.
2. Extract the applicable coding rules, inclusion/exclusion notes, and sequencing guidance.
3. Cross-reference with payer-specific rules if the query involves a particular insurance payer.
4. Return the guideline text with a plain-language explanation and examples.
***
## Automation
### Playbook: Daily pre-submission coding audit
Set the trigger to **Schedule — Daily** at 5:00 PM to audit all claims queued for submission the following business day.
The workflow batch-validates coded claims against clinical documentation and flags errors for correction:
1. **Query** all claims in "ready to submit" status from the billing database.
2. **Query** the corresponding encounter records from the EHR system, including clinical notes and procedure details.
3. **Python code block** — run a validation algorithm that cross-references each claim's codes against the encounter data. The code checks for: (a) diagnosis codes supported by the clinical documentation, (b) procedure codes matching documented services, (c) modifier accuracy per payer rules, and (d) bundling conflicts. Each claim receives a validation score and a list of flagged issues.
The **coding validation** step uses a Python code block to perform rule-based cross-referencing of claim codes against encounter documentation. You can customize the validation rules, add payer-specific checks, and adjust the scoring thresholds.
4. **Condition** — if a claim has any flagged issues, hold it from submission and route it to the coding team for correction.
5. **Action** — update the claim status in the billing database (validated, held, or flagged).
6. **Delivery** — distribute the audit results to the coding team.
* **Email** — send the coding team a detailed audit report listing each flagged claim with the specific issues and suggested corrections
* **Slack** — post a summary to `#revenue-cycle` with the count of validated, held, and flagged claims and the overall coding accuracy rate
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Automate patient registration with form validation, insurance checks, and department routing.
See the full list.
# Patient intake automation
Source: https://docs.wayak.io/use-cases/healthcare/patient-intake-automation
Automate new patient registration by validating forms, verifying insurance, and routing to the correct department
Patient intake is the front door of every healthcare organization, and it sets the tone for the entire care experience. Incomplete forms, unverified insurance, and manual data entry create bottlenecks that delay care and frustrate patients. Front-desk staff spend hours each day chasing missing information and re-keying data between systems, which increases error rates and slows throughput.
Wayak automates the intake workflow end to end. A playbook triggers when a new patient registration lands in your EHR system, validates the submitted information against required fields, checks insurance eligibility, and routes the patient to the appropriate department. An agent handles follow-up questions from staff — pulling patient history, verifying coverage details, and flagging incomplete registrations.
***
## What you need
* **EHR system** — patient demographics, medical history, allergies, medications, and emergency contacts
* **Scheduling API** — provider availability, department schedules, and appointment slots
* **Insurance eligibility API** — real-time coverage verification, plan details, copay information, and authorization requirements
* **Registration forms and checklists** — upload required intake forms, consent templates, and data validation rules for each department
* **Insurance and billing policies** — upload payer-specific requirements, pre-authorization rules, and documentation standards
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Object | Patient | Maps to the `patients` table in the EHR system. Represents an individual receiving care |
| Object | Registration | Maps to `registrations` in the intake system. Represents a single intake submission with status and timestamps |
| Metric | Average Intake Time | Mean elapsed minutes from registration submission to department routing, measured across all completed intakes |
| Metric | Incomplete Registration Rate | Percentage of registrations that require follow-up for missing information before routing |
| Dimension | Department | Categorizes registrations by destination department (primary care, specialty, urgent care, imaging) |
| Dimension | Insurance Type | Groups patients by coverage type (commercial, Medicare, Medicaid, self-pay) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Intake Coordinator |
| **Role** | Patient Registration Specialist |
| **Goal** | Validate incoming patient registrations, verify insurance eligibility, identify missing information, and route patients to the correct department |
> You are a patient intake coordinator who ensures every registration is complete, accurate, and properly routed. You validate patient demographics against required fields, verify insurance eligibility using real-time API data, and flag missing or inconsistent information. You are thorough but efficient, prioritizing patient experience by minimizing unnecessary follow-up. You never make clinical decisions — you ensure administrative readiness for care delivery.
Grant access to:
* EHR system (patient demographics, medical history)
* Scheduling API (provider availability, appointment slots)
* Insurance eligibility API (coverage verification, plan details)
* Registration forms and checklists knowledge space
* Insurance and billing policies knowledge space
* Patient and Registration objects, Average Intake Time metric
**Trigger:** User asks the agent to check a specific registration or batch of registrations.
1. Retrieve the registration record from the EHR system.
2. Load the required fields checklist for the target department from the registration forms knowledge space.
3. Compare the submitted data against the required fields and flag any missing or malformed entries.
4. Validate the patient's date of birth, contact information, and emergency contact formats.
5. Check for duplicate patient records in the EHR system using name, date of birth, and identifier matching.
6. Return a validation report listing the registration status (complete/incomplete), missing items, and any duplicate warnings.
**Trigger:** User asks the agent to verify a patient's insurance coverage.
1. Retrieve the patient's insurance information from the registration record.
2. Call the insurance eligibility API with the patient's member ID, date of birth, and plan identifier.
3. Parse the eligibility response for coverage status, effective dates, copay amounts, and deductible remaining.
4. Check whether the planned visit type requires pre-authorization per the insurance and billing policies knowledge space.
5. Return a coverage summary with eligibility status, cost-sharing details, and any authorization requirements.
**Trigger:** User asks the agent where to route a patient.
1. Review the patient's chief complaint, referral source, and visit type from the registration.
2. Check provider availability in the scheduling API for the relevant departments.
3. Match the patient's insurance type to accepted payers for each department.
4. Apply routing rules from the registration forms knowledge space (e.g., referrals to specialty, walk-ins to urgent care).
5. Return the recommended department, next available appointment slot, and any special instructions.
***
## Automation
### Playbook: New patient intake processor
Set the trigger to **Event — New record** on the `registrations` table in the EHR system. The playbook fires each time a patient submits a registration form.
The workflow validates, verifies, and routes each new registration automatically:
1. **Query** the new registration record including patient demographics, insurance information, and visit reason.
2. **Condition** — check whether all required fields are populated. If any are missing, branch to a notification step that sends the patient an email or SMS listing the outstanding items.
3. **Action** — call the insurance eligibility API to verify coverage and parse the response.
4. **Condition** — check eligibility status. If coverage is inactive or the visit requires pre-authorization, branch to a step that creates a follow-up task for the billing team.
5. **Action** — determine the target department based on visit type, referral source, and insurance acceptance.
6. **Action** — update the registration status in the EHR system with the assigned department and eligibility results.
7. **Delivery** — notify the receiving department and the patient.
* **Email/SMS to patient** — confirmation with assigned department, appointment details, and any items still needed
* **Slack** — notify the `#front-desk` channel when a registration is flagged incomplete or has an insurance issue
* **Email** — send the receiving department a summary of the incoming patient with relevant history
Click **Run now** to test with a recent registration, then toggle to **Active**.
***
## What's next
Reduce physician documentation burden by drafting clinical notes from EHR data and guidelines.
See the full list.
# Attrition analysis
Source: https://docs.wayak.io/use-cases/hr/attrition-analysis
Identify turnover patterns by team, tenure, and engagement signals and deliver monthly trend reports
Employee attrition is expensive — recruiting, onboarding, and lost productivity can cost 50-200% of an employee's annual salary. Most HR teams track attrition reactively, compiling spreadsheets after the fact. By the time a pattern is visible, the damage is done.
Wayak connects your HRIS data, runs Python-powered trend analysis in playbooks, and delivers monthly attrition reports with breakdowns by department, tenure band, job level, and manager. Your HR leadership team gets the signals they need to intervene early, backed by data instead of anecdotes.
***
## What you need
* **HRIS database** — Employee records with hire date, termination date, department, job level, manager, compensation band, and exit reason
* **Engagement survey database** — Survey responses with eNPS scores, satisfaction ratings, and open-ended feedback timestamps
* **Performance review database** — Review scores and promotion history
* **Exit interview summaries** — Anonymized exit interview notes uploaded as documents for thematic analysis
* **Retention playbooks** — Internal guides on retention strategies, stay interview templates, and compensation benchmarking references
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| Object | `Employee` | Maps to the HRIS employees table. Represents a current or former employee with their full tenure and role history |
| Metric | `AttritionRate` | Annualized percentage: (terminations in period / average headcount) x 100 |
| Metric | `AverageTenure` | Mean months of employment for terminated employees in the period |
| Dimension | `TenureBand` | Categorization: 0-6 months, 6-12 months, 1-2 years, 2-5 years, 5+ years |
| Dimension | `ExitReason` | Categorization: voluntary-compensation, voluntary-growth, voluntary-relocation, voluntary-other, involuntary-performance, involuntary-restructuring |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ----------------------------------------------------------------------------------- |
| **Name** | People Analytics Agent |
| **Role** | Workforce analytics and retention specialist |
| **Goal** | Identify attrition patterns early and provide data-driven retention recommendations |
> You analyze workforce data to identify attrition trends and risk factors. Present findings with specific numbers — attrition rates, tenure distributions, and department comparisons. Avoid speculation; base every insight on data. When recommending interventions, reference industry benchmarks or internal retention playbooks. Use a neutral, analytical tone appropriate for leadership audiences. Always include period-over-period comparisons so trends are visible.
Grant access to:
* HRIS database (employees, terminations, departments, compensation bands)
* Engagement survey database (eNPS scores, satisfaction ratings)
* Performance review database (review scores, promotion history)
* Exit interview summaries knowledge space
* Retention playbooks knowledge space
* `Employee` object, `AttritionRate` and `AverageTenure` metrics, `TenureBand` and `ExitReason` dimensions
**Trigger:** HR leader asks about attrition trends or monthly review
1. Pull all terminations for the requested period from the HRIS.
2. Calculate the attrition rate for each segment: department, tenure band, job level, and manager.
3. Compare each segment's rate against the company average and the prior period.
4. Identify the top 3 segments with the highest attrition and the top 3 with the largest increase.
5. For each high-attrition segment, break down by exit reason.
6. Search exit interview summaries for recurring themes in those segments.
7. Present findings as a ranked table with rates, trends, and key themes.
**Trigger:** HR leader requests a risk assessment
1. Query the HRIS for all active employees.
2. For each employee, gather: tenure, time since last promotion, latest engagement survey score, performance review trend, and compensation band relative to role midpoint.
3. Flag employees with three or more risk indicators: low eNPS, no promotion in 2+ years, below-midpoint compensation, declining performance reviews.
4. Group flagged employees by department and manager.
5. Recommend targeted actions: stay interviews, compensation reviews, or development conversations.
***
## Automation
### Playbook: Monthly attrition report
Schedule: **First business day of each month at 9:00 AM**.
1. **Query** the HRIS for all terminations in the previous calendar month and calculate the monthly attrition rate.
2. **Query** the same data for the prior 12 months to build a trend line.
3. **Run Python analysis** to calculate:
* Month-over-month and year-over-year attrition rate changes.
* Rolling 3-month average by department.
* Tenure distribution of departures (median, mean, standard deviation).
* Correlation between engagement survey scores and attrition by department.
4. **Condition:** If any department's rolling 3-month attrition rate exceeds 20% annualized, flag it as "critical" and include a deep-dive section.
5. **Query** exit interview summaries for the flagged departments and extract the top 3 themes.
The **trend analysis** step uses a Python code block to compute rolling averages, standard deviations, and correlation coefficients. You can adjust the lookback window and the critical threshold in the code.
Send an email to the HR leadership team and the CHRO with the subject line: "Monthly attrition report — \[Month Year]". Attach a formatted summary with charts. Post a condensed version to the `#people-analytics` Slack channel.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Pair attrition analysis with policy transparency — employees who understand their benefits are more likely to stay.
See the full list.
# HR
Source: https://docs.wayak.io/use-cases/hr/index
Automate recruiting, onboarding, policy support, and workforce analytics with AI agents
HR teams operate across disconnected systems — applicant tracking, HRIS, payroll, and document repositories — while managing everything from candidate pipelines to policy compliance. The manual effort required to screen resumes, coordinate onboarding, answer policy questions, and analyze attrition trends drains time that should go toward strategic people decisions.
Wayak connects your HR data sources and policy documents, applies a semantic layer to define the metrics and relationships that matter, and deploys agents that handle screening, scheduling, Q\&A, and reporting automatically. Playbooks run recurring workflows on schedule so your team can focus on the human side of human resources.
## Use cases
Score candidates against job requirements automatically and surface top matches with structured summaries so recruiters spend time on interviews, not inbox triage.
Generate personalized onboarding checklists when a new hire is confirmed and deliver tasks to the right owners on the right timeline.
Answer employee questions about benefits, PTO, and company policies instantly with citations from the source documents.
Coordinate availability across candidates and interviewers, send calendar invites, and flag conflicts before they cause delays.
Identify turnover patterns by team, tenure, and engagement signals and deliver monthly trend reports with actionable recommendations.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data sources | ATS database (applications, candidates, job requisitions, interview stages), HRIS (employee records, departments, tenure, compensation), calendar API (interviewer availability, room bookings) |
| Knowledge spaces | Employee handbook, benefits guides, PTO policies, onboarding templates, compliance documents, resume uploads |
| Semantic layer | Objects for candidates, employees, job requisitions, and departments. Metrics for time-to-fill, attrition rate, headcount, and offer acceptance rate. Dimensions for department, location, tenure band, and job level |
| Agents | Recruiting Coordinator for candidate screening and interview logistics. People Ops Assistant for policy questions and onboarding support |
| Playbooks | Daily resume screening batches, event-triggered onboarding checklists, weekly interview scheduling digests, monthly attrition trend reports |
# Interview scheduling
Source: https://docs.wayak.io/use-cases/hr/interview-scheduling
Coordinate interviewer availability, send calendar invites, and flag conflicts before they delay your pipeline
Interview scheduling is a coordination bottleneck. Recruiters spend hours cross-referencing calendars, emailing back and forth with candidates, and rebooking when conflicts arise. Every day a candidate waits for a scheduled interview is a day they might accept another offer.
Wayak connects your ATS and calendar API so an agent can check real-time availability, find optimal slots, send invitations, and flag conflicts — all without manual intervention. A weekly playbook ensures no candidate sits in limbo.
***
## What you need
* **ATS database** — Candidates table with interview stage, assigned panel, and recruiter. Job requisitions table with role and department
* **Calendar API** — Interviewer availability, room bookings, and existing meeting blocks (Google Calendar or Outlook)
* **Interview guides** — Structured interview templates by role type (technical, behavioral, case study) with suggested durations
* **Scheduling policies** — Rules for buffer time between interviews, maximum interviews per day per interviewer, and blackout periods
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Object | `Interview` | Maps to the ATS interviews table. Represents a scheduled or pending interview with its participants, time, and format |
| Object | `Interviewer` | Maps to the HRIS employees table filtered by interview panel membership. Represents someone available to conduct interviews |
| Metric | `TimeToSchedule` | Average number of business days between a candidate reaching the interview stage and the interview being confirmed |
| Dimension | `InterviewStage` | Categorization: phone screen, technical interview, hiring manager interview, panel interview, final round |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ----------------------------------------------------------- |
| **Name** | Recruiting Coordinator |
| **Role** | Talent acquisition specialist |
| **Goal** | Move candidates through the pipeline efficiently and fairly |
> You coordinate interviews for the recruiting team. When scheduling, always respect interviewer preferences and buffer times. Propose three time options to candidates whenever possible. Be warm and responsive in candidate-facing communications. Always include the interview format, duration, interviewer names, and any preparation instructions. Flag scheduling conflicts or candidates who have been waiting more than 3 business days proactively.
Grant access to:
* ATS database (candidates, job requisitions, interview stages)
* Calendar API (interviewer availability, room bookings)
* Interview guides knowledge space
* Scheduling policies knowledge space
* `Interview`, `Interviewer` objects and `TimeToSchedule` metric
**Trigger:** Candidate moves to an interview stage or recruiter requests scheduling
1. Retrieve the candidate's assigned interview panel and the required interview format from the ATS.
2. Check the scheduling policies for buffer time, daily limits, and blackout periods.
3. Query the calendar API for each panel member's availability over the next 5 business days.
4. Identify overlapping available windows that meet the duration requirement (e.g., 60 minutes for technical, 45 minutes for phone screen).
5. Rank slots by earliest available date, then by time of day (morning preferred).
6. Return the top 3 options with date, time, duration, room (if in-person), and video link (if remote).
**Trigger:** Recruiter confirms a selected slot
1. Create a calendar event with the confirmed date, time, duration, and participants.
2. Include in the invite: interviewer names and titles, interview format, preparation instructions from the interview guide, and a link to any take-home materials.
3. Send a confirmation email to the candidate with the details and a point of contact for questions.
4. Update the ATS record to reflect the scheduled interview and expected date.
5. Set a reminder for the recruiter 24 hours before the interview.
***
## Automation
### Playbook: Weekly scheduling digest
Schedule: **Every Monday at 7:00 AM**.
1. **Query** the ATS for all candidates currently in an interview stage who do not have a confirmed interview date.
2. **Loop** through each unscheduled candidate:
* Calculate how many business days they have been waiting since reaching the interview stage.
* Check interviewer panel availability for the current week.
3. **Condition:** If a candidate has waited more than 3 business days, flag them as "at risk" and note the blocking reason (no panel availability, candidate unresponsive, or scheduling conflict).
4. **Aggregate** into a summary: total unscheduled interviews, at-risk candidates, and suggested slots for the week.
Send an email to the recruiting team with the subject line: "Weekly scheduling digest — \[date]". Include the at-risk candidates at the top. Post a summary to the `#recruiting` Slack channel.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Automate the step before scheduling — screen candidates and identify who should advance to interviews.
See the full list.
# Onboarding automation
Source: https://docs.wayak.io/use-cases/hr/onboarding-automation
Generate personalized onboarding checklists and deliver tasks to the right owners on the right timeline
A disorganized first week sets the wrong tone. When onboarding relies on manual handoffs between HR, IT, and hiring managers, tasks get missed — equipment arrives late, accounts are not provisioned, and new hires spend their first days waiting instead of learning. The problem compounds when you are onboarding multiple people across different departments and locations.
Wayak connects your HRIS data, onboarding templates, and communication channels so that a single event — a confirmed new hire — triggers a complete, personalized onboarding workflow. The playbook assigns every task to the right owner with the right deadline, and the agent follows up until everything is complete.
***
## What you need
* **HRIS database** — Employee records table with role, department, location, start date, and manager
* **IT asset database** — Equipment inventory and provisioning status
* **Onboarding templates** — Department-specific onboarding checklists with task owners and relative due dates
* **Employee handbook** — Company policies, benefits summaries, and orientation materials
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | -------------------- | ------------------------------------------------------------------------------------------------- |
| Object | `Employee` | Maps to the HRIS employees table. Represents a current or incoming team member |
| Object | `OnboardingTask` | Maps to the onboarding task tracker. Represents a single task with an owner, due date, and status |
| Metric | `TaskCompletionRate` | Percentage of onboarding tasks completed on time per new hire |
| Dimension | `Department` | Categorization by business unit: Engineering, Sales, Marketing, Operations, Finance |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------ |
| **Name** | People Ops Assistant |
| **Role** | Employee experience and onboarding specialist |
| **Goal** | Ensure every new hire has a smooth, complete onboarding experience |
> You manage new hire onboarding end to end. When generating checklists, tailor every task to the hire's role, department, and location. Use a friendly, welcoming tone in all communications directed at the new hire. Be precise with deadlines and task owners. If a task is overdue, escalate to the responsible owner's manager with a clear summary of what is blocked.
Grant access to:
* HRIS database (employees, departments, managers)
* IT asset database (equipment inventory)
* Onboarding templates knowledge space
* Employee handbook knowledge space
* `Employee`, `OnboardingTask` objects and `TaskCompletionRate` metric
**Trigger:** New hire confirmed in HRIS
1. Pull the new hire's role, department, location, start date, and reporting manager from the HRIS.
2. Retrieve the onboarding template for that department from the knowledge space.
3. Customize the template: add role-specific tools, access permissions, and training modules.
4. Assign each task to the responsible owner (IT for equipment, manager for introductions, HR for paperwork, security for badge access).
5. Set due dates relative to the start date (equipment ready 2 days before, orientation on day 1, 30-60-90 day check-ins).
6. Deliver the checklist to the hiring manager and the new hire via email.
**Trigger:** Daily check or manager request
1. Query all onboarding tasks with a status of "pending" and a due date in the past.
2. Group overdue tasks by new hire and by responsible owner.
3. For each overdue task, identify how many days it is past due and what downstream tasks it blocks.
4. Send a reminder to the task owner with the task details and escalation timeline.
5. If a task is more than 3 days overdue, notify the owner's manager and the HR business partner.
***
## Automation
### Playbook: New hire onboarding workflow
Event trigger: **New employee record created** in the HRIS database with a status of "confirmed" and a future start date.
1. **Query** the HRIS for the new hire's full profile: name, role, department, location, start date, and manager.
2. **Query** the onboarding templates knowledge space for the matching department template.
3. **Loop** through each task in the template:
* Personalize the task description with the new hire's name and role.
* Assign the task owner based on the task category (IT, HR, manager, security).
* Calculate the absolute due date from the relative offset and the start date.
* Create the task record in the onboarding tracker.
4. **Condition:** If the start date is less than 5 business days away, mark the checklist as "expedited" and shorten all pre-start deadlines by 50%.
5. **Aggregate** the full checklist into a formatted summary.
The **deadline calculation** step uses a Python code block to compute business-day offsets, accounting for weekends and company holidays. You can customize the holiday calendar in the code.
Send an email to the hiring manager with the full checklist. Send a Slack message to the `#new-hires` channel with the new hire's name, role, start date, and a link to the checklist.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Help new hires (and all employees) get instant answers to policy questions.
See the full list.
# Policy Q&A
Source: https://docs.wayak.io/use-cases/hr/policy-qa
Answer employee questions about benefits, PTO, and company policies instantly with citations from source documents
Employees ask the same policy questions repeatedly — how much PTO do I have, what does my dental plan cover, can I work remotely from another state. HR teams spend hours answering these questions manually, often pulling up the same PDF and scrolling to the same section. Meanwhile, employees wait for a response that could have been instant.
Wayak solves this by indexing your policy documents in a knowledge space with RAG (retrieval-augmented generation). An agent searches the documents, extracts the relevant section, and delivers a plain-language answer with a citation to the exact source. Sensitive topics are automatically escalated to the right HR partner.
***
## What you need
* **HRIS database** — Employee records with department, location, employment type, and benefits enrollment status
* **Employee handbook** — Full company handbook (PDF or DOCX), uploaded and indexed
* **Benefits guides** — Medical, dental, vision, 401(k), and other plan summaries
* **PTO and leave policies** — Vacation, sick leave, parental leave, bereavement, and sabbatical policies
* **Compliance documents** — Remote work agreements, expense policies, code of conduct
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Object | `PolicyDocument` | Maps to the knowledge space index. Represents a single policy document with its version and effective date |
| Object | `Employee` | Maps to the HRIS employees table. Represents the person asking the question, used to personalize answers by location and employment type |
| Metric | `QueriesResolved` | Count of employee questions answered without HR intervention per period |
| Dimension | `PolicyCategory` | Categorization: benefits, PTO, compensation, compliance, remote work, expenses |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------- |
| **Name** | People Ops Assistant |
| **Role** | Employee experience and policy specialist |
| **Goal** | Answer employee questions accurately and route complex issues to the right team |
> You answer employee questions about policies, benefits, and HR processes. Always reference the specific policy document and section when providing an answer. Use a friendly, approachable tone. If a question involves a sensitive topic — termination, harassment, accommodation, or legal matters — do not attempt to resolve it. Acknowledge the question and escalate to the appropriate HR partner immediately. Keep answers factual and cite sources.
Grant access to:
* HRIS database (employees, departments, locations)
* Employee handbook knowledge space
* Benefits guides knowledge space
* PTO and leave policies knowledge space
* Compliance documents knowledge space
* `PolicyDocument`, `Employee` objects and `QueriesResolved` metric
**Trigger:** Employee asks a question about a company policy
1. Identify the policy topic from the question (PTO, benefits, expense, remote work, compensation, leave, etc.).
2. Check whether the question involves a sensitive topic (termination, harassment, accommodation, legal). If yes, skip to step 6.
3. Search the relevant knowledge space for the policy document that covers the topic.
4. Extract the specific section that answers the question and note the document name, section heading, and effective date.
5. Summarize the answer in plain language. Include the citation in the format: "Source: \[Document Name], Section \[X], effective \[date]."
6. If the topic is sensitive, respond with: "This topic requires a conversation with your HR partner. I've flagged this for \[HR partner name] who will follow up within one business day."
**Trigger:** Employee asks about how a policy differs by office or state
1. Identify the policy topic and the locations being compared.
2. Retrieve the policy document for each location from the knowledge space.
3. Extract the relevant sections from each version.
4. Present a side-by-side comparison table showing differences (e.g., PTO days, remote work eligibility, benefits carriers).
5. Note which version applies to the employee based on their HRIS location.
***
## Automation
### Playbook: New policy notification
Event trigger: **New document uploaded** to any policy knowledge space, or manual trigger when HR updates a policy.
1. **Query** the knowledge space for the newly uploaded or updated document.
2. **Compare** the new document against the previous version to identify what changed.
3. **Summarize** the key changes in three to five bullet points, written in plain language.
4. **Condition:** If the policy change affects a specific department or location, filter the recipient list to only those employees.
Send an email to affected employees with the subject line: "Policy update — \[Policy Name]". Include the summary of changes and a link to the full document. Post a message in the `#company-announcements` Slack channel.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Use policy Q\&A alongside automated onboarding to give new hires instant access to answers from day one.
See the full list.
# Resume screening
Source: https://docs.wayak.io/use-cases/hr/resume-screening
Score candidates against job requirements automatically and surface the strongest matches to your recruiting team
Recruiting teams receive hundreds of applications per open role. Manually reviewing each resume takes hours and introduces inconsistency — different reviewers weight different criteria, and qualified candidates slip through the cracks during high-volume periods.
With Wayak, you upload resumes to a knowledge space, connect your ATS data, and configure an agent that scores every candidate against the job requirements. The agent produces structured summaries with clear match ratings, so recruiters spend their time on interviews instead of inbox triage.
***
## What you need
* **ATS database** — Job requisitions table with role title, department, required skills, must-have qualifications, and nice-to-have qualifications
* **HRIS database** — Departments and hiring manager records for routing recommendations
* **Resume uploads** — PDF or DOCX resumes uploaded per requisition batch
* **Job description templates** — Standardized job descriptions with requirements and evaluation criteria
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------ | --------------------------------------------------------------------------------------------------- |
| Object | `Candidate` | Maps to the ATS candidates table. Represents an individual applicant with their application history |
| Object | `JobRequisition` | Maps to the ATS job requisitions table. Represents an open role with its requirements |
| Metric | `MatchScore` | Weighted score (0-100) based on skills match, experience years, and qualification alignment |
| Dimension | `ScreeningOutcome` | Categorization: strong match, partial match, or no match |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ----------------------------------------------------------- |
| **Name** | Recruiting Coordinator |
| **Role** | Talent acquisition specialist |
| **Goal** | Move candidates through the pipeline efficiently and fairly |
> You help the recruiting team manage candidates. When screening resumes, focus on skills and experience — not school names or company prestige. Use clear, structured summaries when presenting candidates. Always include a match rating and a two-sentence justification. Flag any gaps or concerns without disqualifying candidates outright.
Grant access to:
* ATS database (candidates, job requisitions)
* HRIS database (departments, hiring managers)
* Resume uploads knowledge space
* Job description templates knowledge space
* `Candidate`, `JobRequisition` objects and `MatchScore` metric
**Trigger:** New application submitted or recruiter requests a batch screening
1. Retrieve the job requisition and extract must-have skills, nice-to-have skills, minimum experience, and required qualifications.
2. Parse the candidate resume for: years of experience, listed skills, education, certifications, and past role titles.
3. Compare each must-have requirement against the resume and mark it as met, partially met, or not met.
4. Calculate a match score: 60% weight on must-haves, 25% on nice-to-haves, 15% on experience depth.
5. Classify the candidate as strong match (score 75+), partial match (50-74), or no match (below 50).
6. Write a two-sentence summary highlighting the strongest qualification and the biggest gap.
7. If the candidate is a strong match, recommend scheduling a screen and suggest which interview panel fits based on the role's department.
**Trigger:** Recruiter requests a summary of all screened candidates for a requisition
1. Retrieve all candidates screened for the specified job requisition.
2. Sort candidates by match score in descending order.
3. Group into three tiers: strong match, partial match, and no match.
4. For each tier, list candidates with their score, top qualification, and primary gap.
5. Highlight any candidates who match multiple open requisitions.
6. Output a summary table and recommend the top 5 candidates to advance.
***
## Automation
### Playbook: Daily resume screening batch
Schedule: **Daily at 8:00 AM** (runs before the recruiting team's morning standup).
1. **Query** the ATS database for all applications submitted in the last 24 hours.
2. **Loop** through each new application:
* Retrieve the candidate's resume from the knowledge space.
* Retrieve the associated job requisition requirements.
* Run the screening skill to score and classify the candidate.
3. **Condition:** If any candidate scores as a strong match, add them to the priority list.
4. **Aggregate** results into a summary table grouped by requisition.
Send an email to the recruiting team distribution list with the subject line: "Daily screening summary — \[date]". Include the priority candidates at the top and the full results table below.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Once you have screened candidates, automate the interview coordination process.
See the full list.
# Use cases
Source: https://docs.wayak.io/use-cases/index
See how teams use Wayak across industries
Wayak helps teams across industries turn scattered data into automated workflows. Each use case walks you through what to connect, how to set up the agent, and how to put it on autopilot with playbooks.
***
## Browse by industry
Production costs, quality tracking, shift performance, maintenance scheduling, and material variance.
Email drafting, ticket classification, customer history, escalation analysis, and SLA monitoring.
Claims intake, reserve estimation, fraud detection, document classification, and coverage verification.
Resume screening, onboarding automation, policy Q\&A, interview scheduling, and attrition analysis.
Restock recommendations, promotion analysis, assortment optimization, price elasticity, and store benchmarking.
Route efficiency, delivery exceptions, carrier benchmarking, last-mile visibility, and capacity planning.
Loan processing, portfolio risk, regulatory reporting, anomaly detection, and credit scoring.
Patient intake, clinical documentation, compliance monitoring, appointment scheduling, and medical coding.
Asset health monitoring, demand forecasting, outage management, regulatory compliance, and consumption optimization.
Tenant screening, lease management, maintenance tracking, occupancy optimization, and financial reporting.
***
## Popular use cases
A hand-picked selection across industries to get you started fast.
Flag production cost overruns daily with automated variance alerts.
Auto-tag and route support tickets the moment they arrive.
Score claims against fraud indicators and route suspicious ones for review.
Track VaR, concentration, and performance metrics with daily Python-powered alerts.
Predict energy load using meter data and weather patterns.
Prevent stockouts with daily reorder suggestions based on sell-through rates.
***
## How it works
Every use case follows the same three-step pattern.
Each use case lists exactly what data sources and knowledge spaces you need. Connect a database, upload files to the lakehouse, or plug in an API.
Create a [custom agent](/concepts/agents/custom-agents) with the role, goal, and [skills](/concepts/agents/skills) for your use case. Each page gives you the exact configuration to paste in.
Turn the use case into an automated workflow with a [playbook](/concepts/playbooks/what-is-a-playbook) — scheduled reports, real-time alerts, and multi-step pipelines that run without manual effort.
# Claims intake automation
Source: https://docs.wayak.io/use-cases/insurance/claims-intake-automation
Extract claim details from submissions and route them to the correct handler automatically
Claims intake is the bottleneck of the entire claims lifecycle. Every new submission arrives as a mix of forms, documents, emails, and attachments that a human adjuster must read, extract key details from, enter into the system, classify, and route. This process typically takes 30-60 minutes per claim. With hundreds of new claims per day, the backlog grows faster than the team can process it — and every hour of delay frustrates the policyholder.
This use case deploys an event-triggered playbook that processes new claim submissions the moment they arrive. The system extracts policy numbers, loss details, and claimant information from uploaded documents, verifies the policy is active, classifies the claim by type and complexity, and routes it to the appropriate handler — all within minutes.
***
## What you need
* **Claims management system** — Claim records, handler assignments, and status tracking
* **Policy administration system** — Active policies with coverage terms, effective dates, and endorsements
* **Claim documents** — FNOL (First Notice of Loss) forms, police reports, medical bills, and repair estimates uploaded by claimants
* **Underwriting guidelines** — Classification rules and routing criteria by claim type and complexity
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Object | Claim | Maps to the claims management system. Represents a single claim with type, status, claimant, and assigned handler |
| Object | Policy | Maps to the policy administration system. Represents an insurance policy with coverage terms, limits, and effective dates |
| Metric | Intake Cycle Time | Minutes from claim submission to handler assignment |
| Metric | Document Completeness | Percentage of required documents received versus required for the claim type |
| Dimension | Claim Type | Categorizes claims as auto, property, liability, health, or workers' compensation |
| Dimension | Complexity | Classifies claims as simple (single event, clear liability), moderate (multiple parties), or complex (disputed liability, litigation) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ---------------------------------------------------------------- |
| **Name** | Claims Intake Analyst |
| **Role** | Claims intake and classification specialist |
| **Goal** | Process new claims quickly and route them to the correct handler |
> You process incoming insurance claims. Extract key information from submissions: policy number, date of loss, claim type, claimant details, and supporting documents. Classify each claim by type (auto, property, liability, health) and complexity (simple, moderate, complex). Use a formal, precise tone — this is regulated work. Flag any missing documentation immediately and specify exactly what is needed. Never make coverage determinations; your job is to intake and route.
Grant access to:
* Claims management system data source (claim records)
* Policy administration system data source (active policies)
* Claim documents knowledge space
* Underwriting guidelines knowledge space
* Claim and Policy objects in the semantic layer
**Trigger:** New claim documents uploaded or user asks to process a submission
1. Read the uploaded documents from the knowledge space (FNOL forms, police reports, medical bills, repair estimates).
2. Extract key fields: policy number, claimant name, date of loss, loss description, claimed amount, and involved parties.
3. Cross-reference the policy number against the policy administration system to confirm the policy is active and the loss date falls within the coverage period.
4. Classify the claim by type (auto, property, liability, health) based on the loss description.
5. Assess complexity: simple (single event, clear liability), moderate (multiple parties), or complex (disputed liability, potential litigation).
6. List any missing required documents for the claim type.
7. Output a structured claim summary with all extracted fields, classification, and missing document list.
**Trigger:** Claim has been classified and is ready for assignment
1. Read the claim type, complexity, and claimed amount from the intake summary.
2. Look up the routing rules from the underwriting guidelines knowledge space.
3. Match the claim to the appropriate handler queue based on type and complexity.
4. For claims exceeding the high-value threshold, route to a senior adjuster.
5. Assign the claim and update the status in the claims management system.
***
## Automation
### Playbook: New claim intake pipeline
Set the playbook to trigger on a new claim submission event from the claims management system or document upload portal.
The playbook processes the submission end-to-end: extract, validate, classify, and route.
1. **Query step** — Pull the submitted documents and any form data from the claim submission.
2. **AI step** — Extract policy number, claimant details, date of loss, loss description, and claimed amount from the documents.
3. **Query step** — Look up the policy in the policy administration system to verify it is active and the loss date is covered.
4. **Condition step** — If the policy is inactive or the loss date is outside coverage, flag the claim for manual review and stop processing.
5. **AI step** — Classify the claim by type and complexity using the underwriting guidelines.
6. **Action step** — Create the claim record in the claims management system with all extracted fields, classification, and assigned handler.
Send a notification to the assigned handler via email with the claim summary and document links. If any required documents are missing, also send a request to the claimant's email listing exactly what is needed.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Calculate initial reserves based on comparable historical claims.
See the full list.
# Document classification
Source: https://docs.wayak.io/use-cases/insurance/document-classification
Automatically identify and categorize uploaded claim documents by type
Every claim arrives with a stack of documents — FNOL forms, police reports, medical bills, repair estimates, photos, and correspondence. Adjusters spend significant time simply identifying what each document is before they can process it. When documents are mislabeled or filed incorrectly, it causes delays downstream: the adjuster looking for the police report does not realize it was uploaded as "miscellaneous attachment #3."
This use case deploys an agent skill that reads uploaded documents, identifies their type, and categorizes them in the claims management system. When a claimant uploads a batch of files, each one is automatically labeled and linked to the correct claim section. Missing required documents are flagged immediately so the adjuster can request them before the claim stalls.
***
## What you need
* **Claims management system** — Claim records with document attachment fields and required document lists by claim type
* **Document management system (if separate)** — Repository where uploaded documents are stored with metadata fields
* **Claim documents** — The uploaded documents themselves (FNOL forms, police reports, medical bills, repair estimates, photos, correspondence)
* **Document classification guide** — Upload your document type definitions, naming conventions, and examples of each document type
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Object | Claim Document | Maps to document attachment records. Represents a single uploaded file with type, status, and linked claim |
| Object | Claim | Maps to the claims management system. Provides context on what documents are required for each claim type |
| Metric | Document Completeness | Number of received required documents divided by total required documents, as a percentage |
| Metric | Classification Confidence | The confidence level of the automated document type assignment |
| Dimension | Document Type | Categories: FNOL form, police report, medical bill, repair estimate, photo/video, correspondence, identity document, other |
| Dimension | Document Status | Tracks whether a document is received, classified, reviewed, or missing |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ---------------------------------------------------------------------- |
| **Name** | Document Classifier |
| **Role** | Claims document classification specialist |
| **Goal** | Accurately identify, categorize, and organize uploaded claim documents |
> You classify documents uploaded to insurance claims. Read each document and assign it to the correct document type category. Use the document classification guide as your reference. When confidence is low (the document does not clearly match a known type), assign it as "other" and flag it for manual review rather than guessing. After classifying all documents on a claim, check the required document list for the claim type and identify any missing documents. Be precise with document type labels — use the exact categories from the classification guide.
Grant access to:
* Claims management system data source (claim records and document lists)
* Document management system data source (if separate)
* Claim documents knowledge space
* Document classification guide knowledge space
* Claim Document and Claim objects in the semantic layer
**Trigger:** New documents uploaded to a claim or user asks to classify documents
1. Retrieve the uploaded documents from the knowledge space for the specified claim.
2. Read each document and analyze its content, structure, and formatting to determine the document type.
3. Assign each document to a category: FNOL form, police report, medical bill, repair estimate, photo/video, correspondence, identity document, or other.
4. For each classification, note the confidence level: high (clear match), medium (likely match), or low (uncertain).
5. Flag any document classified as "other" or with low confidence for manual review.
6. Update the document record in the claims management system with the assigned type and confidence level.
**Trigger:** After documents are classified or user asks about missing documents
1. Look up the required document list for the claim type from the claims management system.
2. Compare the list of received and classified documents against the required list.
3. Identify any required documents that have not been received.
4. For each missing document, note the document type and its importance to claim processing.
5. Generate a missing document request listing exactly what the claimant needs to provide.
***
## Automation
### Playbook: Auto-classify on upload
Set the playbook to trigger on a document upload event from the claims management system or document portal.
The playbook classifies each uploaded document and updates the claim record immediately.
1. **Query step** — Pull the uploaded document and the associated claim details (claim number, claim type).
2. **AI step** — Analyze the document content and classify it into the appropriate document type using the classification guide.
3. **Action step** — Update the document record in the claims management system with the assigned type and confidence level.
4. **Query step** — Check the required document list for the claim type and determine if any required documents are still missing.
5. **Condition step** — If all required documents are now received, update the claim status to "documents complete." If documents are still missing, add a note listing what is needed.
When all required documents are received, send a notification to the assigned adjuster that the claim is ready for review. If documents are missing after 48 hours, send an automated request to the claimant listing the specific documents needed.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Cross-reference claim details against active policy terms to confirm coverage.
See the full list.
# Fraud pattern detection
Source: https://docs.wayak.io/use-cases/insurance/fraud-pattern-detection
Score claims against known fraud indicators and flag suspicious submissions for investigation
Insurance fraud costs the industry billions annually. Fraudulent claims range from opportunistic exaggeration to organized staged losses, and they are designed to look legitimate. Most fraud detection relies on experienced adjusters noticing something "off" — but with high caseloads, subtle patterns slip through. A claimant with three prior denied claims who files a new one from a different address does not get flagged if nobody checks.
This use case connects your claims data, claimant history, and fraud indicator reference materials to a Wayak agent that reviews claims for red flags. A scheduled playbook runs every new batch of claims through a scoring model that checks multiple fraud indicators, assigns a risk score, and routes high-risk claims to the Special Investigations Unit (SIU). The scoring logic uses Python to weight indicators and produce a transparent, auditable score.
***
## What you need
* **Claims management system** — Current and historical claim records, claimant profiles, and claim payment history
* **Policy administration system** — Policy inception dates, coverage changes, and premium payment history
* **External watch lists (if available)** — Industry fraud databases or shared fraud registries
* **Fraud indicator reference** — Upload your fraud detection criteria, red flag definitions, and investigation thresholds
* **SIU procedures** — Investigation protocols and escalation criteria for the Special Investigations Unit
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------- | ----------------------------------------------------------------------------------------------------- |
| Object | Claim | Maps to the claims management system. Represents a claim with all details needed for fraud screening |
| Object | Claimant Profile | Maps to claimant records with full history. Includes prior claims, denied claims, and address history |
| Metric | Fraud Risk Score | Weighted score based on the number and severity of detected fraud indicators, scaled 0-100 |
| Metric | Indicator Count | Total number of fraud indicators detected on a single claim |
| Dimension | Risk Level | Classifies claims as low risk (0-30), medium risk (31-60), or high risk (61-100) |
| Dimension | Indicator Type | Groups fraud indicators by category: timing, financial, behavioral, documentary |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------ |
| **Name** | Fraud Detection Analyst |
| **Role** | Fraud pattern identification specialist |
| **Goal** | Flag suspicious claims for investigation before payout |
> You review claims for fraud indicators. Compare claim details against known fraud patterns: duplicate claims, inconsistent timelines, inflated values, staged losses, and suspicious claimant histories. Present findings as a risk score with supporting evidence for each indicator. Use precise, objective language — never state that fraud occurred, only that indicators were detected. Always recommend a clear next step: approve, flag for investigation, or request additional documentation. Cite the specific indicator from the fraud reference for each finding.
Grant access to:
* Claims management system data source (current and historical claims)
* Policy administration system data source (policy details and payment history)
* External watch lists data source (if available)
* Fraud indicator reference knowledge space
* SIU procedures knowledge space
* Claim and Claimant Profile objects in the semantic layer
**Trigger:** Claim flagged for review or user requests a fraud screening
1. Pull the claim details including loss description, claimed amount, date of loss, and policy information.
2. Pull the claimant's full history: prior claims, denied claims, claim frequency, and address changes.
3. Check for known fraud indicators: multiple claims in a short period, inconsistent dates between the loss report and supporting documents, claimed amounts significantly above comparable losses, prior denied claims, recent policy changes before the loss.
4. Cross-reference the claimant against external watch lists if available.
5. Assign a weighted risk score from 0-100, with each indicator contributing based on its severity weight from the fraud reference.
6. List each detected indicator with the specific supporting data point and its weight.
7. Recommend a disposition: approve (score 0-30), request additional documentation (score 31-60), or escalate to SIU (score 61-100).
**Trigger:** User asks about fraud patterns across the book of business
1. Pull all claims processed in the specified period with their fraud risk scores.
2. Group by indicator type and count occurrences.
3. Identify any indicator that has increased in frequency compared to the prior period.
4. Break down high-risk claims by region, claim type, and claimant profile characteristics.
5. Present a trend report with indicator frequency, period-over-period change, and top affected segments.
***
## Automation
### Playbook: Batch fraud screening
Schedule the playbook to run twice daily at 7:00 AM and 3:00 PM, or trigger it on each new claim creation event.
The playbook screens new claims against fraud indicators, scores each one, and routes high-risk claims to SIU.
1. **Query step** — Pull all new claims submitted since the last run that have not yet been fraud-screened.
2. **Query step** — For each claim, pull the claimant's full history from the claims management system.
3. **Python code step** — Run each claim through the fraud scoring model. Check all indicators, apply severity weights, and calculate the composite risk score (0-100).
4. **Condition step** — Route based on score: 0-30 (approve, no action), 31-60 (flag for additional documentation), 61-100 (escalate to SIU).
5. **Action step** — Update the claim record with the fraud risk score and detected indicators. For SIU escalations, create an investigation case.
The **Python code step** uses a Python code block to implement the fraud scoring model. Each indicator has a configurable weight, and the composite score is the weighted sum normalized to a 0-100 scale. You can customize indicator weights, add new indicators, and adjust routing thresholds.
For SIU escalations, send an email to the SIU team with the claim summary, risk score, and detailed indicator breakdown. For documentation requests, send an automated letter to the claimant specifying what is needed.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Automatically identify and categorize uploaded claim documents.
See the full list.
# Insurance
Source: https://docs.wayak.io/use-cases/insurance/index
Automate claims intake, estimate reserves, and detect fraud patterns with AI agents
Insurance operations handle high volumes of claims under strict compliance and regulatory requirements. Every claim involves document extraction, policy verification, reserve calculation, and fraud screening — tasks that require pulling data from multiple systems, cross-referencing it, and making time-sensitive decisions. Manual processing is slow, error-prone, and expensive. A missed fraud indicator or a delayed reserve estimate can cost the organization thousands per claim.
Wayak connects your claims management system, policy database, and document repositories into a unified data layer. Agents extract information from uploaded documents, verify coverage, estimate reserves from historical data, and flag suspicious claims — all while keeping humans in the loop for final decisions. Playbooks automate the intake pipeline, so new claims are classified and routed within minutes instead of hours.
## Use cases
Extract policy numbers, loss details, and supporting documents from submissions and route claims to the right handler automatically.
Calculate initial reserve estimates based on comparable historical claims using statistical analysis.
Score claims against known fraud indicators and flag suspicious submissions for investigation.
Identify and categorize uploaded documents — FNOL forms, police reports, medical bills, repair estimates — automatically.
Cross-reference claim details against active policy terms to confirm coverage before processing.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data sources | Claims management system (claim records, claimant history, payment data), policy administration system (active policies, endorsements, exclusions), general ledger (reserve postings) |
| Knowledge spaces | Uploaded claim documents (FNOL forms, police reports, medical bills, repair estimates), policy documents, underwriting guidelines, fraud indicator reference materials |
| Semantic layer | Objects for claims, policies, and claimants. Metrics for reserve amount, fraud risk score, average payout, and cycle time. Dimensions for claim type, severity, region, and status |
| Agents | Claims Intake Analyst for document extraction and routing. Fraud Detection Analyst for risk scoring and investigation recommendations |
| Playbooks | Event-triggered claims intake pipeline, scheduled fraud scans, reserve recalculation workflows |
# Policy coverage verification
Source: https://docs.wayak.io/use-cases/insurance/policy-coverage-verification
Cross-reference claim details against active policy terms to confirm coverage before processing
Before any claim can be processed, the adjuster must verify that the policy covers the reported loss. This means checking that the policy was active on the date of loss, the type of loss is covered, no exclusions apply, the deductible is noted, and the policy limits are sufficient. With complex policies that include endorsements, riders, and exclusions, this verification can take 15-30 minutes per claim — and a mistake can result in paying a claim that should have been denied, or denying one that should have been paid.
This use case deploys an agent that reads the claim details and cross-references them against the policy terms stored in your policy administration system and policy documents knowledge space. The agent checks coverage, flags exclusions, notes deductibles, and presents a clear verification summary that the adjuster can confirm in seconds instead of minutes.
***
## What you need
* **Policy administration system** — Active policies with coverage terms, effective dates, endorsements, exclusions, deductibles, and limits
* **Claims management system** — Claim details including date of loss, loss type, and claimed amount
* **Policy documents** — Upload actual policy wordings, endorsements, and declarations pages for complex or high-value policies
* **Coverage determination guidelines** — Internal rules for interpreting ambiguous coverage scenarios and escalation criteria
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------------ | ------------------------------------------------------------------------------------------------------------- |
| Object | Policy | Maps to the policy administration system. Represents a policy with all coverage terms, limits, and exclusions |
| Object | Claim | Maps to the claims management system. Provides the claim details that need to be verified against the policy |
| Metric | Coverage Match Score | Degree to which the claim's loss type matches the policy's covered perils, expressed as a percentage |
| Metric | Policy Limit Utilization | Claimed amount as a percentage of the applicable policy limit |
| Dimension | Coverage Type | Groups coverage as comprehensive, collision, liability, medical payments, uninsured motorist, etc. |
| Dimension | Exclusion Category | Types of exclusions: named perils, wear and tear, intentional acts, commercial use, pre-existing conditions |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ---------------------------------------------------------------- |
| **Name** | Coverage Verification Agent |
| **Role** | Policy coverage verification specialist |
| **Goal** | Confirm whether a claim is covered under the active policy terms |
> You verify insurance coverage for claims. For each claim, check five things in order: (1) the policy is active on the date of loss, (2) the loss type is a covered peril, (3) no exclusions apply, (4) the deductible amount, and (5) the applicable policy limit. Present your findings as a structured verification checklist. If any item fails, flag it clearly and cite the specific policy clause or exclusion. When coverage is ambiguous, note the ambiguity and recommend escalation to the coverage determination team rather than making a determination yourself. Never approve or deny coverage — you verify and present the facts.
Grant access to:
* Policy administration system data source (policy records with full terms)
* Claims management system data source (claim details)
* Policy documents knowledge space
* Coverage determination guidelines knowledge space
* Policy and Claim objects in the semantic layer
**Trigger:** User asks to verify coverage or a new claim needs coverage check
1. Pull the claim details: policy number, date of loss, loss type, loss description, and claimed amount.
2. Look up the policy in the policy administration system and verify it was active on the date of loss.
3. Check whether the reported loss type matches a covered peril under the policy terms.
4. Review all exclusions on the policy and determine if any apply to the reported loss.
5. Note the applicable deductible amount and whether the claimant has been informed.
6. Compare the claimed amount against the applicable policy limit and sub-limits.
7. Present a structured verification checklist: policy status, coverage match, exclusions, deductible, and limit — with a pass/fail/review-needed status for each item.
**Trigger:** User asks about a policy's coverage or an adjuster needs a quick policy overview
1. Pull the full policy record from the policy administration system.
2. List all covered perils with their corresponding limits and deductibles.
3. List all exclusions and endorsements that modify standard coverage.
4. Note the policy effective dates and any upcoming renewal or cancellation dates.
5. If policy documents are available in the knowledge space, reference specific clauses for complex terms.
6. Present a concise policy summary organized by coverage section.
***
## Automation
### Playbook: Coverage check on new claim
Set the playbook to trigger after the intake pipeline assigns a new claim, or when a claim's status changes to "pending verification."
The playbook verifies coverage automatically and flags any issues before the adjuster begins processing.
1. **Query step** — Pull the claim details from the claims management system: policy number, date of loss, loss type, and claimed amount.
2. **Query step** — Pull the full policy record from the policy administration system, including endorsements and exclusions.
3. **AI step** — Run the five-point coverage verification: policy active, loss covered, no exclusions, deductible noted, limit sufficient.
4. **Condition step** — If all five checks pass, mark the claim as "coverage verified." If any check fails or is ambiguous, flag the claim for manual coverage review.
5. **Action step** — Post the verification results to the claim record as a structured note.
For verified claims, notify the assigned adjuster that coverage is confirmed and the claim is ready for processing. For flagged claims, send a notification to the coverage determination team with the specific items that need manual review.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Automate the end-to-end intake pipeline for new claim submissions.
See the full list.
# Reserve estimation
Source: https://docs.wayak.io/use-cases/insurance/reserve-estimation
Calculate initial claim reserves based on comparable historical claims using statistical analysis
Setting accurate reserves is one of the most consequential tasks in claims management. Under-reserving creates surprise shortfalls that destabilize financial reporting. Over-reserving ties up capital unnecessarily. Most initial reserves are set by adjusters using experience and rough rules of thumb, which introduces inconsistency — two adjusters often set very different reserves for similar claims.
This use case connects your claims history database to a Wayak agent that estimates reserves by analyzing comparable historical claims. A playbook uses Python to run statistical calculations — pulling median payouts, adjusting for claim-specific factors, and generating confidence ranges — so every new claim gets a data-driven reserve estimate within minutes of classification.
***
## What you need
* **Claims management system** — Historical claims with final payout amounts, claim type, severity, region, and resolution details
* **Policy administration system** — Policy limits and deductible amounts for reserve cap calculations
* **General ledger** — Current reserve postings for reconciliation
* **Reserving guidelines** — Upload your actuarial reserving methodology, including adjustment factors and minimum reserve rules
* **Claims benchmarking data** — Industry benchmark payout data by claim type, if available
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------- | ---------------------------------------------------------------------------------------------------------------- |
| Object | Claim | Maps to the claims management system. Represents a claim with type, severity, region, and current reserve amount |
| Object | Historical Payout | Maps to closed claims with final payout data. Used as the basis for comparable analysis |
| Metric | Estimated Reserve | Statistical estimate of expected payout based on comparable historical claims |
| Metric | Average Payout | Mean final payout for closed claims matching a given type, severity, and region |
| Dimension | Severity | Classifies claims by loss magnitude: minor, moderate, significant, severe, catastrophic |
| Dimension | Region | Geographic area where the loss occurred, which affects cost benchmarks |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------ |
| **Name** | Reserve Estimation Agent |
| **Role** | Claims reserve analyst |
| **Goal** | Provide data-driven reserve estimates for new claims based on historical comparables |
> You estimate claim reserves using historical data. When asked to estimate a reserve, always start by identifying the claim type, severity, and region, then pull comparable closed claims. Present the reserve as a range (low, expected, high) with the number of comparable claims used. Explain which adjustment factors you applied and why. Never present a single point estimate without a confidence range. If fewer than 10 comparable claims are available, flag this as low confidence and recommend manual review. Use precise dollar amounts and always note the policy limit as a cap.
Grant access to:
* Claims management system data source (current and historical claims)
* Policy administration system data source (policy limits and deductibles)
* Reserving guidelines knowledge space
* Claim and Historical Payout objects in the semantic layer
**Trigger:** User requests a reserve estimate or a new claim is classified
1. Identify the claim type, severity, and region from the intake summary or user request.
2. Pull historical closed claims matching the same type, severity, and region from the last 3 years.
3. Calculate the median and mean final payout for the comparable set.
4. Adjust for claim-specific factors: documentation quality, liability clarity, injury severity, and claimant history.
5. Apply the adjustment factors from the reserving guidelines knowledge space.
6. Cap the estimate at the policy limit minus the deductible.
7. Present the reserve estimate as a range: low (25th percentile), expected (median), and high (75th percentile) with the number of comparable claims used.
**Trigger:** User asks how accurate past reserves were or wants to validate an estimate
1. Pull closed claims from the specified period with their initial reserve and final payout.
2. Calculate the reserve accuracy ratio: final payout divided by initial reserve.
3. Group by claim type and severity to show where reserves tend to be most and least accurate.
4. Identify systematic biases (consistent over- or under-reserving) by category.
5. Present a summary table with claim type, average initial reserve, average final payout, accuracy ratio, and bias direction.
***
## Automation
### Playbook: Reserve estimate on new claim
Set the playbook to trigger when a new claim is classified and assigned in the claims management system (after the intake pipeline completes).
The playbook pulls comparable claims, runs a statistical reserve calculation, and posts the estimate to the claim record.
1. **Query step** — Pull the new claim's type, severity, region, and policy details.
2. **Query step** — Pull historical closed claims matching the same type, severity, and region from the last 3 years.
3. **Python code step** — Calculate the reserve estimate: compute the median, 25th percentile, and 75th percentile of historical payouts. Apply adjustment factors for documentation quality and liability clarity. Cap at the policy limit.
4. **Condition step** — If fewer than 10 comparable claims were found, flag the estimate as low confidence and add a note for manual review.
5. **Action step** — Post the reserve estimate (low, expected, high) to the claim record in the claims management system.
The **Python code step** uses a Python code block to compute percentile-based reserve estimates and apply adjustment multipliers from your reserving guidelines. You can customize the adjustment factors, the comparable claim window (default 3 years), and the confidence threshold (default 10 comparable claims).
Post the reserve estimate directly to the claim record. Send a notification to the assigned adjuster with the estimate range and confidence level. For low-confidence estimates, also notify the reserving supervisor.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Score claims against known fraud indicators and flag suspicious submissions.
See the full list.
# Capacity planning
Source: https://docs.wayak.io/use-cases/logistics/capacity-planning
Forecast volume by lane, identify capacity constraints, and plan ahead for peak periods
Capacity mismatches are expensive in both directions. Too little capacity means missed deliveries, expedited freight costs, and unhappy customers. Too much means you are paying for trucks and warehouse space you do not need. Most logistics teams plan capacity based on last year's numbers plus a gut-feel adjustment, which fails to account for changing demand patterns and seasonal shifts.
Wayak connects your TMS data, runs Python-powered volume forecasting in playbooks, and delivers capacity planning dashboards that show where your network will be tight — before it happens. Your planning team gets forward-looking visibility instead of backward-looking reports.
***
## What you need
* **TMS database** — Historical shipment records with lane (origin-destination), volume (shipments and weight), dates, and carrier allocation
* **Warehouse management system** — Outbound volume, dock utilization, and staging capacity by facility
* **Carrier capacity data** — Contracted capacity by lane, available spot capacity, and rate trends
* **Demand calendar** — Planned promotions, seasonal peaks, product launches, and known volume spikes
* **Capacity planning guidelines** — Target utilization rates, buffer capacity rules, and lead times for securing incremental capacity
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | --------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Object | `Lane` | Maps to the TMS lane master. Represents an origin-destination pair with its historical volume and carrier assignments |
| Object | `Facility` | Maps to the warehouse master. Represents a distribution center with its throughput capacity and current utilization |
| Metric | `CapacityUtilization` | Actual volume divided by contracted or available capacity, expressed as a percentage per lane or facility |
| Metric | `ForecastedVolume` | Predicted shipment volume for a future period based on historical trends and known demand events |
| Dimension | `PlanningHorizon` | Time-based categorization: next week, next month, next quarter |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------ |
| **Name** | Capacity Planner |
| **Role** | Network capacity and volume forecasting specialist |
| **Goal** | Ensure sufficient capacity across lanes and facilities to meet demand without overspending |
> You forecast shipment volume and identify capacity constraints across the logistics network. When presenting forecasts, always show the methodology: historical baseline, trend adjustment, and known demand events factored in. Present capacity utilization as a percentage with a clear indicator of headroom or shortfall. Use precise numbers — shipment counts, weight, and percentage utilization. When recommending capacity actions, include the lead time required and the estimated cost of securing incremental capacity.
Grant access to:
* TMS database (historical shipments, lanes, carriers)
* Warehouse management system (outbound volume, dock utilization)
* Carrier capacity data (contracted capacity, spot rates)
* Demand calendar knowledge space
* Capacity planning guidelines knowledge space
* `Lane`, `Facility` objects and `CapacityUtilization`, `ForecastedVolume` metrics
**Trigger:** User asks about upcoming volume or quarterly planning
1. Pull historical shipment volume by lane for the past 12 months.
2. Identify the baseline trend: is volume growing, stable, or declining on each lane?
3. Check the demand calendar for known events in the forecast period (promotions, seasonal peaks, new customer onboarding).
4. Adjust the baseline forecast for each known event based on the expected volume impact.
5. Calculate the forecasted volume for each lane for the requested horizon (week, month, or quarter).
6. Compare forecasted volume against contracted carrier capacity on each lane.
7. Flag any lane where forecasted volume exceeds 85% of contracted capacity as "capacity at risk."
**Trigger:** User asks about capacity risks or monthly planning review
1. Run the volume forecast for all lanes and facilities for the next 30 days.
2. Calculate capacity utilization for each lane (forecasted volume versus contracted capacity) and each facility (forecasted outbound versus throughput capacity).
3. Identify constraints: lanes or facilities where utilization exceeds 85%.
4. For each constraint, calculate the gap in units (shipments or pallets) and estimate the cost of securing spot capacity to cover the shortfall.
5. Present a prioritized list of constraints ranked by gap size and cost impact, with recommended actions: secure spot capacity, shift volume to alternate lanes, or negotiate temporary capacity increases.
***
## Automation
### Playbook: Quarterly capacity forecast
Schedule: **First business day of each quarter at 9:00 AM** (runs for Q2 planning on April 1, Q3 on July 1, etc.).
1. **Query** the TMS for historical shipment volume by lane for the past 12 months.
2. **Query** the demand calendar for all known events in the upcoming quarter.
3. **Query** carrier capacity data for contracted capacity by lane.
4. **Run Python analysis** to:
* Fit a trend line to each lane's historical volume using linear regression.
* Apply seasonal adjustment factors derived from the prior year's quarterly patterns.
* Add event-driven volume spikes from the demand calendar.
* Compute the forecasted weekly volume for each lane across the quarter.
* Calculate capacity utilization percentage: forecasted volume versus contracted capacity.
* Identify weeks and lanes where utilization exceeds 85%.
5. **Condition:** If more than 20% of lanes are projected to hit capacity constraints during the quarter, flag the report as "action required" and recommend a capacity procurement review.
6. **Aggregate** into a formatted forecast report: network-level summary, lane-level detail with weekly projections, constraint heatmap, and recommended actions.
The **volume forecasting** step uses a Python code block to run linear regression on historical data, apply seasonal adjustment factors, and project weekly volumes. You can customize the regression lookback window, seasonal adjustment methodology, and the capacity utilization threshold.
Send an email to the VP of Logistics and the capacity planning team with the subject line: "Quarterly capacity forecast — \[Quarter Year]". Attach the full forecast report. Post a summary of the top 5 constrained lanes to the `#capacity-planning` Slack channel.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Optimize the routes within your network to make the most of the capacity you have.
See the full list.
# Carrier benchmarking
Source: https://docs.wayak.io/use-cases/logistics/carrier-benchmarking
Track on-time rates, damage claims, and cost per shipment by carrier to make data-driven allocation decisions
Most logistics teams allocate shipments to carriers based on habit, relationships, or whatever rate was negotiated last quarter. Without a systematic performance comparison, you miss the carriers who are quietly costing you money through late deliveries, damage claims, and inconsistent service.
Wayak connects data from multiple carrier APIs, runs Python-powered weighted scoring in playbooks, and delivers monthly carrier scorecards that rank every provider on the metrics that matter. Your procurement and operations teams get the data they need to renegotiate contracts, reallocate volume, and hold underperformers accountable.
***
## What you need
* **TMS database** — Shipment records with carrier, service level, origin, destination, planned and actual delivery dates, and freight cost
* **Carrier APIs** — Delivery confirmations, tracking events, invoices, and claims data from each carrier
* **Claims database** — Damage claims with carrier, shipment ID, claim amount, resolution status, and date filed
* **Carrier contracts** — Rate agreements, SLA commitments, volume commitments, and penalty clauses for each carrier
* **Carrier evaluation criteria** — Internal scoring methodology, minimum performance thresholds, and benchmarking weights
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------- | ------------------------------------------------------------------------------------------------------------------- |
| Object | `Carrier` | Maps to the carrier master table. Represents a logistics provider with their contract terms and performance history |
| Object | `Shipment` | Maps to the TMS shipments table. Represents a delivery with its carrier assignment, cost, and outcome |
| Metric | `OnTimeRate` | Percentage of shipments delivered on or before the committed delivery date, per carrier |
| Metric | `CostPerShipment` | Total freight cost divided by number of shipments, per carrier and service level |
| Metric | `DamageClaimRate` | Number of damage claims divided by total shipments, expressed as a percentage per carrier |
| Dimension | `ServiceLevel` | Categorization: ground, express, overnight, freight, white glove |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------- |
| **Name** | Carrier Performance Analyst |
| **Role** | Carrier evaluation and procurement support specialist |
| **Goal** | Provide objective, data-driven carrier performance assessments to optimize allocation |
> You evaluate carrier performance using delivery data, cost records, and claims history. Always present comparisons with precise metrics — on-time rate to two decimal places, cost per shipment to the cent, damage rate per thousand shipments. Use weighted scoring to produce an overall performance rank. When recommending changes, estimate the financial impact of reallocating volume. Reference contract SLAs when a carrier is underperforming. Maintain a neutral tone — the data speaks for itself.
Grant access to:
* TMS database (shipments, costs, delivery dates)
* Carrier APIs (tracking events, invoices, claims)
* Claims database (damage claims, resolutions)
* Carrier contracts knowledge space
* Carrier evaluation criteria knowledge space
* `Carrier`, `Shipment` objects and `OnTimeRate`, `CostPerShipment`, `DamageClaimRate` metrics
**Trigger:** Monthly review or user request
1. Pull delivery data for all carriers over the specified period from the TMS and carrier APIs.
2. Calculate per carrier: on-time rate, average transit time, cost per shipment, and damage claim rate.
3. Retrieve the contract SLA thresholds for each carrier from the knowledge space.
4. Flag any carrier performing below their SLA commitment on any metric.
5. Calculate a weighted overall score: 40% on-time rate, 30% cost efficiency, 20% damage rate, 10% average transit time.
6. Rank carriers by overall score and present as a comparison table with a recommendation column: retain, renegotiate, or replace.
**Trigger:** User asks about carrier performance on a specific route or lane
1. Retrieve all shipments for the specified lane (origin-destination pair) across all carriers.
2. Calculate per carrier on that lane: on-time rate, average transit time, cost per shipment, and damage claim rate.
3. Identify the best-performing carrier for that lane based on weighted scoring.
4. Compare the current volume allocation against performance ranking — is the highest-volume carrier also the best performer?
5. Estimate the cost savings or service improvement from reallocating volume to the top-performing carrier on that lane.
***
## Automation
### Playbook: Monthly carrier scorecard
Schedule: **First business day of each month at 9:00 AM**.
1. **Query** the TMS for all shipments completed in the previous calendar month, grouped by carrier.
2. **Query** the claims database for all claims filed in the same period.
3. **Run Python analysis** to calculate:
* On-time rate, average transit time, cost per shipment, and damage claim rate per carrier.
* Weighted overall performance score using the formula: `(on_time * 0.4) + (cost_score * 0.3) + (damage_score * 0.2) + (transit_score * 0.1)` where each component is normalized to a 0-100 scale.
* Month-over-month trend for each carrier's overall score.
* SLA compliance flag: compare each metric against the carrier's contracted threshold.
4. **Condition:** If any carrier's overall score drops below 70 or their on-time rate falls below 95%, flag them as "underperforming" and include a contract review recommendation.
5. **Aggregate** into a scorecard format: overall ranking table, per-carrier detail cards, trend charts, and SLA compliance summary.
The **weighted scoring** step uses a Python code block to normalize each metric to a 0-100 scale and compute the composite score. You can customize the weights and the normalization ranges to match your business priorities.
Send an email to the logistics director and procurement team with the subject line: "Monthly carrier scorecard — \[Month Year]". Attach the full scorecard as a formatted report. Post a summary of the top 3 and bottom 3 carriers to the `#carrier-performance` Slack channel.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Combine carrier performance data with real-time tracking to give customers a unified delivery experience.
See the full list.
# Delivery exception management
Source: https://docs.wayak.io/use-cases/logistics/delivery-exception-management
Automatically detect delays, failed deliveries, and at-risk shipments and alert stakeholders proactively
Delivery exceptions — delays, failed attempts, damaged goods, customs holds — are inevitable in logistics. The problem is not that they happen; it is that they go undetected until a customer calls to complain. By then, the window for mitigation has closed.
Wayak connects your TMS and carrier APIs, scans for exceptions on a schedule, and alerts your operations team and customers before problems escalate. The agent classifies each exception, estimates the impact, and recommends a specific action — escalate, reroute, notify, or hold.
***
## What you need
* **TMS database** — Shipment records with origin, destination, carrier, service level, planned delivery date, and current status
* **Carrier tracking APIs** — Real-time tracking events with timestamps, location, status codes, and exception codes
* **SLA documents** — Service-level agreements by carrier and service type with penalty thresholds and escalation procedures
* **Exception handling procedures** — Internal runbooks for each exception type: who to contact, what to do, and how to communicate to customers
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | --------------- | --------------------------------------------------------------------------------------------------------------------- |
| Object | `Shipment` | Maps to the TMS shipments table. Represents a package or freight movement from origin to destination |
| Object | `Carrier` | Maps to the carrier master table. Represents a logistics provider with their SLAs and performance history |
| Metric | `OnTimeRate` | Percentage of shipments delivered on or before the planned delivery date |
| Metric | `ExceptionRate` | Number of shipments with at least one exception divided by total shipments, expressed as a percentage |
| Dimension | `ExceptionType` | Categorization: carrier delay, address issue, customs hold, weather disruption, capacity shortage, damaged in transit |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------ |
| **Name** | Shipment Tracker |
| **Role** | Shipment visibility and exception specialist |
| **Goal** | Keep stakeholders informed and catch delays before they impact customers |
> You track shipments across carriers and flag exceptions. When reporting status, lead with the headline: on-time, delayed, or at-risk. For delays, always include the cause, the revised ETA, and the impact on downstream commitments. Use a factual, calm tone — even when reporting problems. Proactively suggest mitigation options: reroute, expedite, notify customer, or escalate to carrier. Never minimize the severity of a delay.
Grant access to:
* TMS database (shipments, delivery status, carrier assignments)
* Carrier tracking APIs (real-time tracking events)
* SLA documents knowledge space
* Exception handling procedures knowledge space
* `Shipment`, `Carrier` objects and `OnTimeRate`, `ExceptionRate` metrics
**Trigger:** Scheduled scan or user request
1. Pull all active shipments from the TMS with a planned delivery date within the next 48 hours or a status of delayed/failed.
2. Query carrier tracking APIs for the latest tracking event on each shipment.
3. Classify each exception by type: carrier delay, address issue, customs hold, weather disruption, capacity shortage, or damaged in transit.
4. For each exception, calculate: hours past due (or hours at risk), estimated revenue impact, and SLA penalty exposure.
5. Group exceptions by type and carrier.
6. Recommend an action for each group: escalate to carrier, notify customer, reroute to alternate carrier, or hold for resolution.
7. Output a summary table with shipment ID, origin, destination, carrier, original ETA, revised ETA, exception type, and recommended action.
**Trigger:** User asks about a specific tracking number or shipment ID
1. Retrieve the shipment record from the TMS including origin, destination, carrier, service level, and planned delivery date.
2. Query the carrier tracking API for the full event history.
3. Determine the current status: in transit (on-time), in transit (at-risk), delayed, delivered, or exception.
4. If delayed or at-risk, identify the cause from the latest exception code and estimate the revised ETA.
5. Present the full timeline of tracking events with a status summary and next steps.
***
## Automation
### Playbook: Daily exception scan
Schedule: **Three times daily at 7:00 AM, 12:00 PM, and 5:00 PM** to catch exceptions during each phase of the delivery day.
1. **Query** the TMS for all in-transit shipments and shipments due for delivery within the next 24 hours.
2. **Loop** through each shipment:
* Query the carrier tracking API for the latest event.
* Compare the current location and timestamp against the expected delivery timeline.
* If the shipment is behind schedule by more than 2 hours, flag it as at-risk.
* If the shipment has an exception code, classify it and look up the SLA penalty threshold.
3. **Condition:** If at-risk shipments exceed 5% of today's deliveries, escalate the report to the logistics director in addition to the standard recipients.
4. **Aggregate** results into two groups: exceptions requiring immediate action and at-risk shipments to monitor.
Send a Slack message to `#shipment-exceptions` with the exception count and top-priority items. Send an email to the operations team with the full report. For critical exceptions (SLA breach imminent), send a direct Slack message to the account manager for the affected customer.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Use exception data to benchmark carrier performance and make smarter allocation decisions.
See the full list.
# Logistics
Source: https://docs.wayak.io/use-cases/logistics/index
Optimize routes, track shipments, benchmark carriers, and forecast capacity with AI agents
Logistics teams manage complex networks of carriers, routes, warehouses, and delivery commitments across multiple systems — TMS, GPS tracking, carrier portals, and warehouse management. The data is there, but pulling it together to answer questions like "which routes are underperforming" or "which carrier should we use for this lane" requires hours of manual analysis.
Wayak connects your logistics data sources, applies a semantic layer to define the metrics that drive operational decisions, and deploys agents that analyze routes, catch delivery exceptions, benchmark carriers, and forecast capacity automatically. Playbooks run the recurring analysis so your team spends less time in spreadsheets and more time solving problems.
## Use cases
Compare planned versus actual routes to identify waste, quantify deviations, and prioritize optimization opportunities.
Automatically detect delays, failed deliveries, and at-risk shipments across carriers and alert stakeholders before customers call.
Track on-time rates, damage claims, and cost per shipment by carrier to make data-driven allocation decisions.
Consolidate tracking data from multiple carriers into a single view and keep customers informed with proactive updates.
Forecast volume by lane, identify capacity constraints, and plan ahead for peak periods with scheduled reports.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data sources | TMS database (shipments, routes, delivery status, carrier assignments), GPS/telematics feed (vehicle locations, speed, stops), carrier APIs (tracking events, invoices, claims), warehouse management system (inventory, dock schedules, outbound volume) |
| Knowledge spaces | Carrier contracts, SLA documents, routing guidelines, driver safety manuals, customer delivery requirements |
| Semantic layer | Objects for shipments, routes, carriers, and vehicles. Metrics for on-time delivery rate, cost per mile, route deviation, and capacity utilization. Dimensions for lane, carrier, service level, and exception type |
| Agents | Route Optimizer for route analysis and efficiency improvements. Shipment Tracker for exception management and customer communication |
| Playbooks | Daily delivery exception scans, weekly route efficiency reports, monthly carrier scorecards, quarterly capacity forecasts |
# Last-mile visibility
Source: https://docs.wayak.io/use-cases/logistics/last-mile-visibility
Consolidate tracking data from multiple carriers into a single view and keep customers informed proactively
Last-mile delivery is where customer satisfaction is won or lost. But when you use multiple carriers, tracking data is scattered across different portals and APIs with inconsistent formats and update frequencies. Your customer service team spends their time logging into carrier websites instead of solving problems, and customers get no updates until they call in.
Wayak consolidates tracking data from all your carriers into a single, normalized view. An agent answers "where is my shipment" questions in real time, and a playbook pushes proactive notifications to customers when status changes or delays occur — before they have to ask.
***
## What you need
* **TMS database** — Shipment records with order ID, carrier, tracking number, origin, destination, and committed delivery date
* **Carrier tracking APIs** — Real-time tracking events from all carriers (FedEx, UPS, USPS, regional carriers, LTL providers)
* **Customer database** — Customer contact information, notification preferences, and order history
* **Carrier status code mappings** — Translation tables that map each carrier's proprietary status codes to a normalized set (in transit, out for delivery, delivered, exception)
* **Customer communication templates** — Approved notification templates for shipping confirmation, out-for-delivery, delivered, and delay alerts
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------- | ----------------------------------------------------------------------------------------------------------------- |
| Object | `Shipment` | Maps to the TMS shipments table. Represents a delivery in progress with its normalized tracking status |
| Object | `TrackingEvent` | Maps to the consolidated tracking events table. Represents a single status update with timestamp and location |
| Metric | `ETAAccuracy` | Percentage of shipments where the actual delivery time fell within the committed delivery window |
| Dimension | `DeliveryStatus` | Normalized categorization: label created, picked up, in transit, out for delivery, delivered, exception, returned |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------ |
| **Name** | Shipment Tracker |
| **Role** | Shipment visibility and exception specialist |
| **Goal** | Keep stakeholders informed and catch delays before they impact customers |
> You track shipments across carriers and provide real-time status updates. When someone asks "where is my shipment," respond with the normalized status, current location, and estimated delivery time — not raw carrier codes. For delays, include the cause, the revised ETA, and what is being done about it. Use a factual, calm tone. Proactively mention if other shipments on the same order are also affected. Always provide the tracking number and carrier name for reference.
Grant access to:
* TMS database (shipments, tracking numbers, order IDs)
* All carrier tracking APIs
* Customer database (contact information, preferences)
* Carrier status code mappings knowledge space
* Customer communication templates knowledge space
* `Shipment`, `TrackingEvent` objects and `ETAAccuracy` metric
**Trigger:** User asks about a shipment, tracking number, or order
1. Identify the shipment from the provided tracking number, order ID, or customer name.
2. Query the carrier tracking API for the full event history.
3. Normalize the carrier status codes to the standard set (label created, picked up, in transit, out for delivery, delivered, exception, returned).
4. Determine the current status and location.
5. If in transit, estimate the remaining delivery time based on the current location and the carrier's typical transit speed for this lane.
6. Present the status summary: current status, location, ETA, and a timeline of key events.
**Trigger:** Tracking event indicates a delay or exception
1. Detect the delay from the carrier tracking event (missed scan, exception code, or ETA pushed past the committed date).
2. Classify the delay type: carrier delay, weather, address issue, customs hold, or capacity shortage.
3. Estimate the revised ETA based on the delay type and historical resolution times.
4. Retrieve the customer's notification preferences from the customer database.
5. Draft a notification using the approved delay template, including the revised ETA and a reference number.
6. Send via the customer's preferred channel (email or SMS).
***
## Automation
### Playbook: Proactive delivery status updates
Schedule: **Every 2 hours from 6:00 AM to 10:00 PM** to catch status changes throughout the delivery day.
1. **Query** the TMS for all shipments currently in transit or out for delivery.
2. **Loop** through each shipment:
* Query the carrier tracking API for the latest event.
* Compare the latest event against the last known status in the consolidated tracking table.
* If the status has changed, update the consolidated table and check if a customer notification is warranted.
3. **Condition:** If the new status is "delivered," send a delivery confirmation. If the new status is "exception" or the ETA has slipped past the committed date, send a delay alert.
4. **Aggregate** a summary of all status changes for the operations team: total deliveries confirmed, total delays detected, and total notifications sent.
Customer notifications go via the customer's preferred channel (email or SMS). The operations summary goes to the `#last-mile-ops` Slack channel. If delay notifications exceed 10% of active shipments, send an escalation email to the logistics director.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Go deeper on exception handling with root cause analysis and structured escalation workflows.
See the full list.
# Route efficiency analysis
Source: https://docs.wayak.io/use-cases/logistics/route-efficiency-analysis
Compare planned versus actual routes to identify waste and prioritize optimization opportunities
Every mile of deviation between a planned route and the actual route costs money — fuel, driver hours, and late deliveries. Most logistics teams review route performance manually, if they review it at all. Without a systematic comparison of planned versus actual, inefficiencies become invisible habits.
Wayak connects your TMS and GPS data, runs Python-powered distance and time calculations in playbooks, and delivers route efficiency dashboards that highlight exactly where your network is losing money. The agent identifies deviations, classifies root causes, and recommends specific optimizations.
***
## What you need
* **TMS database** — Planned routes table with origin, destination, planned stops, planned miles, planned time, and assigned vehicle
* **GPS/telematics feed** — Actual vehicle positions, timestamps, stop durations, and actual miles driven
* **Routing guidelines** — Standard operating procedures for route planning, maximum drive times, and delivery window rules
* **Customer delivery requirements** — Specific delivery windows, access instructions, and appointment scheduling rules by customer
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------- | ------------------------------------------------------------------------------------------------------------- |
| Object | `Route` | Maps to the TMS routes table. Represents a planned delivery route with its stops, miles, and time window |
| Object | `Vehicle` | Maps to the fleet master table. Represents a truck or van with its capacity, cost rate, and driver assignment |
| Metric | `RouteDeviation` | Percentage difference between actual miles driven and planned miles: `(actual - planned) / planned * 100` |
| Metric | `CostPerMile` | Total route cost (fuel + driver wages + vehicle depreciation) divided by actual miles driven |
| Dimension | `DeviationCause` | Categorization: traffic, failed delivery attempt, incorrect stop sequence, unplanned stop, road closure |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------ |
| **Name** | Route Optimizer |
| **Role** | Delivery route and fleet analyst |
| **Goal** | Minimize delivery costs and transit times across the network |
> You optimize delivery routes and fleet utilization. When analyzing routes, always factor in distance, traffic patterns, delivery windows, vehicle capacity, and driver hours. Present route recommendations as comparisons — show the current route versus the optimized route with estimated savings. Use precise metrics (miles, hours, dollars). Flag any delivery at risk of missing its window. Never recommend routes that violate driver hours-of-service regulations.
Grant access to:
* TMS database (routes, shipments, stops)
* GPS/telematics feed (vehicle positions, actual miles)
* Routing guidelines knowledge space
* Customer delivery requirements knowledge space
* `Route`, `Vehicle` objects and `RouteDeviation`, `CostPerMile` metrics
**Trigger:** User asks about route performance or daily route review
1. Pull planned route data (miles, stops, time windows) and actual GPS data (miles driven, stop times, arrival times) for the specified period.
2. Calculate route deviation percentage for each route: planned miles versus actual miles.
3. Calculate time deviation: planned transit time versus actual transit time.
4. Identify routes with more than 15% deviation on miles or time.
5. For each deviation, classify the root cause using GPS stop data: traffic delay, failed delivery attempt, incorrect stop sequence, unplanned stop, or road closure.
6. Calculate the cost impact of each deviation: excess miles multiplied by cost per mile.
7. Output a route efficiency table ranked by cost impact, with a flag column for underperforming routes.
**Trigger:** User requests optimization suggestions or a route consistently underperforms
1. Retrieve the historical performance data for the target route over the past 30 days.
2. Identify the most frequent deviation causes and their average cost impact.
3. Analyze stop sequence efficiency: calculate whether reordering stops would reduce total miles.
4. Check delivery windows against historical traffic patterns to identify scheduling conflicts.
5. Propose an optimized route with reordered stops, adjusted departure times, or alternative paths.
6. Estimate the weekly savings if the optimization is adopted.
***
## Automation
### Playbook: Weekly route efficiency report
Schedule: **Every Monday at 7:00 AM**.
1. **Query** the TMS for all completed routes in the previous 7 days.
2. **Query** the GPS feed for actual miles, actual stop times, and arrival timestamps for each route.
3. **Run Python analysis** to calculate:
* Route deviation percentage for each route.
* Total excess miles and excess cost across the fleet.
* Deviation cause classification using GPS stop patterns.
* Week-over-week trend in average route efficiency.
4. **Condition:** If total excess cost exceeds \$5,000 for the week, flag the report as "action required" and highlight the top 5 most costly routes.
5. **Aggregate** into a formatted report: fleet-level summary, route-level detail table, and trend chart.
The **distance and cost calculation** step uses a Python code block to compute great-circle distances between GPS waypoints, aggregate excess miles, and multiply by the per-mile cost rate. You can customize the cost rate and deviation thresholds in the code.
Send an email to the logistics operations manager with the subject line: "Weekly route efficiency — \[date]". Include the fleet summary at the top and the route detail table below. Post a summary to the `#fleet-ops` Slack channel.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Catch the exceptions that cause route deviations before they cascade across your network.
See the full list.
# Manufacturing
Source: https://docs.wayak.io/use-cases/manufacturing/index
Monitor production costs, track quality, and automate shift reporting with AI agents
Manufacturing operations generate massive volumes of data across ERP systems, production databases, CMMS platforms, and quality management systems. The challenge is not collecting this data — it is turning it into timely, actionable decisions. Late cost variance alerts, missed maintenance windows, and undetected defect patterns all eat into margins.
Wayak connects your manufacturing data sources, layers business logic through a semantic layer, and deploys agents that monitor, analyze, and report on production performance automatically. Your team gets answers in seconds instead of hours, and playbooks handle the repetitive analysis that used to require a dedicated analyst.
## Use cases
Compare estimated versus actual costs on production orders and catch overruns before they compound across the shop floor.
Automatically generate OEE summaries at the end of each shift with downtime breakdowns and line-by-line comparisons.
Identify defect patterns across production lines, shifts, and operators to reduce scrap rates and drive corrective actions.
Monitor equipment service dates, flag overdue maintenance by criticality, and alert the right teams before failures occur.
Track actual material consumption against bills of materials to catch waste, substitution errors, and pricing discrepancies.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data sources | ERP system (work orders, BOMs, cost postings), production database (output logs, downtime events), CMMS (maintenance schedules, equipment records), quality management system (defect logs, inspection results) |
| Knowledge spaces | Standard operating procedures (SOPs), quality manuals, equipment maintenance guides, safety checklists |
| Semantic layer | Objects for work orders, production lines, equipment, and materials. Metrics for OEE, cost variance, defect rate, and MTBF. Dimensions for shift, line, operator, and defect category |
| Agents | Production Cost Monitor for cost variance analysis. Quality Assurance Analyst for defect pattern identification |
| Playbooks | Scheduled daily cost variance alerts, end-of-shift OEE reports, daily maintenance scans, weekly material usage summaries |
# Maintenance scheduling
Source: https://docs.wayak.io/use-cases/manufacturing/maintenance-scheduling
Monitor equipment service dates, flag overdue maintenance, and alert teams before failures occur
Unplanned downtime is one of the most expensive problems in manufacturing. A single critical equipment failure can shut down a production line for hours or days. Most plants track maintenance schedules in a CMMS, but the data often sits there until someone remembers to check it. By then, the equipment is already overdue — or already broken.
This use case connects your CMMS data to a Wayak agent that answers maintenance questions on demand and a daily playbook that scans for overdue items and sends alerts sorted by criticality. Critical equipment overdue by more than 7 days triggers an urgent Slack notification so nothing falls through the cracks.
***
## What you need
* **CMMS (Computerized Maintenance Management System)** — Equipment master records, scheduled maintenance dates, work order history, and criticality ratings
* **Production database** — Equipment runtime hours for condition-based maintenance tracking
* **Equipment maintenance guides** — Upload manufacturer maintenance manuals and recommended service intervals
* **Safety checklists** — Lockout/tagout procedures and safety protocols for each equipment class
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------- | ----------------------------------------------------------------------------------------------------- |
| Object | Equipment | Maps to the CMMS equipment master. Represents a single asset with type, location, and criticality |
| Object | Maintenance Task | Maps to scheduled maintenance records. Represents a planned service activity with due date and status |
| Metric | Days Overdue | Current date minus scheduled service date, for tasks that have not been completed |
| Metric | MTBF | Mean time between failures, calculated from historical work order completion dates |
| Dimension | Criticality | Classifies equipment as critical, important, or standard based on production impact |
| Dimension | Equipment Type | Groups assets by class (CNC, press, conveyor, HVAC, electrical) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ----------------------------------------------------------------------------------------- |
| **Name** | Maintenance Monitor |
| **Role** | Equipment maintenance analyst |
| **Goal** | Prevent unplanned downtime by tracking maintenance schedules and flagging overdue service |
> You are an equipment maintenance analyst. When asked about maintenance status, always sort overdue items by criticality first, then by days overdue. Include the equipment name, last service date, days overdue, and criticality rating for each item. For critical equipment that is more than 7 days overdue, clearly mark it as urgent. Reference the manufacturer's recommended service interval from the knowledge space when available. Use direct language and always recommend a specific action: schedule the service, escalate to the maintenance supervisor, or order parts.
Grant access to:
* CMMS data source (equipment master and maintenance task tables)
* Production database data source (runtime hours)
* Equipment maintenance guides knowledge space
* Safety checklists knowledge space
* Equipment and Maintenance Task objects in the semantic layer
**Trigger:** User asks about overdue maintenance or equipment status
1. Query the maintenance schedule for all equipment with upcoming or past-due service dates.
2. Identify any items where the scheduled service date has passed without a completed work order.
3. Calculate days overdue for each item.
4. Sort by days overdue, highest first, with critical equipment at the top.
5. For each overdue item, include equipment name, last service date, days overdue, criticality rating, and recommended service type.
6. If any critical equipment is more than 7 days overdue, add an urgent flag and recommend immediate escalation.
**Trigger:** User asks about equipment health or reliability
1. Pull the maintenance history for the specified equipment or equipment class.
2. Calculate MTBF from the last 12 months of failure records.
3. Compare current runtime hours against the recommended service interval.
4. List the last three completed maintenance tasks with dates and outcomes.
5. Provide a health status: green (on schedule), yellow (approaching due date), or red (overdue).
***
## Automation
### Playbook: Daily maintenance scan
Schedule the playbook to run every day at 5:30 AM, before the maintenance team's morning standup.
The playbook scans all scheduled maintenance, identifies overdue items, and routes alerts based on severity.
1. **Query step** — Pull all maintenance tasks with a scheduled date of today or earlier that have not been completed.
2. **Loop step** — For each overdue task, calculate days overdue and look up the equipment's criticality rating.
3. **Condition step** — Split overdue items into two groups: critical equipment overdue by 7+ days (urgent) and all other overdue items (standard).
4. **Format step** — Build a summary table for each group with equipment name, task type, scheduled date, days overdue, and criticality.
Send the standard overdue report via email to the maintenance supervisor. For urgent items (critical equipment 7+ days overdue), also send a Slack message to the #maintenance-urgent channel with the equipment name and days overdue.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Track actual material consumption against BOMs to catch waste and pricing issues.
See the full list.
# Material usage variance
Source: https://docs.wayak.io/use-cases/manufacturing/material-usage-variance
Track actual material consumption against bills of materials to catch waste and pricing discrepancies
Material costs typically account for 50-70% of total manufacturing cost. Even small variances — an extra kilogram of resin per batch, a substitution at a higher unit price, or a scrap rate that creeps up by half a percent — add up fast across hundreds of production runs. Most teams only catch these during monthly cost reviews, long after the opportunity to intervene has passed.
This use case connects your ERP and inventory data to a Wayak agent that compares actual material consumption against BOM standards. A weekly playbook uses Python to calculate quantity and price variances for every material, flag the largest deviations, and deliver a report your procurement and production teams can act on immediately.
***
## What you need
* **ERP system** — Bills of materials (BOMs) with standard quantities, material issue transactions, and standard cost records
* **Inventory management system** — Current stock levels, material receipts with actual unit prices, and lot tracking data
* **BOM standards documentation** — Upload your standard BOM definitions and approved material substitution lists
* **Procurement policies** — Price variance thresholds and approved vendor lists for reference
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Object | Material Issue | Maps to ERP material issue transactions. Represents a single material withdrawal against a work order |
| Object | BOM Line | Maps to the bill of materials detail table. Represents the planned quantity of a material for one unit of finished good |
| Metric | Quantity Variance | Actual quantity consumed minus standard quantity (from BOM), per work order or batch |
| Metric | Price Variance | (Actual unit price minus standard unit price) multiplied by actual quantity consumed |
| Dimension | Material Type | Groups materials by category: raw materials, packaging, consumables, components |
| Dimension | Supplier | Groups material issues by the vendor who supplied the material lot |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ----------------------------------------------------------------- |
| **Name** | Material Variance Analyst |
| **Role** | Material cost and usage analyst |
| **Goal** | Identify material consumption variances and pricing discrepancies |
> You are a material cost analyst. When analyzing material usage, always separate quantity variance from price variance — they have different root causes and different owners. Present the largest dollar-impact variances first. For quantity variances, check whether a material substitution was made. For price variances, compare against the approved vendor price list. Use specific numbers: show the standard quantity, actual quantity, and difference. When variance exceeds 5% of standard cost, recommend an investigation and specify whether it is a production issue (quantity) or procurement issue (price).
Grant access to:
* ERP system data source (BOMs, material issue transactions, standard costs)
* Inventory management system data source (receipts and pricing)
* BOM standards documentation knowledge space
* Procurement policies knowledge space
* Material Issue and BOM Line objects in the semantic layer
**Trigger:** User asks about material variance, waste, or BOM compliance
1. Identify the work order, product, or material from the user's request.
2. Pull the BOM standard quantities for the finished good.
3. Pull the actual material issue transactions for the specified work orders.
4. Calculate quantity variance for each material line: actual quantity minus standard quantity.
5. Calculate price variance for each material: (actual price minus standard price) multiplied by actual quantity.
6. Sort by total dollar impact, largest first.
7. Present a table with material name, standard quantity, actual quantity, quantity variance, standard price, actual price, and price variance.
**Trigger:** User asks about substitutions or unexpected materials
1. Pull all material issue transactions for the specified work orders.
2. Compare issued material item numbers against the BOM's specified item numbers.
3. Identify any material issued that does not appear on the BOM (potential substitution).
4. Check the substitution against the approved substitution list in the knowledge space.
5. Flag unapproved substitutions and include the cost difference versus the standard material.
***
## Automation
### Playbook: Weekly material variance report
Schedule the playbook to run every Monday at 7:00 AM.
The playbook compiles the previous week's material consumption against BOM standards and highlights the largest variances.
1. **Query step** — Pull all material issue transactions for work orders completed in the previous 7 days, along with corresponding BOM lines.
2. **Python code step** — Calculate quantity variance and price variance for every material-work order combination. Aggregate to material level and rank by total dollar impact.
3. **Condition step** — Filter to materials where total variance exceeds 5% of standard cost or \$500 in absolute terms.
4. **Format step** — Build a report with two sections: top quantity variances (for production review) and top price variances (for procurement review).
The **Python code step** uses a Python code block to compute both quantity and price variances, aggregate them by material, and rank by dollar impact. You can customize the variance thresholds and add trend calculations comparing to the previous week.
Send the full report via email to the production manager and procurement lead. Include the total variance dollar amount in the subject line.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Monitor overall production order costs and catch overruns before they escalate.
See the full list.
# Quality defect analysis
Source: https://docs.wayak.io/use-cases/manufacturing/quality-defect-analysis
Identify defect patterns across production lines, shifts, and operators to reduce scrap rates
Quality issues rarely come from a single source. They emerge from the intersection of materials, machines, operators, and processes. Catching a pattern — like a defect spike every time a specific material lot runs on Line 3 during the night shift — requires cross-referencing data that typically lives in separate systems. By the time someone manually assembles that picture, you have already scrapped hundreds of units.
This use case connects your quality management system and production database to a Wayak agent that analyzes defect patterns on demand. You can ask natural-language questions like "Which line had the highest scrap rate last week?" or "Show me defect trends for product X by shift." The agent pulls from your SOPs knowledge space to recommend corrective actions grounded in your own procedures.
***
## What you need
* **Quality management system** — Defect logs with defect type, severity, line, shift, operator, and timestamp
* **Production database** — Output records to calculate defect rates as a percentage of total production
* **Standard operating procedures (SOPs)** — Upload process-specific SOPs so the agent can reference correct procedures when recommending corrective actions
* **Quality manual** — Your quality standards, acceptable defect thresholds, and escalation criteria
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------- | -------------------------------------------------------------------------------------------------------- |
| Object | Defect Record | Maps to the quality system defect log. Represents a single defect event with type, severity, and context |
| Object | Inspection Result | Maps to inspection records. Represents a pass/fail outcome for a batch or unit |
| Metric | Defect Rate | Total defects divided by total units produced, as a percentage, over a given period |
| Metric | Scrap Cost | Sum of material and labor cost for scrapped units, pulled from ERP cost postings |
| Dimension | Defect Category | Groups defects by root cause type: material, process, operator, machine |
| Dimension | Severity | Classifies defects as critical, major, or minor based on quality standards |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ----------------------------------------------- |
| **Name** | Quality Assurance Analyst |
| **Role** | Quality control specialist |
| **Goal** | Identify defect patterns and reduce scrap rates |
> You are a quality control analyst focused on reducing defect rates. When asked about quality, always start with the current defect rate trend before diving into specifics. Group defects by category (material, process, operator, machine) and highlight the highest-impact area first. Use precise numbers and percentages. Recommend corrective actions based on data and reference the relevant SOP when available. Do not make assumptions about causes you cannot verify from the data.
Grant access to:
* Quality management system data source (defect logs and inspection results)
* Production database data source (output records)
* SOPs knowledge space
* Quality manual knowledge space
* Defect Record and Inspection Result objects in the semantic layer
**Trigger:** User asks about defect trends, quality issues, or scrap rates
1. Identify the time range, product, or line from the user's request, defaulting to the last 30 days if unspecified.
2. Pull all defect records matching the criteria from the quality management system.
3. Calculate the overall defect rate and compare it to the previous period.
4. Group defects by category (material, process, operator, machine) and rank by count.
5. Cross-reference the top defect category with shift and line data to identify correlations.
6. Reference the relevant SOP from the knowledge space and note any deviations that could explain the pattern.
7. Present findings with a summary table and a recommended corrective action.
**Trigger:** User asks for a Pareto chart or top defect causes
1. Pull all defect records for the specified period.
2. Count defects by type and sort in descending order.
3. Calculate the cumulative percentage for each defect type.
4. Identify the defect types that account for 80% of total occurrences.
5. Present the Pareto table with defect type, count, percentage, and cumulative percentage.
***
## Automation
### Playbook: Weekly quality summary
Schedule the playbook to run every Monday at 7:00 AM.
The playbook compiles the previous week's quality data into a summary report with trend comparisons.
1. **Query step** — Pull all defect records and production output for the previous 7 days.
2. **Query step** — Pull the same data for the week before that (for trend comparison).
3. **Format step** — Build a summary showing defect rate by line, top defect categories, and week-over-week change.
4. **Condition step** — If any line's defect rate increased by more than 1 percentage point, add it to a "needs attention" section.
Send the report via email to the quality manager and plant manager. Include the overall defect rate and trend direction in the subject line.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Automate equipment service tracking and get alerts before failures happen.
See the full list.
# Shift performance reporting
Source: https://docs.wayak.io/use-cases/manufacturing/shift-performance-reporting
Generate automated OEE reports at the end of every shift with downtime breakdowns
Shift supervisors need accurate performance data the moment a shift ends, not the next morning after someone manually pulls numbers from three different systems. Delays in reporting mean delays in corrective action — a line running at 60% OEE for an entire second shift because nobody caught the first shift's downtime event.
This use case connects your production database to a Wayak agent that answers shift performance questions on demand and a playbook that automatically generates an OEE report at every shift change. The playbook uses Python to calculate OEE components and compare them against targets.
***
## What you need
* **Production database** — Output logs (units produced, units scrapped per line per shift), downtime event records with cause codes and durations
* **ERP system** — Production schedule with planned output targets per line
* **OEE reference guide** — Upload your OEE calculation methodology and target definitions
* **Downtime cause code manual** — Standard cause codes and their categories (planned, unplanned, changeover)
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | --------------- | ------------------------------------------------------------------------------------------ |
| Object | Production Run | Maps to the production output log. Represents a single line's output during one shift |
| Object | Downtime Event | Maps to the downtime records table. Represents one stoppage with cause, duration, and line |
| Metric | OEE | Availability x Performance x Quality, expressed as a percentage per line per shift |
| Metric | Scrap Rate | Units scrapped divided by total units produced, as a percentage |
| Dimension | Shift | Categorizes data by shift period (Day, Swing, Night) |
| Dimension | Production Line | Groups data by physical production line identifier |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------- |
| **Name** | Shift Performance Analyst |
| **Role** | Production performance analyst |
| **Goal** | Provide real-time shift performance insights and OEE analysis |
> You are a production performance analyst. When asked about shift performance, always start with the OEE number and whether it met the target. Break OEE into its three components (availability, performance, quality) so the user can see which factor drove the result. List downtime events in order of duration, longest first. Use precise numbers and avoid vague language like "approximately." If a line underperformed its target, recommend checking the longest downtime event first.
Grant access to:
* Production database data source (output logs and downtime records)
* ERP system data source (production schedule and targets)
* OEE reference guide knowledge space
* Production Run and Downtime Event objects in the semantic layer
**Trigger:** End of shift or user asks about shift performance
1. Pull production output for the specified shift, including units produced and units scrapped for each line.
2. Retrieve the planned output target for each line from the production schedule.
3. Calculate OEE for each line: availability multiplied by performance multiplied by quality.
4. Compare each line's actual OEE against its target OEE.
5. List any unplanned downtime events with duration, cause code, and affected line.
6. Summarize in a table: line, target OEE, actual OEE, units produced, scrap count, and top downtime cause.
**Trigger:** User asks about downtime patterns or recurring issues
1. Pull downtime events for the specified time range, defaulting to the last 7 days.
2. Group events by cause code and calculate total minutes lost per cause.
3. Rank cause codes by total downtime, highest first.
4. Identify any cause code that appeared on more than two consecutive shifts.
5. Present a ranked table with cause code, occurrence count, total minutes, and affected lines.
***
## Automation
### Playbook: End-of-shift OEE report
Schedule the playbook to run three times daily at shift change times: 6:00 AM, 2:00 PM, and 10:00 PM.
The playbook pulls the last 8 hours of production data, calculates OEE for every line, and delivers a formatted report.
1. **Query step** — Pull all production output records and downtime events for the shift that just ended.
2. **Python code step** — Calculate OEE components for each line using the standard formula.
3. **Condition step** — Flag any line where OEE fell below the target threshold.
4. **Format step** — Build the report with a summary table and a downtime breakdown section.
The **Python code step** uses a Python code block to compute availability (run time / planned production time), performance (actual output / theoretical output), and quality (good units / total units). It multiplies the three to produce OEE. You can customize target thresholds per line.
Send the report via email to the shift supervisor and plant manager. For any line below target, also send a Slack message to the #production-alerts channel.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Identify defect patterns across lines, shifts, and operators to reduce scrap.
See the full list.
# Work order cost tracking
Source: https://docs.wayak.io/use-cases/manufacturing/work-order-cost-tracking
Detect production cost overruns by comparing estimated versus actual work order costs daily
Production cost overruns often go undetected until month-end close, when it is too late to correct the root cause. A single material pricing error or unplanned labor hour can cascade across dozens of work orders. By the time finance flags it, you have already shipped the product at a loss.
This use case connects your ERP work order data to a Wayak agent that calculates cost variance in real time and a playbook that scans for overruns every morning. You get alerts the same day a variance appears, not weeks later.
***
## What you need
* **ERP system (SAP, Oracle, or similar)** — Work order headers with planned costs, posted cost transactions (labor, material, overhead), and BOM details
* **General ledger** — Cost center postings for overhead allocation validation
* **Cost accounting procedures** — Upload your standard costing methodology and variance investigation guidelines
* **Work order templates** — Reference documents for standard cost structures by product type
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | -------------------- | --------------------------------------------------------------------------------------------------------------- |
| Object | Work Order | Maps to the ERP work order header table. Represents a single production order with planned and actual costs |
| Object | Cost Transaction | Maps to posted cost line items. Represents individual labor, material, or overhead charges against a work order |
| Metric | Cost Variance | Actual total cost minus estimated total cost, expressed in currency and as a percentage |
| Metric | Variance by Category | Cost variance broken down by labor, material, and overhead components |
| Dimension | Product Type | Categorizes work orders by finished good type (assembly, fabrication, packaging) |
| Dimension | Cost Center | Groups transactions by the responsible department or production area |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** > **New agent**.
| Field | Value |
| -------- | -------------------------------------------------------------- |
| **Name** | Production Cost Monitor |
| **Role** | Production order analyst |
| **Goal** | Surface cost overruns and variance issues before they escalate |
> You are a production cost analyst. Monitor work orders and flag any where actual costs deviate significantly from estimates. Lead with the numbers — show the variance first, then explain the likely cause. Use direct, factual language. When a variance exceeds 10%, always recommend a specific next step (review labor entries, check material pricing, audit overhead allocation). Do not speculate about root causes you cannot verify from the data.
Grant access to:
* ERP system data source (work order and cost transaction tables)
* General ledger data source (cost center postings)
* Cost accounting procedures knowledge space
* Work Order and Cost Transaction objects in the semantic layer
**Trigger:** User asks about production cost variance or work order costs
1. Identify the work order number from the user's request.
2. Pull the estimated cost from the work order header, including planned labor, planned materials, and planned overhead.
3. Pull the actual cost by summing all posted transactions against the work order.
4. Calculate the total variance as actual cost minus estimated cost.
5. Break the variance into labor, material, and overhead categories.
6. If the total variance exceeds 10%, flag it and list the top three contributing line items.
7. Present results in a table with estimated, actual, and variance columns for each cost category.
**Trigger:** User asks to compare costs across work orders or product types
1. Identify the product type or date range from the user's request.
2. Pull all completed work orders matching the criteria.
3. Calculate the average cost variance percentage for each product type.
4. Rank product types from highest to lowest average variance.
5. Highlight any product type with an average variance above 5%.
6. Present a summary table with order count, average estimated cost, average actual cost, and average variance.
***
## Automation
### Playbook: Daily cost variance alert
Schedule the playbook to run every weekday at 6:00 AM, before the morning production meeting.
The playbook queries all work orders with transactions posted in the last 24 hours, calculates the variance for each, and filters for any exceeding the 10% threshold.
1. **Query step** — Pull all work orders with new cost postings since yesterday.
2. **Python code step** — Calculate variance percentage for each work order and categorize by labor, material, and overhead.
3. **Condition step** — Filter to only work orders where total variance exceeds 10%.
4. **Format step** — Build a summary table with work order number, product, estimated cost, actual cost, variance amount, and variance percentage.
The **Python code step** uses a Python code block to compute variance percentages and categorize overruns by cost type. You can customize the threshold (default 10%) and add additional calculations like rolling averages.
Send the report via email to the production manager and cost accounting team. Include the summary table and a count of flagged work orders in the subject line.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Automate OEE calculations and downtime tracking at the end of every shift.
See the full list.
# Real Estate
Source: https://docs.wayak.io/use-cases/real-estate/index
Automate tenant screening, lease management, and property financial reporting with AI agents
Property management companies and real estate firms manage a constant stream of tenant applications, lease renewals, maintenance requests, and financial obligations across portfolios that may span hundreds of properties. Data lives in property management systems, accounting platforms, tenant portals, and market data feeds — but stitching it together for timely decisions requires manual effort that scales poorly with portfolio size.
Wayak connects your property data sources, applies portfolio and operational logic through a semantic layer, and deploys agents that screen tenants, track leases, and analyze financial performance. Playbooks automate the recurring workflows — application scoring, renewal reminders, maintenance routing, financial reporting — so your property teams manage by exception rather than by spreadsheet.
## Use cases
Score tenant applications using credit, income, and rental history data, and notify applicants with automated decisions.
Track lease expirations, automate renewal outreach, and manage document workflows across your entire portfolio.
Route incoming maintenance requests to the right vendor or team based on urgency, category, and property rules.
Analyze vacancy patterns and market conditions to optimize pricing, marketing, and lease-up strategies.
Generate property-level and portfolio-level financial reports with automated data compilation and variance analysis.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data sources | Property management system (units, leases, tenants, maintenance), accounting database (GL, AP/AR, budgets), credit/background check API (scores, criminal, eviction), market data API (rents, vacancy rates, comparables) |
| Knowledge spaces | Lease templates and legal documents, tenant screening criteria, maintenance vendor contracts, company operating procedures |
| Semantic layer | Objects for properties, units, leases, and tenants. Metrics for occupancy rate, NOI, rent per square foot, and maintenance response time. Dimensions for property type, market, unit type, and lease status |
| Agents | Tenant Screening Analyst for application evaluation. Portfolio Analyst for financial performance and occupancy analysis |
| Playbooks | Event-triggered application scoring, scheduled lease renewal reminders, event-triggered maintenance routing, monthly financial report generation |
# Lease management
Source: https://docs.wayak.io/use-cases/real-estate/lease-management
Track lease expirations, automate renewal outreach, and manage document workflows across your portfolio
Managing leases across a large property portfolio is an exercise in calendar management at scale. Every lease has an expiration date, renewal terms, rent escalation clauses, and notice period requirements. When lease tracking relies on spreadsheets or manual calendar reminders, missed renewals lead to costly vacancies, holdover situations, and lost rent escalation opportunities. The administrative burden grows linearly with portfolio size.
Wayak automates lease lifecycle management. A playbook scans your lease database on a recurring schedule, identifies leases approaching key milestones (notice periods, expirations, rent adjustments), and triggers the appropriate outreach and document workflows. An agent gives property managers instant access to lease details, renewal status, and portfolio-wide lease analytics.
***
## What you need
* **Property management system** — lease records including start/end dates, rent amounts, escalation terms, renewal options, and notice period requirements
* **Accounting database** — tenant payment history, outstanding balances, and late payment frequency
* **Market data API** — comparable rents, vacancy rates, and market trends for rent adjustment decisions
* **Lease templates and legal documents** — upload standard lease agreements, renewal letter templates, rent increase notification templates, and non-renewal notice templates
* **Renewal policies** — upload your renewal criteria, rent escalation guidelines, incentive approval thresholds, and retention strategies by property tier
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Object | Lease | Maps to the `leases` table in the property management system. Represents a lease agreement with terms, dates, and status |
| Object | Unit | Maps to `units` in the property management system. Represents a rentable unit with type, square footage, and current occupancy status |
| Metric | Retention Rate | Percentage of expiring leases that are renewed, measured over a rolling 12-month period |
| Metric | Average Rent Growth | Mean percentage increase in rent at renewal compared to the expiring lease rate |
| Dimension | Lease Status | Classifies leases as active, expiring (within 90 days), month-to-month, or expired |
| Dimension | Property Tier | Groups properties by class (A, B, C) based on location, condition, and amenities |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Name** | Lease Manager |
| **Role** | Lease Administration Specialist |
| **Goal** | Track lease milestones across the portfolio, provide renewal recommendations based on tenant history and market conditions, and answer lease-related queries |
> You are a lease administration specialist managing a multi-property portfolio. You track lease expirations, notice periods, and rent escalation dates proactively. You recommend renewal terms by analyzing the tenant's payment history, market comparables, and the property's renewal policy. You flag leases at risk of non-renewal based on payment patterns and provide retention strategy suggestions. You present data clearly and cite the applicable lease clause or policy when making recommendations.
Grant access to:
* Property management system (leases, units, tenant records)
* Accounting database (payment history, balances)
* Market data API (comparable rents, vacancy rates)
* Lease templates and legal documents knowledge space
* Renewal policies knowledge space
* Lease and Unit objects, Retention Rate and Average Rent Growth metrics
**Trigger:** User asks for a summary of upcoming lease expirations or the current lease pipeline.
1. Query the property management system for all leases expiring within the next 90, 60, and 30 days.
2. Pull tenant payment history and outstanding balances from the accounting database.
3. Flag leases that have passed their notice period deadline without a renewal decision.
4. Group expiring leases by property and identify any concentration risk (e.g., multiple leases expiring simultaneously at one property).
5. Return a pipeline summary with lease count by expiration window, properties with the highest exposure, and leases requiring immediate action.
**Trigger:** User asks for a renewal recommendation for a specific tenant or lease.
1. Retrieve the lease record and tenant profile from the property management system.
2. Pull the tenant's payment history and late payment frequency from the accounting database.
3. Fetch comparable market rents for the unit type and location from the market data API.
4. Load the renewal policy and rent escalation guidelines from the renewal policies knowledge space.
5. Calculate the recommended renewal rent based on market comparables, the escalation clause, and the tenant's retention value.
6. Return a recommendation with the proposed rent, justification, retention risk assessment, and the applicable policy reference.
**Trigger:** User asks about lease performance metrics across the portfolio.
1. Query lease data across all properties for the requested time period.
2. Calculate retention rate, average rent growth, weighted average lease term, and rollover exposure by quarter.
3. Compare metrics against prior year and budget targets.
4. Identify properties with the lowest retention rates or highest vacancy risk.
5. Return a portfolio analytics summary with key metrics, trends, and properties needing attention.
***
## Automation
### Playbook: Lease renewal outreach
Set the trigger to **Schedule — Daily** at 8:00 AM to scan for leases that have entered their renewal action windows.
The workflow identifies leases approaching key milestones and triggers the appropriate outreach:
1. **Query** all active leases from the property management system with their expiration dates, notice periods, and renewal options.
2. **Condition** — identify leases that have entered the 90-day pre-expiration window and do not yet have a renewal decision recorded.
3. **Loop** — for each lease in the renewal window:
* Pull the tenant's payment history from the accounting database.
* Fetch comparable market rents from the market data API.
* Determine the recommended renewal action (renew at current rate, renew with increase, offer incentive, non-renew) based on the renewal policy.
4. **Condition** — if the lease is within 30 days of expiration and no renewal is recorded, escalate to the property manager.
5. **Action** — generate the appropriate outreach letter (renewal offer, rent increase notice, or non-renewal notice) from the lease templates knowledge space.
6. **Delivery** — send outreach and notifications.
* **Email to tenant** — send the renewal offer or notice letter with the proposed terms and response deadline
* **Slack** — post a daily renewal pipeline summary to `#leasing-ops` with the count of leases in each action stage
* **Email** — send property managers a list of leases needing their attention (escalated, overdue, or requiring approval)
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Route and track maintenance requests with automated vendor assignment and escalation.
See the full list.
# Maintenance request tracking
Source: https://docs.wayak.io/use-cases/real-estate/maintenance-request-tracking
Route incoming maintenance requests to the right vendor or team based on urgency, category, and property rules
Maintenance is the day-to-day heartbeat of property management, and how quickly and effectively you handle requests directly impacts tenant satisfaction and retention. When requests come in through portals, phone calls, and emails, they need to be categorized, prioritized, assigned to the right vendor or team, and tracked to completion. Manual triage is slow, inconsistent, and prone to losing requests in the shuffle — especially during high-volume periods like seasonal transitions.
Wayak automates the maintenance workflow from intake to resolution. A playbook triggers on each new request, categorizes it, assigns priority based on your rules, routes it to the appropriate vendor, and escalates if the resolution timeline is exceeded. An agent gives property managers real-time visibility into open requests, vendor performance, and cost tracking.
***
## What you need
* **Property management system** — maintenance request tickets, unit details, tenant information, and request history
* **Vendor management database** — approved vendor list, service categories, response time SLAs, and contract terms
* **Accounting database** — maintenance budgets, work order costs, and invoice history
* **Maintenance procedures** — upload your triage rules, priority definitions (emergency, urgent, routine, cosmetic), routing logic by category and property, and escalation timelines
* **Vendor contracts** — upload active vendor agreements with scope of work, pricing, response time commitments, and contact information
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Object | Maintenance Request | Maps to the `requests` table in the property management system. Represents a tenant-submitted work order with category, priority, and status |
| Object | Vendor | Maps to `vendors` in the vendor management database. Represents an approved service provider with category, SLA, and availability |
| Metric | Average Resolution Time | Mean elapsed hours from request submission to completion, segmented by priority and category |
| Metric | First-Contact Resolution Rate | Percentage of requests resolved on the first vendor visit without a return trip |
| Dimension | Category | Classifies requests by type (plumbing, electrical, HVAC, appliance, structural, cosmetic) |
| Dimension | Priority | Ranks requests as emergency, urgent, routine, or cosmetic based on triage rules |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Maintenance Coordinator |
| **Role** | Property Maintenance Specialist |
| **Goal** | Triage incoming maintenance requests, track resolution progress, provide vendor performance data, and answer maintenance-related queries from property managers |
> You are a property maintenance coordinator who manages work orders across a multi-property portfolio. You categorize and prioritize requests using defined triage rules, assign them to the appropriate vendor based on category, location, and SLA requirements, and track each request to resolution. You flag overdue requests for escalation and monitor vendor performance against contractual SLAs. You provide clear status updates and cost summaries to property managers.
Grant access to:
* Property management system (maintenance requests, unit details, tenant information)
* Vendor management database (vendor list, SLAs, contracts)
* Accounting database (maintenance budgets, work order costs)
* Maintenance procedures knowledge space
* Vendor contracts knowledge space
* Maintenance Request and Vendor objects, Average Resolution Time and First-Contact Resolution Rate metrics
**Trigger:** User asks about the status of a specific request or all open requests.
1. Query the property management system for the specified request or all open requests.
2. Pull the assigned vendor and their response timeline from the vendor management database.
3. Calculate elapsed time and compare against the priority-based SLA from the maintenance procedures knowledge space.
4. Flag any requests that have exceeded their SLA or are approaching the deadline.
5. Return a status summary with request ID, category, priority, assigned vendor, elapsed time, SLA status, and next action.
**Trigger:** User asks about vendor performance or reliability.
1. Query completed maintenance requests for the requested vendor or all vendors over the specified period.
2. Calculate average resolution time, first-contact resolution rate, and SLA compliance rate.
3. Pull cost data from the accounting database and compare against contracted pricing.
4. Rank vendors by performance within each service category.
5. Return a performance report with metrics, rankings, and recommendations for contract renewal or replacement.
**Trigger:** User asks about maintenance spending or budget tracking.
1. Query work order costs from the accounting database for the specified property or portfolio.
2. Break down costs by category, vendor, and priority level.
3. Compare actual spending against the maintenance budget.
4. Identify the top cost drivers and any unusual spending patterns.
5. Return a cost analysis with total spend, budget variance, category breakdown, and top cost items.
***
## Automation
### Playbook: Maintenance request routing
Set the trigger to **Event — New record** on the `requests` table in the property management system. The playbook fires each time a tenant submits a maintenance request.
The workflow triages, assigns, and tracks each new request:
1. **Query** the request details including the tenant's description, unit, property, and any attached photos.
2. **Action** — categorize the request using keyword matching against the triage rules in the maintenance procedures knowledge space (e.g., "water leak" maps to plumbing/emergency, "paint peeling" maps to cosmetic/routine).
3. **Action** — assign priority based on the category and description per the triage rules.
4. **Condition** — if the priority is "emergency," skip normal routing and immediately alert the on-call maintenance team.
5. **Action** — for non-emergency requests, query the vendor management database for approved vendors in the request's category and property location. Select the vendor with the best SLA compliance and availability.
6. **Action** — create the work order assignment in the property management system with the vendor, priority, and SLA deadline.
7. **Delivery** — notify the vendor, tenant, and property manager.
* **Email to vendor** — send the work order with property address, unit number, request details, photos, and SLA deadline
* **Email/SMS to tenant** — confirm receipt with the assigned vendor, expected response time, and a tracking reference number
* **Slack** — post emergency requests to `#maintenance-urgent` immediately; post a daily digest of all new requests to `#maintenance`
Click **Run now** to test with a recent request, then toggle to **Active**.
***
## What's next
Analyze vacancy patterns and market conditions to optimize pricing and lease-up strategies.
See the full list.
# Occupancy optimization
Source: https://docs.wayak.io/use-cases/real-estate/occupancy-optimization
Analyze vacancy patterns and market conditions to optimize pricing, marketing, and lease-up strategies
Vacancy is the most direct drag on property income. Every unoccupied unit represents lost rent, ongoing carrying costs, and marketing expense. But optimizing occupancy requires more than just filling units — it requires pricing them correctly for the market, timing lease starts to avoid seasonal vacancy clusters, and directing marketing spend where it will have the most impact. When these decisions are made on instinct rather than data, the result is either underpriced units leaving money on the table or overpriced units sitting vacant too long.
Wayak connects your property data with market intelligence and runs Python-based analysis in a playbook to produce actionable occupancy and pricing recommendations. An agent gives leasing teams immediate access to vacancy analysis, market comparables, and pricing scenarios so they can make faster, more informed decisions.
***
## What you need
* **Property management system** — unit inventory, current occupancy status, lease start/end dates, asking rents, and concessions offered
* **Market data API** — comparable property rents, vacancy rates, absorption trends, and new supply pipeline
* **Marketing platform** — lead sources, listing views, tour conversion rates, and marketing spend by channel
* **Pricing guidelines** — upload your revenue management policies, including maximum discount thresholds, concession approval rules, and seasonal adjustment factors
* **Market research reports** — upload quarterly market surveys, submarket analysis, and competitor positioning data
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| Object | Unit | Maps to the `units` table in the property management system. Represents a rentable unit with type, square footage, and occupancy status |
| Object | Comparable | Maps to `comparables` in the market data API. Represents a competing property with rent, vacancy, and amenity data |
| Metric | Occupancy Rate | Percentage of total units that are occupied, measured at the property and portfolio level |
| Metric | Effective Rent per Square Foot | (Asking rent - concessions) / unit square footage, annualized |
| Dimension | Unit Type | Classifies units by configuration (studio, 1BR, 2BR, 3BR, commercial, retail) |
| Dimension | Market | Groups properties by submarket or MSA for benchmarking |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Name** | Portfolio Analyst |
| **Role** | Occupancy and Revenue Optimization Specialist |
| **Goal** | Analyze occupancy patterns, benchmark against market conditions, recommend pricing adjustments, and support leasing strategy decisions with data |
> You are a portfolio analyst specializing in occupancy and revenue optimization for a multi-property real estate portfolio. You analyze vacancy trends, compare asking rents against market comparables, and identify pricing opportunities at the unit and property level. You evaluate marketing channel effectiveness and recommend budget allocations based on lead conversion data. You present recommendations with supporting market data and financial projections so decision-makers can act with confidence.
Grant access to:
* Property management system (units, occupancy, leases, rents)
* Market data API (comparables, vacancy rates, absorption)
* Marketing platform (leads, conversions, marketing spend)
* Pricing guidelines knowledge space
* Market research reports knowledge space
* Unit and Comparable objects, Occupancy Rate and Effective Rent per Square Foot metrics
**Trigger:** User asks about current vacancy, occupancy trends, or exposure risk.
1. Query the property management system for all units with their current occupancy status and lease expiration dates.
2. Calculate the current occupancy rate and project 30/60/90-day vacancy exposure from upcoming expirations.
3. Identify unit types and properties with the highest vacancy concentrations.
4. Compare occupancy against the market vacancy rate from the market data API.
5. Return a vacancy analysis with current occupancy, projected exposure, problem areas, and market context.
**Trigger:** User asks for a pricing recommendation for a specific unit, unit type, or property.
1. Retrieve the unit details and current asking rent from the property management system.
2. Pull comparable rents for similar units in the submarket from the market data API.
3. Load the pricing guidelines from the knowledge space, including maximum discount and seasonal factors.
4. Calculate the recommended rent range based on comparables, time on market, and seasonal adjustments.
5. Estimate the revenue impact of pricing at the low, mid, and high end of the range.
6. Return a pricing recommendation with the suggested rent, comparable support, revenue scenarios, and the applicable guideline reference.
**Trigger:** User asks about marketing effectiveness or where to spend the leasing budget.
1. Pull lead volume, tour conversion rate, and lease conversion rate by marketing channel from the marketing platform.
2. Calculate cost per lead and cost per lease for each channel.
3. Identify the highest-performing and lowest-performing channels.
4. Compare channel performance by property and unit type.
5. Return a channel analysis with performance rankings, cost efficiency metrics, and reallocation recommendations.
***
## Automation
### Playbook: Weekly occupancy and pricing review
Set the trigger to **Schedule — Weekly** on Tuesday at 7:00 AM, giving leasing teams updated recommendations for the week.
The workflow analyzes occupancy and pricing across the portfolio and flags units needing attention:
1. **Query** all units from the property management system with current occupancy status, asking rent, days on market, and lease expiration schedule.
2. **Query** the market data API for current comparable rents, submarket vacancy rates, and absorption trends.
3. **Python code block** — compute pricing recommendations for each vacant unit. The code compares the asking rent against the weighted average of comparable rents, applies a days-on-market decay factor (suggesting a reduction for units vacant longer than 30 days), and adjusts for seasonal demand patterns. It produces a recommended rent, a confidence score, and the estimated revenue impact of the adjustment.
The **pricing optimization** step uses a Python code block to compute market-adjusted rent recommendations with days-on-market decay and seasonal adjustments. You can customize the comparable weighting, decay rate, and seasonal factors.
4. **Condition** — flag any unit where the recommended rent differs from the current asking rent by more than 5%.
5. **Loop** — for each flagged unit, generate a brief pricing rationale with comparable support.
6. **Delivery** — distribute the weekly occupancy and pricing report.
* **Email** — send each property manager their property's occupancy summary, pricing recommendations, and flagged units
* **Slack** — post a portfolio-wide occupancy snapshot to `#leasing-ops` with overall occupancy rate, week-over-week change, and the count of units with pricing flags
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Generate automated financial reports with variance analysis across your property portfolio.
See the full list.
# Property financial reporting
Source: https://docs.wayak.io/use-cases/real-estate/property-financial-reporting
Generate property-level and portfolio-level financial reports with automated data compilation and variance analysis
Property financial reporting is a monthly obligation that consumes significant accounting and asset management time. Each property requires an income statement, balance sheet metrics, NOI calculation, budget variance analysis, and capital expenditure tracking. Across a multi-property portfolio, the data lives in accounting systems, property management platforms, and budget spreadsheets — and compiling it into investor-ready reports is a manual, error-prone process that often extends well past month-end close.
Wayak automates financial report generation by connecting your accounting and property data, running Python-based calculations for NOI, variance analysis, and key performance indicators, and delivering formatted reports on a monthly schedule. An agent gives asset managers instant access to property financials, letting them drill into line items and investigate variances without waiting for the reporting cycle.
***
## What you need
* **Accounting database** — general ledger entries, accounts payable, accounts receivable, revenue postings, and expense classifications by property
* **Property management system** — unit count, occupied units, rent rolls, concessions, and tenant charges
* **Budget system** — annual operating budgets and capital budgets by property and line item
* **Reporting templates** — upload your standard property financial report template, investor report format, and chart of accounts mapping
* **Accounting policies** — upload your revenue recognition rules, expense capitalization thresholds, and reserve policies
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Object | Property | Maps to the `properties` table in the property management system. Represents a real estate asset with location, type, and unit count |
| Object | GL Account | Maps to `accounts` in the accounting database. Represents a general ledger account with category and normal balance |
| Metric | Net Operating Income (NOI) | Total revenue - total operating expenses, excluding debt service and capital expenditures |
| Metric | Budget Variance | (Actual - Budget) / Budget, expressed as a percentage for each line item |
| Dimension | Expense Category | Groups expenses by type (payroll, maintenance, utilities, insurance, taxes, management fees) |
| Dimension | Revenue Category | Groups revenue by type (base rent, other income, parking, late fees, utility reimbursements) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Name** | Property Financial Analyst |
| **Role** | Real Estate Financial Reporting Specialist |
| **Goal** | Compile property financial data, calculate NOI and key performance metrics, analyze budget variances, and answer financial queries from asset managers |
> You are a real estate financial reporting specialist who compiles and analyzes property-level financial performance. You calculate NOI, budget variance, and key operating metrics from accounting and property management data. You explain variances by tracing them to specific line items and operational drivers (e.g., higher turnover costs, utility rate increases). You present financial data in a clear, investor-ready format and reference accounting policies when applying recognition or capitalization rules. You prepare reports for review — final approval is always a human responsibility.
Grant access to:
* Accounting database (GL entries, AP/AR, revenue, expenses)
* Property management system (rent rolls, occupancy, tenant charges)
* Budget system (operating and capital budgets)
* Reporting templates knowledge space
* Accounting policies knowledge space
* Property and GL Account objects, NOI and Budget Variance metrics
**Trigger:** User asks for the financial performance of a specific property or the portfolio.
1. Query the accounting database for all revenue and expense postings for the specified property and period.
2. Pull occupancy and rent roll data from the property management system.
3. Aggregate revenue by category (base rent, other income, reimbursements).
4. Aggregate expenses by category (payroll, maintenance, utilities, insurance, taxes, management fees).
5. Calculate NOI and operating expense ratio.
6. Return a formatted income statement with revenue, expenses, NOI, and key operating ratios.
**Trigger:** User asks about budget variance for a property, line item, or the portfolio.
1. Pull actual financial results from the accounting database for the specified period.
2. Pull the corresponding budget figures from the budget system.
3. Calculate variance (actual vs. budget) for each line item, both in dollars and as a percentage.
4. Identify the top three favorable and unfavorable variances.
5. For each significant variance, trace the cause to operational data (e.g., higher vacancy, unplanned repair, rate change).
6. Return a variance report with line-by-line comparison, top variances, and explanations.
**Trigger:** User asks for a portfolio-wide financial overview.
1. Query financial data across all properties for the specified period.
2. Calculate portfolio NOI, weighted average occupancy, and total revenue growth.
3. Rank properties by NOI margin, NOI growth, and budget adherence.
4. Identify the strongest and weakest performers.
5. Return a portfolio summary with aggregate metrics, property rankings, and properties requiring management attention.
***
## Automation
### Playbook: Monthly property financial report
Set the trigger to **Schedule — Monthly** on the 10th of each month, after the prior month's books are closed and GL entries are finalized.
The workflow compiles financial reports for every property and generates a portfolio summary:
1. **Query** the accounting database for all revenue and expense GL entries for the prior month, segmented by property.
2. **Query** the property management system for month-end occupancy, rent roll, and concession data for each property.
3. **Query** the budget system for the corresponding monthly budget figures by property and line item.
4. **Python code block** — compute NOI, operating expense ratio, budget variance, and year-over-year growth for each property. The code also generates a portfolio roll-up with weighted average metrics and ranks properties by NOI performance. For each line item with a variance exceeding 10%, the code flags it and includes the prior-month and prior-year figures for context.
The **financial calculations** step uses a Python code block to compute NOI, budget variance percentages, and portfolio-level aggregations. You can customize the variance threshold for flagging, the chart of accounts mapping, and the report formatting.
5. **Condition** — if any property has a total NOI variance exceeding 15% from budget, flag it for asset manager review.
6. **Action** — format the data into the property financial report template from the reporting templates knowledge space.
7. **Delivery** — distribute property and portfolio reports.
* **Email** — send each asset manager their properties' financial reports with variance highlights
* **Email** — send the portfolio summary to the VP of Asset Management and the investment committee
* **Slack** — post a portfolio snapshot to `#asset-management` with total NOI, occupancy, and the count of flagged properties
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Automate tenant application scoring with credit checks and configurable screening criteria.
See the full list.
# Tenant screening
Source: https://docs.wayak.io/use-cases/real-estate/tenant-screening
Score tenant applications using credit, income, and rental history data for faster, more consistent leasing decisions
Tenant screening is one of the most repetitive and high-stakes tasks in property management. Each application requires pulling credit reports, verifying income, checking eviction and criminal records, and comparing results against your screening criteria. When this is done manually, turnaround times stretch to days, criteria are applied inconsistently across properties, and good applicants lose patience and sign elsewhere.
Wayak automates the screening workflow. A playbook triggers on each new application, pulls data from your credit and background check APIs, scores the applicant against your configurable criteria, and sends notifications to both the leasing team and the applicant. An agent gives leasing managers instant access to application details, scoring breakdowns, and historical approval patterns.
***
## What you need
* **Property management system** — tenant applications, unit availability, lease terms, and applicant contact information
* **Credit/background check API** — credit scores, payment history, eviction records, and criminal background results
* **Accounting database** — current tenant payment history and collections data for reference comparisons
* **Tenant screening criteria** — upload your screening standards by property and unit type, including minimum credit score, income-to-rent ratio, eviction lookback period, and disqualifying conditions
* **Fair housing guidelines** — upload federal and local fair housing requirements to ensure screening criteria comply with anti-discrimination regulations
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Object | Application | Maps to the `applications` table in the property management system. Represents a single tenant application with applicant details and status |
| Object | Tenant | Maps to `tenants` in the property management system. Represents a current or former tenant with lease and payment history |
| Metric | Approval Rate | Percentage of applications approved over a rolling 30-day period, segmented by property and unit type |
| Metric | Average Screening Time | Mean elapsed hours from application submission to decision notification |
| Dimension | Property | Groups applications by property name and location |
| Dimension | Decision Outcome | Classifies applications as approved, conditionally approved, denied, or withdrawn |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Tenant Screening Analyst |
| **Role** | Leasing Application Reviewer |
| **Goal** | Evaluate tenant applications against screening criteria, explain scoring decisions, and provide leasing teams with actionable application summaries |
> You are a tenant screening analyst who evaluates rental applications against defined criteria. You pull credit, background, and income data and score each application consistently using the property's screening standards. You explain every scoring decision by citing the specific criteria that the applicant met or failed. You flag any fair housing considerations and never make final approval decisions — you present a scored recommendation for the leasing manager to act on.
Grant access to:
* Property management system (applications, units, lease terms)
* Credit/background check API (credit scores, eviction records, criminal checks)
* Accounting database (tenant payment history)
* Tenant screening criteria knowledge space
* Fair housing guidelines knowledge space
* Application and Tenant objects, Approval Rate and Average Screening Time metrics
**Trigger:** User asks the agent to score a specific application.
1. Retrieve the application record from the property management system, including the requested unit and lease terms.
2. Pull the applicant's credit score, payment history, and delinquency records from the credit/background check API.
3. Check eviction history and criminal background results from the same API.
4. Load the screening criteria for the specific property and unit type from the tenant screening criteria knowledge space.
5. Score the application against each criterion (credit score, income-to-rent ratio, eviction history, criminal background).
6. Assign an overall recommendation (approve, conditionally approve, or deny) based on the combined results.
7. Return a scoring summary with each criterion's result, the overall recommendation, and any conditions or flags.
**Trigger:** User asks the agent to compare multiple applicants for the same unit.
1. Retrieve all active applications for the specified unit.
2. Score each application using the scoring skill.
3. Rank applicants by overall score, highlighting the strongest and weakest criteria for each.
4. Flag any applicants with equivalent scores for manual tiebreaking.
5. Return a side-by-side comparison table with scores, key differentiators, and the recommended top applicant.
**Trigger:** User asks about application trends, approval rates, or screening performance.
1. Query application data for the requested time period and property from the property management system.
2. Calculate approval rate, denial rate, and average screening time.
3. Identify the most common denial reasons.
4. Compare current metrics against the prior period.
5. Return a trend summary with rates, top denial reasons, and screening time performance.
***
## Automation
### Playbook: Application intake and scoring
Set the trigger to **Event — New record** on the `applications` table in the property management system. The playbook fires each time a prospective tenant submits an application.
The workflow scores each application and notifies all parties:
1. **Query** the application record including applicant demographics, income documentation, and the requested unit.
2. **Action** — call the credit/background check API with the applicant's identifying information to pull credit score, eviction history, and criminal background.
3. **Condition** — check whether the credit and background data returned successfully. If the API returns an error or incomplete data, route to a manual review queue.
4. **Action** — score the application against the property's screening criteria (credit score threshold, income-to-rent ratio, eviction lookback, criminal disqualifiers).
5. **Condition** — if the application meets all criteria, set the status to "approved." If it fails any criterion, set the status to "denied" and record the denial reason. If it falls within conditional ranges (e.g., credit score within 20 points of threshold), set to "conditionally approved" pending additional deposit or guarantor.
6. **Action** — update the application status in the property management system.
7. **Delivery** — notify the leasing team and the applicant.
* **Email to applicant** — send the application decision with next steps (lease signing instructions for approvals, denial reason for denials, conditional requirements for conditional approvals)
* **Slack** — post the scoring result to `#leasing` with the applicant name, property, unit, score, and decision
* **Email** — notify the property manager of conditional approvals that need review
Click **Run now** to test with a recent application, then toggle to **Active**.
***
## What's next
Track lease expirations, automate renewal workflows, and manage document processes across your portfolio.
See the full list.
# Retail
Source: https://docs.wayak.io/use-cases/retail/index
Optimize inventory, measure promotions, and benchmark store performance with AI agents
Retail teams need real-time visibility into stock levels, sales trends, and promotion performance across locations and channels. But the data lives in separate systems — POS, inventory management, supplier portals, and merchandising platforms — making it slow and painful to answer basic questions like "what should we reorder today" or "did that promotion actually work."
Wayak connects your retail data sources, layers business logic through a semantic layer, and deploys agents that monitor inventory, analyze promotions, and benchmark performance automatically. Playbooks handle the daily and weekly analysis that used to require a dedicated analyst pulling reports from three different systems.
## Use cases
Monitor stock levels daily, calculate days of supply, and generate reorder suggestions before stockouts happen.
Measure revenue lift, margin impact, and cannibalization after every promotion to learn what actually drives incremental sales.
Identify top-performing and underperforming SKUs across categories to guide buying decisions and markdown strategy.
Track how price changes affect unit volume and margin so you can set prices that maximize revenue without killing demand.
Compare locations against each other on sales, conversion, inventory turns, and labor productivity with scheduled reports.
## Platform capabilities used
| Capability | How it's used |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data sources | POS database (transactions, line items, tenders), inventory management system (stock levels, receipts, transfers), supplier portal or ERP (purchase orders, lead times, costs), promotions database (campaigns, discounts, date ranges) |
| Knowledge spaces | Merchandising guidelines, vendor agreements, markdown policies, seasonal planning calendars |
| Semantic layer | Objects for SKUs, stores, suppliers, and promotions. Metrics for sell-through rate, days of supply, gross margin, and revenue per square foot. Dimensions for category, brand, store region, and promotion type |
| Agents | Inventory Analyst for stock monitoring and reorder recommendations. Merchandising Assistant for product performance and assortment analysis |
| Playbooks | Daily restock scans, post-promotion performance reports, weekly product rankings, monthly store benchmarking summaries, price change impact alerts |
# Price elasticity monitoring
Source: https://docs.wayak.io/use-cases/retail/price-elasticity-monitoring
Track how price changes affect unit volume and margin so you can optimize pricing decisions
Every price change is a bet. Raise the price too much and volume drops. Lower it too far and you erode margin without enough incremental units to compensate. Most retail teams set prices based on competitor matching or cost-plus formulas without understanding the actual demand response.
Wayak connects your POS data, detects price change events automatically, and runs Python-powered elasticity calculations in playbooks. You get a clear picture of how price-sensitive each product is, so your pricing team can make decisions that maximize total margin — not just revenue or volume.
***
## What you need
* **POS database** — Transaction line items with SKU, quantity sold, selling price, date, and location
* **Pricing database** — Price change history with SKU, old price, new price, effective date, and change reason
* **Pricing strategy guidelines** — Internal rules for price floors, competitive positioning, and margin targets by category
* **Competitive pricing reports** — Uploaded competitor price comparisons for key SKUs
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Object | `SKU` | Maps to the POS item master. Represents a product with its price and sales history |
| Object | `PriceChange` | Maps to the pricing database. Represents a single price change event with before/after values |
| Metric | `PriceElasticity` | Percentage change in unit volume divided by percentage change in price. Values below -1 indicate elastic demand |
| Metric | `MarginPerUnit` | Selling price minus cost of goods sold per unit |
| Dimension | `ElasticityBand` | Categorization: highly elastic (below -1.5), elastic (-1.5 to -1.0), unit elastic (-1.0 to -0.5), inelastic (above -0.5) |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ----------------------------------------------------------------- |
| **Name** | Pricing Analyst |
| **Role** | Price optimization and demand analysis specialist |
| **Goal** | Maximize total margin by understanding price-demand relationships |
> You analyze the relationship between price changes and demand. When reporting elasticity, always show the math: the percentage change in price, the percentage change in units, and the resulting elasticity coefficient. Distinguish between price increases and decreases — elasticity is often asymmetric. Factor in seasonality and competitive context when interpreting results. Use precise language and avoid vague terms like "slightly" or "somewhat." Present recommendations in terms of total margin impact, not just unit volume.
Grant access to:
* POS database (transactions, line items)
* Pricing database (price change history)
* Pricing strategy guidelines knowledge space
* Competitive pricing reports knowledge space
* `SKU`, `PriceChange` objects and `PriceElasticity`, `MarginPerUnit` metrics
**Trigger:** User asks about price sensitivity or a price change review
1. Retrieve the price change history for the requested SKU.
2. For each price change event, pull unit sales for the 4 weeks before and 4 weeks after the change.
3. Calculate the percentage change in average daily unit volume.
4. Calculate the percentage change in selling price.
5. Compute the price elasticity coefficient: % change in volume / % change in price.
6. Classify the SKU into an elasticity band (highly elastic, elastic, unit elastic, or inelastic).
7. Estimate the margin-maximizing price based on the elasticity curve and current COGS.
**Trigger:** User requests a pricing review or quarterly pricing audit
1. Retrieve all SKUs with at least one price change in the past 6 months.
2. Calculate the elasticity coefficient for each.
3. Flag SKUs where the current price appears suboptimal: elastic products priced above the margin-maximizing point, or inelastic products priced below it.
4. Estimate the weekly margin opportunity if the price were adjusted to the optimal point.
5. Rank by margin opportunity and present as a table with current price, suggested price, and estimated weekly margin gain.
***
## Automation
### Playbook: Price change impact alert
Schedule: **Weekly on Wednesday at 8:00 AM** (evaluates all price changes from the prior week with enough post-change sales data).
1. **Query** the pricing database for all price changes effective in the past 7-14 days (changes that now have at least 7 days of post-change sales data).
2. **Query** the POS database for pre-change and post-change unit sales for each affected SKU.
3. **Run Python analysis** to calculate:
* Price elasticity coefficient for each change event.
* Actual margin impact: `(new_margin_per_unit * new_daily_units - old_margin_per_unit * old_daily_units) * 7`
* Projected annual margin impact if the new price holds.
4. **Condition:** If any price change resulted in a negative margin impact exceeding \$500/week, flag it as "review needed" with a recommendation to revert or adjust.
5. **Aggregate** into a summary: total price changes evaluated, positive impact count, negative impact count, and net weekly margin effect.
The **elasticity calculation** step uses a Python code block to compute the elasticity coefficient and margin impact. You can customize the pre/post observation window and the significance threshold for flagging negative impacts.
Send an email to the pricing and merchandising teams with the subject line: "Price change impact — week of \[date]". Flag negative-impact items at the top. Post a summary to the `#pricing` Slack channel.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Combine pricing insights with store-level performance to understand how pricing decisions play out across locations.
See the full list.
# Product assortment optimization
Source: https://docs.wayak.io/use-cases/retail/product-assortment-optimization
Identify top-performing and underperforming SKUs to guide buying decisions and markdown strategy
Carrying the wrong products costs you twice — underperformers occupy shelf space and tie up capital, while gaps in your assortment send customers to competitors. Most merchandising teams rely on gut feel and stale quarterly reports to make buying decisions. By the time the data is compiled, the season has shifted.
Wayak connects your POS and returns data, defines performance metrics in the semantic layer, and deploys an agent that ranks every product by contribution margin, flags underperformers, and recommends actions — keep, markdown, discontinue, or investigate. Your buyers get a live, data-backed view of what is working.
***
## What you need
* **POS database** — Transaction line items with SKU, quantity, revenue, cost of goods sold, and date
* **Returns database** — Return records with SKU, quantity returned, return reason, and date
* **Inventory management system** — Current stock on hand, days since last sale, and receiving dates
* **Merchandising guidelines** — Category assortment rules, minimum margin thresholds, and seasonal planning calendars
* **Markdown policies** — Rules for when to markdown, clearance timing, and minimum margin floors
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | -------------------- | ----------------------------------------------------------------------------------------------------- |
| Object | `SKU` | Maps to the POS item master. Represents a product with its full sales, returns, and inventory history |
| Metric | `ContributionMargin` | Revenue minus cost of goods sold minus returns value, per SKU over the period |
| Metric | `ReturnRate` | Units returned divided by units sold, expressed as a percentage |
| Dimension | `PerformanceTier` | Categorization: top 10% (best seller), middle 80% (core), bottom 10% (underperformer) |
| Dimension | `Category` | Product categorization: apparel, electronics, home goods, grocery, seasonal |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------------------------------- |
| **Name** | Merchandising Assistant |
| **Role** | Product performance analyst |
| **Goal** | Identify top-performing and underperforming products to optimize the assortment |
> You analyze product performance across channels. Compare sales, margins, and return rates by category, brand, and SKU. Present findings as ranked lists with clear metrics. When recommending assortment changes, back them with data: what to keep, what to drop, and what to test. Use a neutral, analytical tone. Never recommend discontinuing a product without showing the supporting data.
Grant access to:
* POS database (transactions, line items)
* Returns database (return records)
* Inventory management system (stock levels)
* Merchandising guidelines knowledge space
* Markdown policies knowledge space
* `SKU` object, `ContributionMargin` and `ReturnRate` metrics, `PerformanceTier` and `Category` dimensions
**Trigger:** User asks about product performance or weekly review
1. Pull sales, cost, and return data for the requested category or time period from the POS and returns databases.
2. Calculate contribution margin for each SKU: revenue minus COGS minus returns value.
3. Rank SKUs by contribution margin in descending order.
4. Assign performance tiers: top 10% as best sellers, bottom 10% as underperformers, middle 80% as core.
5. For underperformers, enrich with: units sold, return rate, days since last sale, current stock on hand, and carrying cost.
6. Recommend an action for each underperformer: keep (if seasonal uptick expected), markdown (if stock is high), discontinue (if return rate is high and sales are declining), or investigate (if data is inconclusive).
**Trigger:** User asks about assortment gaps or buying planning
1. Pull the full SKU list for the requested category with sales velocity and margin data.
2. Identify price point gaps: ranges where competitors have products but you do not (based on merchandising guidelines).
3. Identify feature gaps: attributes present in top sellers but missing from underperformers.
4. Calculate the revenue opportunity for each gap based on the average performance of adjacent SKUs.
5. Present a prioritized list of gaps with estimated revenue opportunity and recommended product attributes.
***
## Automation
### Playbook: Weekly product performance digest
Schedule: **Every Monday at 7:00 AM**.
1. **Query** the POS database for sales and return data from the previous 7 days across all categories.
2. **Loop** through each product category:
* Calculate contribution margin and return rate for every SKU.
* Rank and assign performance tiers.
* Identify any SKU that moved between tiers compared to the prior week.
3. **Condition:** If any SKU in the bottom 10% has more than 30 days of stock on hand, flag it for markdown review.
4. **Aggregate** into a category-by-category summary with movement highlights (new best sellers, new underperformers).
Send an email to the merchandising and buying teams with the subject line: "Weekly product performance — \[date]". Highlight tier changes at the top. Include the full ranked list per category as an attachment.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Understand how price changes affect demand so your assortment and pricing strategies work together.
See the full list.
# Promotion performance
Source: https://docs.wayak.io/use-cases/retail/promotion-performance
Measure revenue lift, margin impact, and cannibalization after every promotion
Promotions are expensive — you discount prices, run ads, and reposition merchandise. But most retail teams cannot answer a simple question after the fact: did the promotion make money? Without a clear lift calculation that accounts for baseline sales, margin erosion, and cannibalization of non-promoted items, you are flying blind on your biggest investment lever.
Wayak connects your POS and promotions data, runs Python-powered lift calculations in playbooks, and delivers a structured post-promotion report so your merchandising team knows exactly what worked and what did not.
***
## What you need
* **POS database** — Transaction line items with SKU, quantity, revenue, cost, discount applied, and timestamp
* **Promotions database** — Campaign records with promotion name, SKU list, discount type, start date, end date, and target revenue
* **Promotion playbook templates** — Internal guidelines for evaluating promotion success (target lift thresholds, acceptable margin erosion)
* **Markdown policies** — Rules for post-promotion markdown timing and clearance thresholds
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Object | `Promotion` | Maps to the promotions database. Represents a campaign with its SKUs, date range, and discount structure |
| Object | `SKU` | Maps to the POS item master. Represents a product with its sales and margin history |
| Metric | `RevenueLift` | Promoted-period revenue minus baseline revenue (same period prior year or pre-promotion average), expressed as a percentage |
| Metric | `GrossMarginImpact` | Difference in gross margin dollars between the promoted period and the baseline period |
| Dimension | `PromotionType` | Categorization: percentage discount, BOGO, bundle, loyalty points, clearance |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------- |
| **Name** | Merchandising Assistant |
| **Role** | Product performance analyst |
| **Goal** | Identify what drives profitable sales and what does not |
> You analyze product and promotion performance across channels. When evaluating promotions, always calculate the full picture: revenue lift, margin impact, and cannibalization of related non-promoted items. Present findings with precise numbers — percentages, dollar amounts, and unit volumes. Compare results against targets when they exist. Use a neutral, analytical tone and let the data lead the recommendation.
Grant access to:
* POS database (transactions, line items)
* Promotions database (campaigns, discounts, date ranges)
* Promotion playbook templates knowledge space
* Markdown policies knowledge space
* `Promotion`, `SKU` objects and `RevenueLift`, `GrossMarginImpact` metrics
**Trigger:** Promotion end date passes or user requests a review
1. Pull sales data for the promoted SKUs during the promotion period.
2. Pull baseline sales data for the same SKUs during the equivalent prior-year period (or the 4 weeks before the promotion if no prior-year data exists).
3. Calculate revenue lift, unit lift, and gross margin impact for each promoted SKU.
4. Identify cannibalization: check whether non-promoted SKUs in the same category saw a sales decline during the promotion period.
5. Compare results against the promotion's target revenue and margin thresholds.
6. Summarize whether the promotion was profitable after accounting for discounts, cannibalization, and incremental costs.
**Trigger:** User asks about promotion strategy or quarterly review
1. Retrieve all promotions run in the specified period.
2. Group by promotion type (percentage discount, BOGO, bundle, loyalty, clearance).
3. Calculate average revenue lift, margin impact, and cannibalization rate for each type.
4. Rank promotion types by net margin contribution.
5. Present a comparison table and recommend which types to increase, reduce, or retire.
***
## Automation
### Playbook: Post-promotion report
Event trigger: **Promotion end date reached** in the promotions database. Runs automatically the day after each promotion ends.
1. **Query** the promotions database for the promotion that just ended — get the SKU list, discount structure, and targets.
2. **Query** the POS database for promoted-SKU sales during the promotion period and the baseline period.
3. **Run Python analysis** to calculate:
* Revenue lift percentage: `(promo_revenue - baseline_revenue) / baseline_revenue * 100`
* Gross margin impact: `promo_margin_dollars - baseline_margin_dollars`
* Cannibalization index: percentage change in same-category non-promoted SKU sales during the promotion window.
* Net promotion value: margin impact minus estimated promotion costs (ad spend, signage, labor).
4. **Condition:** If net promotion value is negative, flag the report as "unprofitable" and include a recommendation to adjust or retire the promotion format.
5. **Aggregate** into a formatted report with summary metrics and a SKU-level detail table.
The **lift calculation** step uses a Python code block to compute baseline-adjusted revenue lift, margin impact, and the cannibalization index. You can customize the baseline methodology (prior year vs. pre-promotion average) and the cost allocation formula.
Send an email to the merchandising team and the category manager with the subject line: "Promotion report — \[Promotion Name]". Include the summary at the top and the full SKU detail table below.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Use promotion insights alongside product performance data to optimize your assortment.
See the full list.
# Restock recommendations
Source: https://docs.wayak.io/use-cases/retail/restock-recommendations
Monitor stock levels daily and generate reorder suggestions before stockouts happen
Stockouts cost you sales. Overstock ties up cash and leads to markdowns. Most retail teams rely on weekly manual reviews or simple min/max thresholds that miss demand changes. By the time someone notices a problem, the shelf is already empty or the warehouse is already full.
Wayak connects your inventory and POS data, calculates days of supply based on actual sell-through rates, and runs a daily playbook that generates reorder recommendations for every SKU at every location. The agent factors in supplier lead times so you know not just what to order, but when the order needed to go out.
***
## What you need
* **Inventory management system** — Stock levels table with SKU, location, quantity on hand, and quantity in transit
* **POS database** — Transaction line items with SKU, quantity sold, date, and location
* **Supplier database** — Supplier lead times, minimum order quantities, and cost per unit
* **Reorder policies** — Safety stock rules, target days of supply by category, and seasonal adjustment guidelines
* **Vendor agreements** — Minimum order quantities, volume discount tiers, and delivery schedules
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ----------------- | ------------------------------------------------------------------------------------------ |
| Object | `SKU` | Maps to the inventory SKU master table. Represents a unique product at a specific location |
| Object | `Supplier` | Maps to the supplier database. Represents a vendor with lead time and ordering constraints |
| Metric | `DaysOfSupply` | Current stock on hand divided by the trailing 14-day average daily sales rate |
| Metric | `SellThroughRate` | Units sold divided by units received over a given period, expressed as a percentage |
| Dimension | `Category` | Product categorization: apparel, electronics, home goods, grocery, seasonal |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ------------------------------------------------------- |
| **Name** | Inventory Analyst |
| **Role** | Stock and demand planning specialist |
| **Goal** | Prevent stockouts and reduce overstock across locations |
> You monitor inventory levels and demand signals. Lead with the data — show current stock levels, sell-through rates, and days of supply before making recommendations. Use concise, action-oriented language. When recommending reorders, specify quantities, supplier lead times, and expected delivery dates. Flag slow-moving inventory that may need markdowns. Never round numbers — precision matters in inventory management.
Grant access to:
* Inventory management system (stock levels, receipts, transfers)
* POS database (transaction line items)
* Supplier database (lead times, order constraints)
* Reorder policies knowledge space
* Vendor agreements knowledge space
* `SKU`, `Supplier` objects and `DaysOfSupply`, `SellThroughRate` metrics
**Trigger:** Daily schedule or stock drops below safety threshold
1. Pull current stock levels for all SKUs at the specified location (or all locations).
2. Calculate days of supply for each SKU using the trailing 14-day average daily sales rate.
3. Identify any SKU with fewer days of supply than the category safety threshold (default: 7 days).
4. For each flagged SKU, calculate the recommended reorder quantity: target 30 days of supply minus current stock on hand minus quantity in transit.
5. Retrieve the supplier lead time and minimum order quantity for each flagged SKU.
6. Flag any SKU where the supplier lead time exceeds the remaining days of supply — these are urgent.
7. Output a reorder table: SKU, location, current stock, days of supply, recommended order quantity, supplier, lead time, and urgency flag.
**Trigger:** User asks about slow-moving inventory or weekly review
1. Pull all SKUs with more than 60 days of supply based on the trailing 30-day sales rate.
2. For each overstocked SKU, calculate the carrying cost (quantity x unit cost x daily holding cost rate).
3. Check whether the SKU is seasonal and if the selling season is approaching or has passed.
4. Rank by total carrying cost in descending order.
5. Recommend an action for each: hold, transfer to a higher-demand location, markdown, or return to vendor.
***
## Automation
### Playbook: Daily restock scan
Schedule: **Daily at 6:00 AM** (runs before the store operations team starts their day).
1. **Query** the inventory management system for current stock levels across all locations.
2. **Query** the POS database for sales volume by SKU over the trailing 14 days.
3. **Loop** through each SKU-location combination:
* Calculate days of supply.
* Compare against the category safety threshold.
* If below threshold, calculate the recommended reorder quantity and check supplier lead time.
4. **Condition:** If the supplier lead time exceeds remaining days of supply, mark the reorder as "critical."
5. **Aggregate** results into two tables: critical reorders (need immediate action) and standard reorders (need action this week).
Send an email to the inventory planning team with the subject line: "Daily restock report — \[date]". Critical reorders appear at the top in a highlighted section. Also send a Slack message to `#inventory-alerts` for any critical items.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Once your inventory is stable, measure whether your promotions are driving profitable demand.
See the full list.
# Store benchmarking
Source: https://docs.wayak.io/use-cases/retail/store-benchmarking
Compare locations against each other on sales, conversion, and inventory turns with scheduled reports
Multi-location retailers struggle to understand why some stores outperform others. The data exists — POS, traffic counters, labor scheduling, inventory — but it lives in different systems and nobody has time to compile a cross-location comparison every week. Performance gaps go unnoticed until they show up in quarterly results.
Wayak connects your multi-location POS and inventory data, defines consistent benchmarking metrics in the semantic layer, and delivers scheduled reports that rank every store on the KPIs that matter. Your operations team gets a clear picture of who is leading, who is trailing, and where to focus improvement efforts.
***
## What you need
* **POS database** — Transaction data with store ID, revenue, transaction count, units sold, and date
* **Inventory management system** — Stock levels, receipts, and inventory turns by store
* **Labor scheduling system** — Scheduled hours, actual hours, and labor cost by store and date
* **Store profiles** — Store size (square footage), format (flagship, standard, outlet), region, and opening date
* **Operational standards** — Target KPIs by store format, acceptable variance ranges, and improvement playbooks
**Semantic layer:** Define these in your ontology before setting up the agent.
| Component | Name | Definition |
| --------- | ---------------------- | ------------------------------------------------------------------------------------------------- |
| Object | `Store` | Maps to the store master table. Represents a physical retail location with its profile attributes |
| Metric | `RevenuePerSquareFoot` | Total revenue divided by selling square footage over the period |
| Metric | `InventoryTurns` | Cost of goods sold divided by average inventory value, annualized |
| Metric | `ConversionRate` | Number of transactions divided by foot traffic count, expressed as a percentage |
| Dimension | `StoreRegion` | Geographic categorization: Northeast, Southeast, Midwest, West, International |
| Dimension | `StoreFormat` | Format categorization: flagship, standard, outlet, pop-up |
See [building a semantic layer](/quickstart/build-semantic-layer) for a step-by-step guide.
***
## Agent setup
Go to **Agent Space** → **New agent**.
| Field | Value |
| -------- | ----------------------------------------------------------------------------------------- |
| **Name** | Store Performance Analyst |
| **Role** | Multi-location retail operations analyst |
| **Goal** | Identify performance gaps between stores and surface actionable improvement opportunities |
> You analyze and compare store performance across locations. Always normalize comparisons by store format and size — do not compare a flagship to an outlet without adjusting. Present rankings with context: show the metric, the store's value, the peer average, and the variance. Use a direct, data-driven tone. When identifying underperformers, suggest specific operational levers (staffing, inventory allocation, layout changes) based on which metrics are lagging.
Grant access to:
* POS database (transactions by store)
* Inventory management system (stock levels, turns by store)
* Labor scheduling system (hours, costs by store)
* Store profiles knowledge space
* Operational standards knowledge space
* `Store` object, `RevenuePerSquareFoot`, `InventoryTurns`, `ConversionRate` metrics
**Trigger:** User asks for a store comparison or weekly operations review
1. Pull revenue, transaction count, inventory turns, and labor hours for all stores over the requested period.
2. Calculate key metrics: revenue per square foot, conversion rate, inventory turns, and revenue per labor hour.
3. Group stores by format (flagship, standard, outlet) to ensure fair comparisons.
4. Rank stores within each format group by each metric.
5. Identify the top 3 and bottom 3 stores in each format group with their variance from the peer average.
6. For bottom performers, cross-reference which metrics are lagging to identify the likely root cause (traffic, conversion, basket size, or operational efficiency).
**Trigger:** User asks about a specific store's performance
1. Pull all available metrics for the requested store over the past 12 weeks.
2. Calculate week-over-week trends for revenue, conversion, inventory turns, and labor productivity.
3. Compare each metric against the store's format peer group average.
4. Identify the single biggest performance gap relative to peers.
5. Search operational standards for recommended improvement actions tied to that gap.
6. Present a trend chart and a prioritized list of actions with estimated impact.
***
## Automation
### Playbook: Monthly store benchmarking report
Schedule: **First Monday of each month at 8:00 AM**.
1. **Query** the POS, inventory, and labor databases for the previous calendar month across all stores.
2. **Query** store profiles for format, region, and square footage data.
3. **Loop** through each store:
* Calculate revenue per square foot, inventory turns, conversion rate, and revenue per labor hour.
* Compare against the format peer group average and the same month last year.
4. **Condition:** If any store falls more than 15% below its peer group average on two or more metrics, flag it as "needs attention."
5. **Aggregate** into a formatted report with store rankings by format, trend comparisons, and a flagged-stores section.
Send an email to the VP of Retail Operations and regional managers with the subject line: "Monthly store benchmarking — \[Month Year]". Include a dashboard-style summary and a detailed appendix with per-store metric tables.
Click **Run now** to test with live data, then toggle to **Active**.
***
## What's next
Once you identify which stores need better inventory allocation, automate the restock process.
See the full list.