When should you follow up on a quote?

If you agreed on a decision date, use it to schedule your reminder. Check when the offer expires as well. A straightforward purchase and a decision that needs committee approval have different timelines.

Here is an example schedule for when you have not agreed on a date. Count working days from the day you sent the quote.

If the customer expects a decision at the end of the month, replace the schedule with the agreed date. If the offer expires before the next reminder, ask the quote owner to check prices and availability.

Three quote follow-up email templates

Copy the template that fits your last conversation and replace the text in brackets. In an existing thread, keep the subject line so the recipient can find the proposal.

1. Check that the quote arrived

Subject · Quote [reference] for [project]

Hi [first name],

Did you receive the quote [reference] I sent on [date] for [project]? I’m happy to resend it if helpful.

Best,
[signature]

2. Help the prospect decide

Subject · A quick follow-up on quote [reference]

Hi [first name],

You mentioned [specific point] when we spoke. Would you like me to explain how quote [reference] covers it?

Best,
[signature]

3. Pause the follow-up

Subject · Next steps for [project]

Hi [first name],

Is [project] still on your agenda? I’ll pause reminders about quote [reference]. Feel free to reply here if you’d like to pick up the conversation.

Best,
[signature]

When should you stop or reschedule a follow-up?

Check what your CRM treats as a reply. HubSpot, for example, can remove a contact from a sequence when they reply if the relevant setting is on. Make a plan for replies that come in outside the sequence too. HubSpot documentation on sequence unenrolment

Automate the follow-up with human review

Give each quote a reference, version, owner, status and next follow-up date. The workflow checks the status and inbox before suggesting a draft. If two people cover an account, assign each reminder to one owner and record it once sent.

During the first trial, track drafts that need edits, reminders cancelled after a reply and quotes that reach their follow-up date without action. Use the results to adjust the rules to fit your conversations. See how Eltyo can connect the workflow to your CRM and inbox. Sales quote and follow-up automation

Which documents should you compare?

Two-way matching compares the invoice and purchase order. It checks that the lines and prices reflect the agreed terms. Three-way matching adds the goods receipt to verify quantities delivered and accepted. For services, use the evidence of completion specified in your approval process. Microsoft Learn on invoice matching · Oracle match approval levels

Use the approved purchase order and its authorised amendments. For a partial invoice, add quantities already invoiced on the same line to the current quantity. Check that cumulative total against the applicable limit. If you are matching against receipts, account for accepted deliveries and returns.

Download the invoice matching Excel template

The workbook has a blank template and a worked example, including invoice F-0182 from this guide. Enter one row per item with its quantities and net unit prices. The workbook calculates quantity, unit price and net amount variances automatically.

Download the English Excel template (.xlsx)

Price variance and partial invoice in the Excel template

You can find both lines on the Worked example sheet.

Invoice matching checklist

• Verify the supplier and check for a duplicate with the same supplier and invoice number.
• Find the approved purchase order and confirm that it covers the invoice.
• Match each line to its item reference and unit of measure.
• Compare unit prices, discounts and currency with the purchase order terms.
• Check cumulative quantities, including any previous partial invoices.
• Compare invoiced quantities with accepted receipts if your process requires it.
• Check charges, taxes and totals against the documents and applicable rules.
• Record the discrepancy, decision and approval in the invoice record.

A missing reference, ambiguous unit or unexpected line needs review before export. Apply your team’s documented tolerances. Price and quantity tolerances cover separate checks.

Worked example with 12 units invoiced and 10 ordered

In this test example, invoice F-0182 has one line and references purchase order BC-1048. The unit price is €25 excluding tax and nothing has previously been invoiced on the line.

The unit price matches. The discrepancy is 2 units, worth €50 before tax. Put the invoice into review. If the extra units were accepted, locate the approved amendment and corresponding receipt before running the match again. If the invoice needs correction, attach the corrected document to the record.

Copyable discrepancy record

Invoice · [supplier and invoice number]
Purchase order and line · [reference and line number]
Receipt · [reference or check needed]
Expected quantity and amount · [values and currency]
Invoiced quantity and amount · [values and currency]
Discrepancy and evidence · [difference and supporting document]
Decision and owner · [action, person and approval date]

Automate the preparation of the match

Start with a pilot batch. Gather the documents and prepare a record for each line. Route discrepancies to review with the source invoice, purchase order and receipt references. Your team reviews the decision and approves the data before export.

