---
title: Where to start with AI: a department-by-department playbook
description: Find where you stand, pick one department, and rebuild its work in seven steps. Then the workflows to start with in finance, sales ops, HR, legal, operations, procurement, IT, marketing and customer operations, each with the steps, a prompt to copy and the number to track.
author: Ofek Katriel, co-founder and CEO
published: 2026-10-20
url: https://trycaliber.ai/blog/first-impact-playbook
---

# Where to start with AI: a department-by-department playbook

Find where you stand, pick one department, and rebuild its work in seven steps. Then the workflows to start with in finance, sales ops, HR, legal, operations, procurement, IT, marketing and customer operations, each with the steps, a prompt to copy and the number to track.

Where should a large company start with AI? Anyone who gives every company the same answer has not done it many times. The answer depends on where you are today, and it is found in discovery: learning how the work actually runs before deciding what to change.

One thing holds everywhere: the work does not stop at a department's edge. A finance process waits on procurement, payroll and sales. An HR process waits on IT. So the agents you build will read from and write to several departments, and the plan has to start from that.

## 1. Figure out where you are

Most companies are in one of three places, and each has its own problem.

1. **You have not started.** Security, legal or a systems migration held you back, and "we need to get our data in order first" has been the line for a while. Cleaning the data is part of the work, not a condition for starting it. The upside: no seats gathering dust and no committee guarding a list of use cases.
2. **You rolled out a copilot and hit a plateau.** Everyone has a chat tool, usage climbed and then flattened, and people say it helps, but the P&L has not moved. An assistant speeds up a person when they remember to ask it. The step change comes from agents that do the work in the background and only bring people the exceptions.
3. **Your pilots are stuck.** Plenty of pilots, none in production. Usually because each was built inside one team, the process was never mapped, and no number was agreed before building, so the demo worked until the first exception and nobody knew what fixing it was worth.

## 2. Start with a department

Not one workflow, and not the whole company: one department, with every system, process, rule and person in it. Most of the time in a process is lost in the handoffs between departments, so optimizing one workflow inside one team usually misses where the delay is. Each team meets its own target, and the process still takes weeks.

Pick the department that scores highest on three things:

1. **Volume.** How many times its processes run each month.
2. **Cost.** What the department costs to run. The CFO usually has the number.
3. **Reach.** How many other departments its processes touch.

For most companies that points to finance first, then sales operations, then HR, procurement or operations, and legal and marketing after that.

## 3. The seven steps

1. **Pick the department that scores highest.** Score each department on volume, cost and reach, and start with the winner. Write down why, so the next department is a decision, not a debate.
2. **Agree on the value and write it down.** The executive sponsor and the department head agree on a few numbers in three groups: time and cost, revenue after what the AI costs to run, and risk. Write down where each stands today. That page is what you report against.
3. **Map the process as it really runs.** The documented process is never the real one. Read the event logs in your systems and sit with the people who do the work; the extra steps, the email side-channels and the workarounds are where the time goes.
4. **Design the new process.** For every step ask, in order: can we delete it, can plain code do it, can an agent do it? What is left stays with a person, usually because a control or an auditor needs it. The common mistake is automating the old process without deleting anything.
5. **Build on the systems you already have.** Agents work inside your ERP, CRM and ticketing tools, so nobody moves to a new system. Use a model only where the input is unpredictable, and keep what the agents learn about your company in one shared place, so the second department starts ahead.
6. **Run alongside, then go live.** For the first weeks the agents run on the full volume without acting, and every case where they disagree with a person gets reviewed. Then let them act on the cases you have checks for and are sure of, and widen from there. People keep the rest.
7. **Find the people already ahead.** A small share of every company already uses AI to get better at their job. Train them, rank them by time saved rather than tokens used, and have them build the agents for the next department. Everyone else gets the agents in the background.

## 4. What changes depending on where you start

Everyone runs the same seven steps. The first week is different.

1. **If you have not started.** Go straight to step one, but do not roll AI out across the company first. Bring security, legal and finance in during the first week, including how agents get identities and access.
2. **If you rolled out a copilot.** Keep the seats; people are faster with them. Pull a report of who uses them most: those people are your step seven. Then pick the department.
3. **If your pilots are stuck.** Put a number on each pilot as in step two, and stop the ones you cannot. Fold the rest into the department you picked and map their process; most cover a single step of a much longer process.