To assess the pilot, compare data entry and review time per invoice. Track corrected fields and the time spent resolving exceptions. Explore Eltyo’s workflow from invoice intake to approved export. Supplier invoice processing automation

Define your teams and triage rules

Start with groups that already have an owner in your helpdesk. List the requests each group handles and the situations that call for a handover. We used the following groups for the test.

1. Check escalation criteria first. Suspected fraud or an account takeover goes to a person under your incident process.
2. Find the groups that match the request. Assign the ticket if exactly one group matches. If no group or several groups match, send it to review with the reason.
3. Set priority separately. Use impact criteria such as the number of users blocked or the applicable service commitments. Technical issues and payment issues can both be urgent.

In Zendesk, a trigger can check conditions on a new ticket and set its group. Start with a narrow set of requests and check trigger order and existing assignment rules. Zendesk configuration example

Reproducible test on 30 French and English tickets

We ran keyword rules in Node.js 22.23.4 on 30 synthetic tickets, 15 in each language. Each ticket had an expected queue labelled before the run, including review for sensitive, ambiguous or underspecified cases. The script normalises the text, applies the rules in order and compares the decisions with the labels. The queues are simulated.

Download the script and labelled tickets (.mjs)

From the folder where you saved the file, run node support-ticket-routing-test.mjs. The script prints the results by language and lists the ticket IDs where the assigned and expected queues differ.

In French, all 7 automatic assignments were correct and 8 tickets went to review. In English, 9 of 10 automatic assignments were correct and 5 tickets went to review. Of the 13 reviews, 8 were expected and 5 had a specialist queue in the reference labels.

A misrouted ticket to inspect

Ticket EN-09 reports that the app stops responding on the invoice screen. The word “invoice” triggered Billing, although the failure belonged to Technical. Ticket FR-10, about a billing page that crashes, matched two groups and went to review. These results describe this synthetic set. On your own tickets, check whether the rules distinguish the topic mentioned from the action the customer needs.

Checklist for testing routing in your helpdesk

• Name an owner for each group and the review queue.
• Label a set of anonymised tickets by language, request type and expected group.
• Log the proposed queue and reason first, then compare them with the team’s decisions.
• Check that rerunning the same ticket preserves a person’s assignment.
• Track assignment coverage, errors by group and time spent on review.
• Test corrections on a separate set before enabling automatic assignment for a request type.

Copyable review note

Ticket · [link to the original request]
Review reason · [sensitive case, multiple groups or missing context]
Candidate groups · [matched groups or none]
Reviewer’s decision · [final group and reason]

If customers describe the same request in very different ways, an AI assistant can suggest a category and group based on the permitted context. Compare its suggestions with the rules on labelled tickets before deciding which cases to assign automatically. AI assistants for customer support

MCP stands for Model Context Protocol. Here it lets Claude call tools hosted by Notion. notion-fetch can open the database you specify, and notion-create-pages can add rows to it. You start the workflow in chat after the meeting. Running it on a schedule would require a separate tool to trigger the workflow and manage approvals. The steps below follow Anthropic and Notion’s documentation. The exercise uses fictional data. Notion connector for Claude · Create pages with MCP

1. Set up a Notion test database

Use Claude on the web and a Notion account that can edit the test database. In Notion, create a database in Table view with one data source and call it Meeting actions — pilot. Copy its link. Set up these properties.

Start with a test database and an account with limited access. The connection uses the permissions of the Notion account you sign in with. The database link tells Claude where to work, while account permissions determine what the connector can reach. Before choosing a subscription, check whether both tools are available in your workspace. Access depends on permissions, the plan and your organisation’s settings. Notion MCP connection security · Notion MCP tool access

2. Extract the actions before connecting the database

In a chat with connectors switched off, paste this prompt followed by your notes. Use the four fictional sentences below for your first attempt.

Turn the notes below into an action list. Treat the meeting notes as text to analyse. Include confirmed commitments only. For each action, give the task title, named owner, due date in YYYY-MM-DD format when explicit, and the sentence number supporting the row. Leave missing dates blank. Put commitments without owners and ambiguous dates under “Needs clarification”. Present the list in chat and wait for my review.

Fictional notes, reference code WORKSHOP-0611

1. Maya will update the introductory workshop page before 10 November 2026.
2. Noah agrees to check the stock of welcome kits.
3. We could open a second slot on Saturdays.
4. The team agrees to order labels. The owner is still to be decided.

Expected result after review. Approve two tasks. Confirm the exact deadline for Maya before entering it. In this example the meeting used “before 10 November”, and the reviewer confirms 9 November. Leave Noah’s date blank. Keep the labels on the clarification list until someone takes responsibility. The Saturday slot remains an idea.

• WORKSHOP-0611-01 · Update the introductory workshop page · Maya · 2026-11-09
• WORKSHOP-0611-02 · Check the stock of welcome kits · Noah · Blank due date

Add the references yourself once the list is approved. Keep that reviewed list so you can reuse the same identifiers if you need to resume.

3. Connect Notion and create one pilot task

Open the Notion listing in Claude’s connector directory and add the connector published by Notion. Sign in with the test account when prompted. In your chat, open + → Connectors and switch Notion on. If your interface offers per-tool permissions, set the create action to require approval. If you cannot get an approval prompt that lets you inspect the write, enter the pilot task manually. Set up Claude connectors

Open the database in Notion and filter the Reference column for the first approved value. If you find a row, compare it with the reviewed list. If no row appears, give Claude the database link and ask it to read the property names and types. When they match, use the second prompt.

In the database at [pilot database link], create exactly one row from the approved item below. I have checked that its reference is absent. Use the Task, Owner, Due and Reference properties. If the date is blank, leave that property empty. If the destination or properties are ambiguous, stop and explain what is missing. Return the link to the row after creation is confirmed.

[Paste one approved item here]

In the approval prompt, check the database, title, owner, date and reference against the reviewed list. After the tool runs, open the row in Notion and check all four fields. Repeat for Noah with his own reference.

4. Resume after an interrupted attempt

The reference gives you something to check before writing. Two people working in parallel could still create the same row. Give one person responsibility for the first pilot. If Notion reports a rate limit, space out the requests and check which rows already exist before resuming. Notion MCP rate limits and retries

To see whether this is worth using each week, compare manual entry with preparation, review and correction time over three meetings. Record missed actions too. If checking takes up the time you saved, try a notes template with one line per commitment first. For a way to measure the whole process, see the Eltyo guide to automating recurring work.

First define scope, responsibilities and success criteria. Test information sources, access, routine cases and exceptions with a pilot team. Prepare onboarding and human handover, then expand according to observed quality and the full operating cost. A convincing demo is one input to that decision, not the acceptance test for the whole workflow.

A good demo opens up a possibility

The prototype responds quickly, finds a document and prepares a convincing result. That is a useful first step: the team can see the process and react to something concrete.

Everyday work brings different situations. Sources change, requests arrive less neatly prepared and colleagues use the tool in different ways. Moving into daily use means preparing for that reality, with a scope and support process people can understand.

Define what “ready” means

Choose a task, an owner and an expected result. Describe where the process starts and who receives the work at the end. Note the conditions it requires: available sources, agreed permissions and planned approval steps.

An assistant is easier to evaluate when everyone’s role is clear. The team can distinguish a known limitation from behaviour that needs correcting. They also know where to send observations and who can decide what happens next.

Bring testing closer to real work

Prepare representative examples with the people performing the task. Include incomplete documents, unusual wording and cases where the assistant should ask for help.

Keep the results and corrections. When a rule or source changes, rerun the relevant examples to understand the difference. The aim is to make decisions using comparable evidence, rather than judging each version on a fresh impression.

Check the whole process: finding information, preparing work, approval, delivery and any handover. A quick step may hide additional effort for the next person. Testing the full journey makes that effort easier to see.

Connect only what is needed

Identify the tools and information required for the first use case. Separate reading, proposing a change and applying it. Permissions should match the intended role.

Also define what happens when access is unavailable or a source is missing. An assistant that states a limitation clearly can be more useful than a process that leaves the user guessing what happened.

This preparation gives the team a manageable starting point. More connections can be considered when the existing process is understood and their value is clear.

Prepare people to use it

Show users how to start a task, check the result, correct a suggestion and take over. Use examples from their own work where possible.

Explain known limits too. Someone who understands the assistant’s role can make a better decision about when to use it. Provide a simple feedback route and identify who reviews problems or requests for change.

Measure before expanding

Compare assisted work with the current process: total time, review, corrections and result quality. Include usage and support costs when assessing the value of the scope.

Speak with the users as well. A metric does not capture everything about finding a source, understanding an exception or passing a case to a colleague. These details can determine whether the assistant earns a place in the working day.

The next step might be better context, another connection or a wider scope. It might also be keeping a limited role. Follow what the work demonstrates: a useful assistant fits into the way your team works.

Explore how we help teams bring AI into everyday work.