## The workflows to start with, department by department

These are the workflows that are ready for agents in most companies. Each runs in the background on the systems you already have and routes the exceptions to your people. For each one: the steps to start this month, a prompt to test it with in the AI tool your company has approved, and the number to track.

### 1. Finance

High volume, clear rules and a lot of exceptions: the best place to start in most companies.

#### 1.1 AP exception triage

Sort every invoice that failed matching by its reason, and draft the fix or the email that resolves it.

1. Export last month's exception queue with the invoice, PO and receipt lines side by side.
2. Run the prompt on a batch of 50 and check every answer against what your team actually did.
3. Route each reason to one owner: price variances to the buyer, missing receipts to the warehouse, duplicates to AP.
4. Once the reasons match your team's on two batches in a row, run it on the whole queue every morning.

Prompt:

```
You are an accounts payable analyst. For each invoice below, compare the invoice lines with the PO and receipt lines. Classify the exception as one of: price variance, quantity variance, missing PO, missing receipt, duplicate invoice, other. Give the line and the amount that caused it, the most likely fix, and who should own it. If the reason is unclear, say so instead of guessing. Return a table.

{{paste invoice, PO and receipt lines}}
```

Track: Exceptions open at month end, and the average days an exception stays open.

#### 1.2 Variance commentary for the close

Draft the explanations of month-over-month and budget variances that the controller writes by hand today.

1. Export the trial balance for this month and last, plus the GL detail for every account over your variance threshold.
2. Run the prompt per account group and have the account owner correct the draft, not write it.
3. Keep the corrected drafts: next month they are the examples you paste in, so the tone and depth match.

Prompt:

```
You are a controller preparing the month-end flux analysis. Below are two trial balances and the GL detail for accounts that moved more than {{threshold}}. For each account, explain the variance in two sentences using only the transactions shown: name the largest drivers with their amounts. Flag anything that looks like a misposting, a missing accrual or a one-off. Do not invent reasons the data does not support.

{{paste trial balances and GL detail}}
```

Track: Hours from soft close to a reviewed close package.

#### 1.3 Cash application and collections

Match incoming payments and remittance advice to open invoices, and write the follow-up for every account still past due.

1. Export the day's payments with their remittance advice, and open AR with the contact and last note per account.
2. Post the clean matches; a person reviews short pays, overpays and anything unmatched.
3. Every week, the collector edits and sends the reminders for the 30+ bucket before it becomes the 60+ bucket.

Prompt:

```
Below are today's payments with their remittance advice, and the open invoices. Match each payment to the invoices it pays, and flag short pays, overpays and payments you cannot match. Then, for each customer with invoices more than 30 days past due, draft a short, polite reminder that lists the invoices and asks for a payment date. Acknowledge the last note on the account if there is one. No threats, no legal language.

{{paste payments, remittances and open AR with notes}}
```

Track: Days sales outstanding, and the share of AR more than 30 days past due.

### 2. Sales ops

Most of the win is giving reps their admin time back and walking into every call prepared.

#### 2.1 The post-call CRM update

Turn every call transcript into the fields your CRM needs, so the pipeline is current without anyone typing.

1. Pick the five fields your forecast depends on: next step, next step date, decision maker, budget, close date.
2. After each call, paste the transcript into the prompt and paste the result into the opportunity.
3. After two weeks, wire it up so the transcript goes in and the fields come out automatically.

Prompt:

```
From this sales call transcript, fill in these fields for the CRM: next step (one sentence), next step date, decision maker and their role, budget mentioned (or 'not discussed'), expected close date (or 'not discussed'), risks raised by the buyer, and open questions we owe them. Quote the transcript for every field you fill. Leave a field empty rather than guess.

{{paste transcript}}
```

Track: Share of open opportunities with a next step and a date filled in.

#### 2.2 Deal desk approvals

Prepare every discount and non-standard terms request with what the approver needs, so approvals stop waiting on back-and-forth.

1. Write down your approval matrix: who approves which discount levels and which non-standard terms.
2. Run the prompt on each request as it comes in, and send the packet straight to the right approver.
3. Track the requests that still bounced back, and add what was missing to the prompt.

Prompt:

```
You prepare deal desk requests. Our approval rules: {{approval matrix}}. For this request, return: the discount and terms requested, how they compare with our standard, who must approve under the rules, the deal context the approver will ask for (size, stage, competitor, term length, past discounts for this customer), and anything missing from the request. Keep it to one page.

{{paste request and deal details}}
```

Track: Days from approval request to decision.

#### 2.3 The forecast-call deal brief

One page per committed deal before the Monday forecast call: what changed, what is at risk, what the rep needs.

1. Export the activity history, stage changes and notes for every deal in commit and best case.
2. Run the prompt per deal on Sunday night; the manager reads the briefs instead of asking reps for updates.
3. Track which deals the brief flagged as at risk, and whether they slipped.

Prompt:

```
You are a sales manager preparing for the forecast call. From this deal's history, write a brief: current stage and how long it has been there, what changed this week, the next step and its date, and risks. Flag: no activity in 14 days, close date pushed more than once, no contact with the decision maker, stage moved backwards. End with the one question I should ask the rep.

{{paste deal history}}
```

Track: Hours spent preparing the forecast call, and deals that slipped without being flagged.

### 3. HR

The same questions every week, and data that has to agree across three systems.

#### 3.1 Policy and benefits answers

An assistant that answers employee questions from your own handbook, cites the section, and hands off when the answer is not there.

1. Collect the handbook, benefits guides and leave policies, and remove anything out of date.
2. Load them into a project or custom assistant in the AI tool your company has approved, with the instructions below.
3. Test it with last quarter's 30 most common questions before anyone else sees it.

Prompt:

```
You answer employee questions about company policy and benefits. Answer only from the documents provided, and cite the document and section for every answer. If the documents do not answer the question, or it concerns a personal situation (health, pay dispute, performance, a complaint), do not answer: say that HR will handle it and give the contact {{hr contact}}. Be short and plain.
```

Track: Policy and benefits questions reaching the HR team each month.

#### 3.2 The pre-payroll reconciliation

Before every payroll run, check that the HRIS, the payroll system and the ATS agree on who joined, who left and who changed pay.

1. Export changes since the last run from each system: hires, leavers, pay changes, leave.
2. Run the prompt and fix every mismatch before payroll locks, not after.
3. Keep a log of mismatch types; the recurring ones are a process to fix, not a list to check.

Prompt:

```
Compare these three exports covering changes since the last payroll run: HRIS, payroll and ATS. List every person whose start date, end date, salary, department or status differs between systems, or who appears in one system and not another. For each, show the values side by side and say which system is most likely right and why. Return a table.

{{paste the three exports}}
```

Track: Off-cycle payroll corrections per run.

#### 3.3 Role-based onboarding plans

A day-one checklist and a first-30-days plan for every new hire, generated from the role and the team.

1. Write down what every hire needs (equipment, accounts, documents) and what each team adds.
2. Generate the plan when the offer is signed, and send the IT and equipment parts the same day.

Prompt:

```
Create an onboarding plan for a new {{role}} joining the {{team}} team on {{start date}}, reporting to {{manager}}. Include: what must be ready before day one (equipment, accounts, access), a day-one schedule, goals for days 1-30, and the people they should meet. Use this company checklist as the base: {{paste checklist}}.
```

Track: Share of new hires with equipment and every account working on day one.

### 4. Legal

Standard contracts that wait in a queue, and obligations nobody remembers until they bite.

#### 4.1 First-pass NDA review against your playbook

Compare each incoming NDA with your positions, and produce the redline suggestions a lawyer approves instead of writes.

1. Write your playbook as a table: clause, our standard, acceptable fallback, walk-away.
2. Run the prompt on the last ten NDAs you signed and compare with what counsel actually changed.
3. Then use it on every new NDA; counsel reviews the table, not the whole document.

Prompt:

```
You are reviewing an NDA for {{company}}. Our playbook: {{paste table of clause / standard / fallback / walk-away}}. For each clause in the playbook, quote the NDA's language, say whether it meets our standard, our fallback, or neither, and propose replacement language where it does not. Note any clause in the NDA that our playbook does not cover. Return a table.

{{paste NDA}}
```

Track: Days from NDA received to NDA returned.

#### 4.2 Contract intake

Turn every contract request into a complete intake: who is asking, what type, which template, which lawyer.

1. Write down your contract types, the template for each and who handles it.
2. Point the request form or the legal inbox at the prompt, and send the result to the assigned lawyer.
3. Review a week of assignments before letting it route on its own.