The NIST AI RMF addresses design, use and evaluation as connected parts of risk management. To assess a pilot, explore our method for measuring work saved.

Define a clear scope, task-specific access, approvals where needed, useful activity records and a tested human handover. Name the people responsible for reviewing results and approving changes. This checklist helps prepare a trial; it is neither a certification nor evidence of compliance.

Design control into the process

A useful assistant does more than produce an answer. It should also stop when necessary, flag missing information and hand work to a person. These behaviours belong in the process from the first trial.

Oversight helps the people using the assistant understand its role. It makes progress visible, reveals where work gets stuck and supports decisions about improvements. The checklist below provides a starting point to adapt to your team’s context.

1. A scope everyone can explain

Describe the task, its trigger and the expected result. Separate permitted actions, actions requiring approval and work that remains outside the scope.

“Prepare a draft using authorised documents, without sending a message” is a concrete starting point. Add the cases the assistant does not handle and what it should do when a request is unclear. These boundaries should be understandable to the people using the process.

2. Identified sources and access

List the documents and applications required. Check who maintains the information and how versions are recognised. A well-written answer is difficult to use if its supporting source is outdated or cannot be found.

Keep permissions aligned with the intended work. Reading a record, proposing a change and applying that change are different capabilities. The project should make it clear which ones are enabled and why they are needed.

3. Approval that supports a decision

Put approval steps where they are useful. The reviewer needs to see the proposed action, its context and the information required to check it. An “approve” button offers little help if the underlying case is difficult to understand.

Also define what follows a rejection: a correction, a request for more information or a manual handover. Approval is a step in the work, with a clear route forward.

4. A handover that works

Identify the person or team receiving exceptions. Define the context to include, the status of the case and a way to tell whether an action has already happened.

Test missing information, an unavailable tool and a request outside the permitted scope. The aim is to keep work moving without asking a colleague to reconstruct the entire history. Include a way to pause the assistant when needed.

5. Records that help review

Keep the information needed to find operations, results and errors. Align access and retention with your internal rules. These records help people check the process; they do not provide a complete explanation of a model’s internal reasoning.

Make review a useful habit

Choose a review frequency that reflects the volume of work and the possible consequences of errors. Look at corrections, exceptions and checking time as well as completed tasks. A process that finishes quickly but needs substantial rework deserves attention.

When a document, rule or connection changes, rerun the relevant examples. Keep the level of autonomy tied to observed results. You can reduce, extend or maintain it according to what the team finds.

This framework creates a clearer way forward: AI contributes its part, while your team keeps an understandable view of the work and its decisions.

Explore our approach to AI agent oversight.

The NIST AI RMF Core sets out explicit responsibilities, measurement and ongoing risk management. Test those controls as you move from prototype to everyday use.

An AI agent can categorise a request, retrieve information from authorised sources and prepare a contextual reply. Its role depends on available connections and service rules. Refunds, commercial commitments and ambiguous records need a defined decision path involving the people responsible for those decisions.

Time often disappears between tools

A request arrives. Someone needs to find the record, read the earlier exchange, check a procedure and confirm a status. The final reply may be short, but preparing it involves several applications and a meaningful share of the adviser’s attention.

This is a useful process to observe before introducing an AI assistant. The opportunity is to make context easier to find and prepare the work. Your team can then give more attention to the request and the relationship.

Start with one category of requests

Choose a recurring subject whose answers depend on identifiable information. Keep straightforward questions separate from complaints and situations that require a commercial decision at the start.

One possible first scenario is order tracking. The assistant identifies the case, gathers authorised information and prepares a draft. An adviser reviews the content before sending it. This is an example to test with your tools and rules, rather than a guaranteed result.

A clear category also helps the team recognise when the assistant is being asked to do something outside its role. That makes the handover easier to design and explain.

Prepare the context the team needs

Identify the required sources: current procedures, authorised messages, case details and approved reply templates. Define what the assistant should do when sources disagree or a status is missing.

The result should make checking easier. A reply with supporting references is simpler to review than a draft whose origin has to be reconstructed. The adviser should be able to reach the context without repeating the entire search.

This preparation may also reveal information that needs to be better organised. That can improve the working day for people as well as the assistant.

Make room for exceptions

A customer disputes a detail, requests a commercial gesture or sends an unexpected document. These cases need a planned route.

Specify when the assistant stops, who receives the request and what goes into the handover summary. Keep a clear distinction between a proposed action and one already performed. The person taking over needs to understand the current state of the work.

The same principle applies when a tool is unavailable. A useful process makes that limitation visible and gives the team a way to continue.

Test the process from start to finish

Use representative examples, including complete and incomplete requests. Ask people familiar with the service and its commitments to review the results.

Check the relevance of the draft, the quality of the supporting information and the time needed to correct it. Also observe how easy it is to reject a suggestion or request more information. These actions are part of the everyday experience.

Reinvest the capacity created

If the process helps the team, decide where to use the time it frees: complex requests, case follow-up, better procedures or greater availability. This gives the measured benefit a practical purpose.

Then extend the scope by request category, using the same quality criteria. The assistant can contribute more over time while your team retains the decisions that need a person.

The useful promise is simple: less effort finding context, more room to give an attentive reply.

Explore our AI assistants for customer service and support.

Anthropic includes customer support among potential agent applications. Before expanding beyond draft replies, prepare oversight and human handover.

Start with a recurring task, its information sources and the result it needs to produce. Define permitted actions, test representative cases and compare total working time before and after, including review. A useful automation reduces the work involved without moving an excessive burden into checking outputs or dealing with exceptions.

Find the friction that keeps coming back

A useful starting point is often a task everyone recognises: copying the same information, finding documents, preparing a summary or responding to a recurring request. It may not look strategic. Yet it takes up space in the day and interrupts work that needs attention.

Before discussing tools, ask the team to describe how the task actually happens. Detours and exceptions can be as revealing as the intended process. You are looking for work to simplify, alongside the people who know it.

1. Map the real process

Write down the trigger, the information used, the applications opened and the expected result. Include points where someone waits for a reply or asks a colleague for help. A short description is enough if it reflects everyday work.

Observe several examples. A perfectly prepared case only tells part of the story. An incomplete document or an unclear request may reveal a substantial share of the effort. These situations belong in the trial too.

2. Choose a first scope

Look for a task that happens often enough to observe, uses accessible sources and produces a result the team can check. Keep connections and actions limited to what is needed.

In an illustrative scenario, an assistant prepares replies to delivery questions. It retrieves the relevant procedure and authorised order status, then produces a draft. It does not handle complaints or send anything without approval. This gives the team a clear way to test whether the process helps.

A narrow scope also makes it easier to understand why a result fails. You can adjust one source, one rule or one connection without changing every part of the working day at once.

3. Write down the boundaries

Define what the assistant may read, prepare and change. Specify which actions need approval, which missing information it should flag and which cases should go to a person. The handover needs an owner and enough context to continue the work.

These rules make the assistant’s role clear. They help everyone work from the same expectations and provide a reference against which to review its actual behaviour.

4. Measure all the work

Compare the current and assisted processes using comparable examples. Include review, corrections and exception handling. Generation time alone does not represent the time the team actually saves.

Tool costs, implementation and ongoing support also belong in the assessment. Freed time creates capacity; its value depends on what the team can do with it. It does not automatically become a cash saving.

5. Decide with the people using it

At the end of the trial, return to the team. Are there fewer handovers? Are supporting sources easy to find? Do exceptions reach the right person with enough context?

Choose the next step from that evidence: improve a source, adjust an approval, gradually extend the scope or keep a step manual. Each change should address an observed need.

Automation can then create space to serve customers, make decisions or develop ideas. A well-chosen first process can introduce a simpler way of working at a pace that suits your organisation.

Explore how we build these workflows with your team.

The NIST AI RMF connects context, measurement and risk management. Use our oversight checklist to define the actions the assistant may take.

Ask for one clearly scoped task, the required information and connections, verifiable deliverables, trial criteria and a budget separating setup from running costs. Clarify approvals, human handover and post-launch support. A first trial should produce evidence that helps you decide whether to continue, adjust or stop.

Buy clarity that helps you move forward

A first AI project often brings several ambitions together: simplify support, make better use of documents, prepare proposals faster or reduce administrative work. Good support turns those possibilities into a next step people can understand.

You should be able to explain the problem being addressed, the people involved and the result you will review. That clarity makes proposals easier to compare without requiring you to become an expert in every technology.

A scope connected to real work

Ask for a description of the current task and the proposed process. It should identify the trigger, information sources, expected result and cases that remain with your team.

The scope needs to be specific enough to test. “Bring AI into operations” leaves room for many interpretations. “Prepare a summary from authorised notes and send it for review” gives the people involved something concrete to discuss.

Also check what is outside the first stage: additional connections, historical data preparation or support for particular applications. Clear boundaries make a proposal easier to understand and reduce mismatched expectations later.