Prompt:

```
You triage contract requests for the legal team. Contract types, templates and owners: {{list}}. From this request, return: the requester and their team, the counterparty, the contract type, the template to start from, the lawyer it goes to, the deadline, the deal value if given, and the questions the lawyer will need answered that the request does not answer.

{{paste request}}
```

Track: Days from request to a lawyer starting work.

#### 4.3 Obligation and renewal extraction

Pull renewal dates, notice periods and auto-renewal terms out of every signed contract and into a calendar.

1. Start with the contracts above a value threshold, then work down.
2. Run the prompt per contract, check the dates against the document, and put each notice deadline in a shared calendar with an owner.

Prompt:

```
From this signed contract, extract: parties, effective date, term, renewal type (auto-renew or not), renewal date, notice period and the last date to give notice, termination rights, price increase terms, and any other dated obligation. Quote the clause for each field. Leave a field empty if the contract is silent.

{{paste contract}}
```

Track: Renewals that passed their notice deadline without a decision.

### 5. Operations

Exceptions that someone handles by hand, usually late and usually by email.

#### 5.1 The daily disruption brief

Every morning, turn late shipments and supplier issues into a list of affected orders and the customer messages to send.

1. Export open shipments with their expected and current dates, and the orders each one feeds.
2. Run the prompt each morning; the ops lead decides, the drafts go out the same hour.

Prompt:

```
Here are today's delayed shipments and the open orders they feed. For each affected order: the customer, the original and new expected date, whether a substitute or partial shipment is possible from the stock listed, and a short message to the customer explaining the delay and the option. Sort by customer priority {{rule}}.

{{paste shipments, orders, stock}}
```

Track: Hours from a delay being known to the customer being told.

#### 5.2 Order exception queue

Classify every held order (credit hold, bad address, out of stock, pricing) and propose the resolution.

1. Export every order on hold with its hold reason, customer and notes.
2. Run the prompt, send each class to its owner, and review what is still held at the end of the day.

Prompt:

```
For each held order below, classify the problem (credit hold, address, stock, pricing, other), propose the most likely resolution from the data given, and say who should act. Flag orders held more than 24 hours. Return a table.

{{paste held orders}}
```

Track: Orders on hold for more than 24 hours.

### 6. Procurement

Paperwork that waits on someone to chase it, and invoices that should never have been paid.

#### 6.1 Supplier onboarding document check

Check every new supplier's documents for completeness and expiry, and draft the follow-up for what is missing.

1. List the documents you require from every supplier: tax form, insurance certificate, bank letter, sanctions screen, signed terms.
2. Run the prompt on each new supplier's packet the day it arrives.
3. Send the drafted follow-up the same day; the waiting is where the weeks go.

Prompt:

```
Review these supplier onboarding documents against our requirements: {{list required documents and rules, e.g. insurance coverage at least X, certificate not expiring within 60 days}}. For each requirement say: present, missing, or present but failing (and why). Then draft a short email to the supplier asking for exactly what is missing.

{{paste or attach the documents}}
```

Track: Days from supplier request to supplier ready to pay.

#### 6.2 3-way match before payment

Compare every invoice with its PO and receiving record before the payment run, and catch duplicates and invoices above the PO.

1. Export the invoices in the upcoming payment run, their POs and receiving records, and the last 90 days of paid invoices.
2. Run the prompt and hold anything flagged until AP clears it.

Prompt:

```
For each invoice, compare it with its PO and receiving record. Flag: (1) quantity billed above quantity received; (2) price above the PO; (3) no PO or no receipt; (4) likely duplicates of another invoice or of one already paid, matching on vendor and amount, invoice number variants (spaces, dashes, leading zeros) or the same date and amount. Return a table with the reason and the invoices involved.

{{paste invoices, POs, receiving records and recently paid invoices}}
```

Track: Value of mismatched and duplicate invoices stopped before payment.

### 7. IT

Access that arrives late and is removed later, and tickets that land with the wrong team.

#### 7.1 The weekly joiners, movers and leavers diff

Compare your HR system with every app's user list, and find leavers who still have access and joiners who still lack it.

1. Export the HRIS employee list (status, start date, end date, department) and the user lists of your identity provider and top ten apps.
2. Run the prompt every Monday and close every line before Friday.
3. Include the AI tools: seats and API keys are access too.