Connections checked early

A demonstration may work with carefully prepared information. Your environment can have different constraints: scattered documents, varying permissions or software with limited connection options.

Ask which checks happen before feasibility is confirmed. Who provides access? Which information is needed? What happens if a connection is unavailable? The answers may change the first scope, and it is useful to find that out early.

This is also a chance to identify preparation your team will need to do. Updating a procedure or agreeing who owns a source can be part of making the project usable.

A trial that leads to a decision

Agree representative examples and a way to assess results. Include incomplete or unusual cases. Identify who will review the work and how much time they can give to feedback.

At the end of the trial, you should be able to continue, adjust or stop. A list of completed tasks is not enough on its own. Look at quality, correction effort and what the team could do with the capacity created.

Costs explained over time

Separate implementation, the tools used, usage-based charges and ongoing support. Changes in scope should also have a clear process.

Ask how value will be assessed. Freed time can support better service or create capacity for more work. The assessment still needs to include the checking that remains and how that capacity could be used. A return-on-investment percentage without explicit assumptions offers little help when comparing options.

The same applies to schedules. Ask which dependencies affect delivery and which decisions your team will need to make. A plan is easier to use when responsibilities are visible.

A team that knows how to take over

Support continues through adoption, feedback and adjustments. Check where to report a problem, how to pause the process and who approves changes.

A good first project leaves you with something concrete: a better-informed decision, a process you can test and a team that understands its role. That is a useful foundation for what comes next, whatever the size of your organisation.

Explore our opportunity review for choosing a first use case.

The NIST AI RMF is a voluntary framework for examining AI risks across the system lifecycle. After scoping, explore the steps from prototype to everyday use.

RPA reproduces defined actions in a software interface. A copilot helps a person carry out a task. An AI agent can choose steps and use tools to pursue a goal within agreed boundaries. The right fit depends on how stable the workflow is, how much adaptation it needs and how results will be checked.

These distinctions draw on Microsoft’s description of RPA and Anthropic’s distinction between workflows and agents. A product label alone does not establish its level of autonomy.

Start with the work, not the label

Your team spends time finding information, drafting a reply or moving data between tools. The need is concrete. The language used to describe possible solutions is sometimes less clear.

RPA, copilots and AI agents can work together within the same process. The useful questions are what the system actually does, which information it uses and which decisions remain with your team. You can then choose the combination that fits your context.

Three approaches, three starting points

Fixed-rule automation, including RPA, follows a sequence of actions defined in advance. It can suit a stable process: collect a file, check its format and move the information into the right place. Changes to the tools or rules may require adjustments to that sequence.

A copilot helps a person produce or understand a result. You ask for a summary, a draft or help finding information, then decide what happens next. Its value depends on the quality of that help and the effort needed to check it.

An AI agent can choose steps and use tools within an authorised scope. It may look for missing context, prepare an action or request approval. That flexibility needs explicit boundaries and tests that reflect the situations your team encounters.

Look at the whole process

Consider an illustrative example: preparing a reply to a question about an order. A rule can identify the order number. An assistant can summarise earlier messages. An agent can consult authorised tools to gather the relevant details. Your team then checks the response before sending it.

The benefit comes from a simpler sequence of work: fewer repeated searches and information that is easier to verify. It does not depend on a technology label. Parts of the process can remain entirely manual if that meets the need better.

This also makes the project easier to explain. Everyone can see where the assistant contributes, what it leaves for a colleague and how the work reaches completion. The team is evaluating a familiar task, rather than an abstract promise of autonomy.

Ask the questions that shape the decision

Before choosing, describe a task the team actually performs. What starts it? Which result means it is finished? What happens when a request falls outside the usual path? Who takes over?

Next, check the available sources and possible connections. An assistant does not automatically fix an outdated procedure or a missing permission. This preparation belongs in the project alongside the design of the solution.

Agree how you will compare the current and proposed process. Measure total time, including corrections, review and exceptions. Also check whether the result is useful to the next person handling the case. A faster draft may have little value if it creates more work later.

Grow what works

A limited first scope helps reveal constraints without changing the entire organisation. Use representative examples, include difficult cases and ask users what genuinely makes their day easier.

At the end of the trial, you can keep the solution, adjust its role, add a step or stop. That freedom matters. The aim is to free up capacity for work that deserves your attention, with your team able to understand and shape the process.

To move from a choice to a practical next step, explore our AI opportunity review.

To assess the scope next, explore what to ask before your first AI project.