Prompt:

```
Compare this HR employee list with the app user lists below. List: (1) people marked as left who still have an active account, with the app and last login; (2) people who started more than three days ago and are missing an account their department normally has; (3) accounts that match no employee. Return one table per list.

{{paste HR list and app user lists}}
```

Track: Active accounts belonging to people who left, and days from start date to full access.

#### 7.2 Ticket triage and routing

Classify each new ticket, route it to the right team the first time, and draft a first reply with the relevant article.

1. Export your last 500 tickets with their final team and category: that is your answer key.
2. Test the prompt on 100 of them and compare its routing with where they actually ended up.
3. When it beats your current first assignment, put it in front of the queue.

Prompt:

```
Classify this IT ticket. Teams: {{list teams and what each owns}}. Return: category, the team that should own it, priority (with a reason), and a first reply to the user that links the most relevant article from this list {{paste KB titles and links}}. If the ticket lacks something the team will need, ask for it in the reply.

Ticket: {{paste ticket}}
```

Track: Share of tickets reassigned to another team.

### 8. Marketing

Inbound that waits hours for a rep, and media invoices nobody checks against what ran.

#### 8.1 Speed to lead

Enrich, score and route every inbound demo request with a short brief for the rep, in minutes instead of hours.

1. Write down your routing rules and your ideal customer profile in plain words.
2. Run the prompt on each new request (by hand at first, then from your form tool's automation).
3. Check a week of routing decisions against what the reps think before you automate it.

Prompt:

```
A new inbound request: {{form fields}}. Our ideal customer: {{ICP}}. Routing rules: {{rules}}. Using public information about the company, return: company size and industry, fit score from 1 to 5 with the reason, the rep it should go to under the rules, and a three-line brief the rep can read before calling. Say what you could not verify.
```

Track: Minutes from form submitted to first contact by a rep.

#### 8.2 Media invoice reconciliation

Check every media invoice against the insertion order and what actually ran.

1. Export the insertion orders, the delivery reports from each platform, and the invoices for the month.
2. Run the prompt and dispute every gap before the invoice is paid.

Prompt:

```
Compare these media invoices with the insertion orders and the delivery reports. For each line, show ordered, delivered and billed (impressions, placements, amounts), and flag any line billed above what was ordered or delivered. Total the amount in dispute per vendor.

{{paste IOs, delivery reports, invoices}}
```

Track: Amount billed above what was delivered, per month.

### 9. Customer operations

Escalations that bounce between support and engineering, and come back asking for details.

#### 9.1 Escalation routing

Send every escalation to the team that owns the problem the first time, instead of letting it bounce between support and engineering.

1. Export the last few hundred escalations with the team that finally resolved each one.
2. Test the prompt on them and compare its pick with the team that actually fixed it.
3. Put it in front of the escalation queue once it beats the current first assignment.

Prompt:

```
Route this escalation. Teams and what each owns: {{teams}}. Return: the team that should own it and why, the product area, severity with a reason, and what that team will need that the ticket does not include yet.

{{paste ticket}}
```

Track: Escalations reassigned between teams before resolution.

#### 9.2 Escalation summaries engineering accepts

Every escalation arrives with what engineering needs to act, so it is not sent back for details.

1. Ask engineering what they always have to ask for, and put it in the template.
2. Run the prompt on the ticket thread before every escalation.

Prompt:

```
Summarize this support thread for an engineering escalation. Include: the customer and their plan, what they were trying to do, what happened instead, exact error messages, steps to reproduce, when it started, what support already tried, how many customers are affected if known, and business impact. Mark anything missing as MISSING so support can get it before escalating.

{{paste thread}}
```

Track: Escalations sent back for more information.

## TL;DR

You are probably in one of three places: not started, plateaued on a copilot, or stuck in pilots. Most companies are in the second. An assistant makes people somewhat faster when they ask it; agents in the background take over whole workflows and hand people the exceptions.

Wherever you are, pick one department and rebuild it end to end. The time is in the handoffs between departments, so the agents will span them, and the project is won or lost in discovery. Choose by volume, cost and reach. It is usually finance.

> One department, mapped as it really runs, rebuilt end to end. Then the next one.

Caliber: https://trycaliber.ai/ · Book a demo: https://trycaliber.ai/get-a-demo