https://joinfinn.com/blog Perspectives, guides, and business use cases from Finn.en-US https://joinfinn.com/blog/what-is-agentic-automationhttps://joinfinn.com/blog/what-is-agentic-automationA customer writes, “Can you move my appointment to Friday afternoon?” Answering with the opening hours is easy. Changing the appointment requires finding the booking, checking availability, confirming a choice, and saving the change. Agentic automation describes software that can interpret a goal and work through the actions needed to achieve it. An agent works toward a result. An agent can ask for missing information, use connected tools, and adjust its next step based on what those tools return. If Friday is full, it can offer available alternatives instead of pretending the original request succeeded. The business still defines what is allowed. Understanding a customer’s request does not give the agent permission to waive a cancellation fee or override a staff schedule. Those decisions need explicit rules and, where required, a person’s approval. A fixed automation is often enough. If a job always follows the same steps with well-structured inputs, conventional automation may be simpler. Sending a standard internal alert when stock falls below a threshold does not necessarily need language interpretation. Agents become useful when requests arrive in different forms, need clarification, or require several supported actions. The choice is about the work, not which technology sounds newer. A reliable fixed process can remain part of a larger agent-assisted journey. Separate intention from completion. For the appointment example, a proposed time is not a saved booking. A successful result should come from the scheduling system. If the slot disappears before the update finishes, the agent needs to explain that and offer another option. This distinction keeps a fluent conversation from hiding unfinished work. Design the journey around a result your team can inspect, including a clear status when the agent cannot complete it. Try one bounded request. Choose a service your team understands. Write down its starting point, required information, permitted actions, approval needs, and final record. Test a normal request, an ambiguous one, and an unavailable action. Finn connects customer and employee conversations to approved business actions. The practical test is whether the configured workflow completes the intended job accurately and leaves people able to understand what happened. Further reading Moveworks: Agentic Automation Explained: https://www.moveworks.com/us/en/resources/blog/what-does-agentic-automation-meanExplainer https://joinfinn.com/blog/ai-agent-chatbot-or-taskhttps://joinfinn.com/blog/ai-agent-chatbot-or-task“What is your return policy?” and “Review yesterday’s unfulfilled orders every morning” are different requests. One needs an answer. The other describes an ongoing job. Treating both as the same kind of chatbot project makes setup and measurement harder than they need to be. Use an answer when information is the result. A policy question may be complete once the person receives accurate, relevant guidance. The system needs an approved source and the right access. It does not need to change a record just to demonstrate that it is an agent. Check whether the answer depends on a particular order, location, or customer agreement. General guidance should not be presented as a confirmed decision about a specific customer’s entitlement. Use an agent when the request requires action. A request to prepare a quote or change a booking needs more than an explanation. An agent can gather the details, use permitted actions, and ask a person to approve an exception. It should distinguish a draft from a committed change. Start with the result: a quote saved for review, for example. Sending it to the customer is an additional action. Naming that boundary helps the team choose sensible access and approval rules. Use a Task when the job should recur. In Finn, a Task is a saved job with a defined goal and a scheduled or event-based start. A morning review of unfulfilled orders belongs here. Each run is one attempt to perform the job, and its results should remain visible. Specify which orders qualify, who receives the review, and what happens when no orders qualify. A recurring start does not remove the permissions or approvals that would apply to the same work requested in a conversation. Combine them without confusing them. A customer may ask a question, then request an action. An employee may discuss a report, then decide to run that review every week. The experience should support those transitions while making any new commitment clear. Measure each against its purpose. An accurate answer, a completed action, and a successful recurring run are related outcomes, but counting messages alone will not tell you whether any of them worked. Further reading Moveworks: Agentic Automation Explained: https://www.moveworks.com/us/en/resources/blog/what-does-agentic-automation-meanExplainer https://joinfinn.com/blog/build-a-useful-company-knowledge-basehttps://joinfinn.com/blog/build-a-useful-company-knowledge-baseStart with one question your team answers often. For a hotel, it might be “When can we offer late checkout?” The aim is to make the approved answer easy to find and apply, then expand from there. Uploading every document at once makes it harder to discover which source is causing a bad answer. 1. Choose the source that owns the answer. List the relevant website pages, operating procedures, policies, and internal documents. Identify which one is authoritative and who maintains it. An old presentation may be useful background but should not overrule the current policy. Separate guidance from live records. A policy explains when late checkout is allowed. Room availability must come from the current booking or property system. A document cannot reliably substitute for that check. 2. Clean up conflicting instructions. Look for duplicate policies, missing location details, and exceptions stated without conditions. Ask the owner to resolve contradictions before the material becomes operational guidance. Keep the approved version identifiable. For an SOP, state the inputs, permitted actions, exceptions, and escalation contact. “Use your judgment” is not enough when the next step could promise a room or change a customer’s bill. 3. Test retrieval with real questions. Try the wording customers and employees actually use, including abbreviations and incomplete requests. Check whether the answer identifies the relevant source and asks for the location or booking details when they matter. Test with different employee roles too. A useful answer must respect access to the underlying information. A restricted document should not become visible simply because an agent summarizes it. 4. Establish a maintenance habit. Assign someone to review failed answers and source changes. When a policy is replaced, make sure the old guidance cannot continue to appear as current. Decide how urgently each kind of update needs to take effect. Use Finn’s knowledge experience to organize supported sources around the work they enable. Expand when the first set of questions works reliably, keeping live availability, balances, and customer records with their operational owners. Further reading Moveworks: Knowledge Discovery: https://www.moveworks.com/us/en/resources/blog/what-is-knowledge-discoveryHow-to https://joinfinn.com/blog/set-ai-permissions-and-approvalshttps://joinfinn.com/blog/set-ai-permissions-and-approvalsA sales agent may need to read customer details and prepare a quote. That does not mean it should change pricing rules or send every draft without review. A practical permissions plan starts with one job and separates its actions. 1. List the exact effects. For a quote workflow, distinguish reading product data, creating a draft, applying a discount, and sending the quote. For each action, identify the system that owns it and the people entitled to authorize it. Avoid a broad instruction such as “manage sales.” It leaves both the operator and the agent guessing about the boundary. Configure only the supported actions the workflow needs. 2. Define the exception that requires review. Specify when a person must decide: a discount outside standard terms, a recipient change, or a quantity beyond a limit. Make the approval request show the actual proposal and relevant facts. If the proposal changes materially after approval, check whether it requires a new decision. Approval of one price should not become permission to send a different price. 3. Keep access and model controls separate. An application’s permission to use an AI model does not grant access to customer records. Nor does an AI spending budget determine how much an agent can refund. These controls operate at different points. Finn Gateway applies rules to requests routed through it. The connected business actions still need their own authorization. Review both when introducing a workflow, instead of assuming one makes the other unnecessary. 4. Test both permitted and denied cases. Use an ordinary request, an exception requiring approval, a denied request, and a user from another location. Check that the system explains a missing permission without revealing protected information. Make an owner responsible for reviewing grants when roles change. Good permissions should let routine work proceed while giving consequential exceptions a clear path to the right person. Further reading Moveworks: AI Governance Frameworks: https://www.moveworks.com/us/en/resources/blog/enterprise-ai-governance-frameworks-typesHow-to https://joinfinn.com/blog/employee-onboarding-with-aihttps://joinfinn.com/blog/employee-onboarding-with-aiA new employee needs several things to be ready at once: the right instructions, approved access, equipment, and a manager who knows what is missing. AI can help coordinate that work, provided each action has a clear owner and a reliable source. 1. Begin with a confirmed employee record. Use the authoritative hiring record for the start date, manager, role, and location. A conversation about a possible hire should not trigger account creation. Confirm changes when a start date moves or an offer is withdrawn. Keep sensitive documents in their appropriate system. The coordination workflow should retrieve only the information needed for the current step rather than distribute a full personnel file. 2. Map the first-day requirements. For a new hotel supervisor, list the relevant operating guidance, equipment request, and approved systems access. Assign an owner to each requirement. Some steps can be prepared immediately; others depend on authorization. AI can help assemble the checklist and request missing information. Provisioning access requires a supported connection and the organization’s existing authority checks; a generated checklist is not proof that access exists. 3. Show what is actually ready. Track equipment requested separately from equipment delivered. Track access approved separately from access available. A manager should be able to see the remaining blocker without reading every message. If a tool fails, keep that step incomplete and direct it to the responsible team. Avoid sending a blanket “everything is ready” message based only on requests having been submitted. 4. Welcome the employee into a usable experience. Give the employee a clear place to ask questions and find approved guidance. Keep answers relevant to their role and location, with a visible route to a person for exceptions. In Finn, frame onboarding as a coordinated business journey across supported systems. Test the full path with a sample hire, including a changed start date and a missing approval, before using it for a live arrival. Further reading Moveworks: Employee Onboarding Automation: https://www.moveworks.com/us/en/resources/blog/enterprise-hr-onboarding-automation-guideHow-to https://joinfinn.com/blog/ai-it-support-with-a-clear-handoffhttps://joinfinn.com/blog/ai-it-support-with-a-clear-handoffAn employee who cannot use an application wants to get back to work. They do not want to choose between ten ticket categories. An AI support experience can gather the problem in ordinary language, consult approved guidance, and perform supported actions within the employee’s authority. 1. Select a narrow service. Start with one application or request type your IT team understands. Write down the common causes, safe troubleshooting steps, and information needed when the issue requires escalation. A useful first scope might be explaining how to request access and preparing the request for review. Do not imply that an agent can provision accounts unless the required connection and authorization are in place. 2. Ask for useful details once. Collect the application, the observed error, and when the problem began. Avoid asking employees to paste passwords, recovery codes, or other secrets into a conversation. Use the admitted employee identity where appropriate, rather than treating a name typed into chat as proof of access. The support workflow should preserve the organization’s normal identity and security controls. 3. Escalate with context. If the supported steps do not resolve the problem, send the relevant details, actions attempted, and remaining issue to the responsible team. Distinguish what the employee reported from what a tool verified. An employee should know whether a request is submitted, assigned, or resolved. Creating a ticket is progress, but it is not the same as restoring service. 4. Review the outcome. Track whether the employee’s original problem was resolved, whether they contacted support again, and how much review the IT team needed. Inspect repeated failures for missing guidance or an unsuitable scope. Finn can provide the conversational entry point and coordinate configured actions. The IT team remains responsible for its support procedures, access decisions, and the set of tools made available to the agent. Further reading Moveworks: AI IT Support: https://www.moveworks.com/us/en/resources/blog/enterprise-guide-to-tier-1-help-desk-automationHow-to https://joinfinn.com/blog/test-an-ai-workflow-before-publishinghttps://joinfinn.com/blog/test-an-ai-workflow-before-publishingA perfect demo usually follows the happy path. A useful release test also checks what happens when information is missing, someone says no, or a connected system cannot finish an action. Start with a workflow your team can judge from real records. 1. Define the expected outcome for each case. For a booking change, record the original appointment, permitted alternatives, required confirmation, and expected saved result. Include a case where no alternative is available. The correct response there may be an explanation and a handoff. Use a safe test environment or approved sample records for actions that change data. Make sure the test cannot accidentally send customer messages or alter live bookings. 2. Include the boundaries. Test an unauthorized employee, a customer whose details do not match, a request outside policy, and a material change after approval. These cases reveal whether the workflow respects its configured limits. Check the output for unintended disclosure too. A refusal should not reveal the confidential information that caused it. A public message should not contain internal notes. 3. Simulate an incomplete action. Consider a quote that saves but cannot be emailed, or a booking slot that disappears before confirmation. The result should identify the completed and incomplete steps rather than report blanket success. When retrying an action, verify that the integration avoids duplicate effects. The team should know whether a retry checks an existing result or attempts a new change. 4. Make the release decision explicit. Record which cases passed, which remain outside scope, and who owns the workflow after publication. A known limitation may be acceptable if the experience explains it and routes the work appropriately. Repeat the relevant tests when instructions, permissions, or connected actions change. Finn’s test-before-publish experience should serve a business decision: whether this specific workflow is ready for the people who will use it. Further reading Moveworks: End-to-End Service Orchestration: https://www.moveworks.com/us/en/resources/blog/end-to-end-service-orchestration-checklistHow-to https://joinfinn.com/blog/five-ai-use-cases-finance-operationshttps://joinfinn.com/blog/five-ai-use-cases-finance-operationsFinance teams spend time collecting facts before they can make decisions. That preparatory work is a useful place to apply AI. These illustrative journeys focus on administration and review; payment authority and accounting decisions stay with the business. 1. Explain an invoice. 2. Prepare an overdue-account review. For an invoice question, retrieve the correct document and relevant order or agreement. Prepare an explanation using the recorded line items. If a charge is disputed, identify the item and send it to the responsible person instead of inventing a justification. For an overdue-account review, use current balances and agreed terms. Group accounts for employee review and show the reporting time. Recheck the balance before any approved reminder so customers who have paid are not contacted unnecessarily. 3. Assemble the facts behind a discrepancy. When an invoice and an order disagree, gather the records and describe the mismatch. Show which values differ and which source owns each one. A useful result is a reviewable exception, not an automatic adjustment. Missing information should remain missing. An agent should not infer a receipt, delivery confirmation, or approval merely because one would normally exist in the process. 4. Draft a customer billing response. Prepare a reply that explains the recorded state and the available next step. Keep internal collection notes and unrelated account details out of the customer message. Route exceptions to someone with appropriate authority. Review the recipient, wording, and sending rules before delivery. Drafting a message and sending it are separate actions, especially when many accounts are involved. 5. Prepare a recurring operating summary. A scheduled review can summarize supported billing records for a defined period. Specify the entities, currency treatment, exclusions, and comparison period. Do not combine amounts in different currencies without an agreed conversion method. In Finn, configure each journey around the records and actions your connections support. Measure time spent preparing and reviewing the work, along with errors caught and unresolved exceptions. Avoid treating a polished report as an independently verified financial statement. Further reading Moveworks: AI Use Cases for Finance Teams: https://www.moveworks.com/us/en/resources/blog/ai-use-cases-in-financeUse cases https://joinfinn.com/blog/ai-wholesale-quote-workflowhttps://joinfinn.com/blog/ai-wholesale-quote-workflowA buyer asks for 200 branded items by the end of the month. The request may arrive in email, while pricing, customer terms, and product details live elsewhere. A useful agent-assisted journey gathers those facts without making the customer repeat the order to every team. Collect the details that change the price. Ask for the product, quantity, customization, delivery location, and required date. Identify the correct customer account using the approved process. Do not assume a wholesale rate applies merely because the buyer requests it. Retrieve current product and pricing information from the chosen owners. When a lead time requires a supplier or production check, leave it unconfirmed until that check is complete. Prepare a proposal people can inspect. Show quantities, unit prices, delivery assumptions, and any missing detail. Link the proposal to the relevant customer record. Identify exceptions such as a requested discount or an unusual delivery deadline. A draft should be clearly labeled. The operations team needs to distinguish what the buyer asked for from what the business is prepared to promise. Approve the exact offer. Ask the appropriate employee to review the proposal and its exceptions. If the quantity or terms change afterward, determine whether a new approval is required before proceeding. Keep a declined proposal from accidentally moving into the sending step. The employee should be able to explain the required change and continue the work without losing the request. Save, send, and follow through. Record the approved quote in the supported system and send it only to the verified recipient under the business’s rules. A saved quote and a delivered email are separate results; show either failure accurately. Finn’s customer and employee agents can support both sides of this configured journey. Measure time to an approved quote, missing-information loops, and delivery failures. Do not count a drafted offer as a completed sale. Further reading Moveworks: Cross-Department Workflows: https://www.moveworks.com/us/en/resources/blog/enterprise-ai-agents-for-cross-department-workflowsUse cases https://joinfinn.com/blog/ai-appointment-follow-upshttps://joinfinn.com/blog/ai-appointment-follow-upsTomorrow’s schedule contains several unconfirmed appointments. A spa, dental practice, or massage business can use a defined follow-up journey to prepare contact, handle replies, and surface exceptions. The work starts with the current schedule, not yesterday’s exported list. Select the right appointments. Define the location, date range, booking state, and eligible contact method. Exclude canceled visits and people whose contact preferences prohibit the proposed message. Use the location’s time zone for both selection and sending. Preview the selected records before activating a recurring Task. Include an appointment that has just been confirmed to check that the workflow does not contact it unnecessarily. Send only what is needed. Use approved wording that identifies the appointment and explains how to respond. Avoid including sensitive internal notes. Set permitted sending windows and frequency limits appropriate to the business. For a dental practice, keep this journey administrative. Questions requiring clinical judgment should reach an appropriate professional through the practice’s established process. Treat a reply as a new decision point. A confirmation can update the booking through a supported action. A request to reschedule needs current availability and the customer’s choice before a change is committed. A request outside policy may need employee review. Do not interpret silence as confirmation unless the business has explicitly established that meaning for the particular process. A delivered reminder only proves that the messaging step succeeded. Review the exceptions and the result. Show undelivered messages, ambiguous replies, and bookings still awaiting action to a named owner. Check that updates appear in the scheduling system before telling the customer the change is complete. Use Finn Tasks for the recurring start and configured agent actions for the work. Measure confirmed appointments, useful rescheduling, opt-outs, and staff effort—not simply the number of messages sent. Further reading Moveworks: Self-Service Automation: https://www.moveworks.com/us/en/resources/blog/self-service-automation-transforms-support-operationsUse cases https://joinfinn.com/blog/ai-property-maintenance-journeyhttps://joinfinn.com/blog/ai-property-maintenance-journeyA tenant reports a leaking tap and provides a photo. The property team needs the location, the right contractor, any required spending approval, and access arrangements. An agent can help coordinate supported steps, but creating a maintenance ticket is only the beginning. Establish the request and the property. Confirm the relevant unit and collect a concise description. Distinguish the tenant’s report from verified facts. Follow the property’s established escalation process when the report suggests an urgent issue. Avoid promising a repair time before availability is confirmed. Tell the tenant what has been recorded and which step comes next. Prepare the work for a decision. Gather the relevant maintenance record, responsibility rules, and contractor details. If a quote is needed, record it as pending. If spending approval is required, show the proposal to the authorized person. An earlier approval should not automatically cover a materially different scope. A contractor discovering another issue may require a separate decision before additional work is authorized. Coordinate access and scheduling. Collect permitted access times and confirm the contractor’s availability through supported channels. Share only the information the contractor needs. Keep the tenant informed of the agreed appointment. If the appointment changes, update the owning record and communicate the confirmed change. Sending a request to the contractor does not mean the contractor has accepted it. Close against the actual outcome. Distinguish scheduled, attended, and resolved. A completion report may require review or tenant confirmation under the property’s process. Unresolved work should remain visible with an owner and next step. Finn can connect the customer-facing request with employee coordination and configured record updates. Track time to assignment, time waiting for approval, repeat visits, and reopened requests to see where the journey needs improvement. Further reading Moveworks: End-to-End Service Orchestration: https://www.moveworks.com/us/en/resources/blog/end-to-end-service-orchestration-checklistUse cases https://joinfinn.com/blog/five-ways-teams-can-work-with-aihttps://joinfinn.com/blog/five-ways-teams-can-work-with-aiEmployees do not need to begin with a company-wide transformation. They need a useful job, relevant information, and a way to review the result. These examples show where an AI workspace can help while keeping the employee involved in the decision. 1. Prepare for an account conversation. Ask for a summary of accessible customer records, recent requests, and open issues. Specify the account and the time period. Check the sources before treating the summary as a complete history. The result should identify unresolved questions rather than fill gaps with plausible details. Use it to prepare for a conversation, not to replace current confirmation of a customer’s needs. 2. Compare documents. 3. Draft a response. Compare two versions of an operating procedure and ask which steps changed. Keep the original documents available so the owner can inspect the differences. The output can support review without declaring the new policy approved. For a customer response, give the agent the relevant facts and desired outcome. Review the wording, recipient, and any promise before sending. A useful draft saves preparation time while leaving the final business commitment explicit. 4. Create a small decision tool. A simple calculator can help compare quantities, rates, or staffing assumptions. Require visible inputs, clear units, and an explanation of the calculation. Test an ordinary case and a boundary case before relying on it. Treat generated artifacts as reviewable work. A convincing interface does not establish that its formula or assumptions are correct. The person using it should know its intended scope. 5. Turn a useful review into a recurring Task. Once a manual review is dependable, define its schedule, record scope, output destination, and approval rules. For example, prepare a weekly list of unresolved customer requests for the responsible manager. Finn brings conversations, artifacts, and Tasks into the workspace. Start with one of these jobs using supported connections, review the output, and refine it with the team before expanding its scope. Further reading Moveworks: Employee Productivity Use Cases: https://www.moveworks.com/us/en/resources/blog/agentic-ai-employee-productivity-impact-use-casesUse cases https://joinfinn.com/blog/the-interface-should-fit-the-jobhttps://joinfinn.com/blog/the-interface-should-fit-the-jobAsk someone to compare three catering proposals. They probably want a table. Ask them to correct a delivery address, and a small form might be enough. Ask them to explain an unexpected charge, and a conversation makes sense. The future of business software should make room for all three. Start with the decision, then choose the display. We believe the useful question is what a person needs to understand or decide next. A chat window can make a complex request easy to express. But turning every answer into a long message can make the next step harder. People should not have to reconstruct a budget from paragraphs or scroll through a conversation to find the final version of a quote. Consider a hotel manager planning staffing for a busy weekend. They might ask Finn to compare expected arrivals with the current roster. The result should make the gap visible. A table can show coverage by shift; a calculator can expose assumptions about arrival volume. The conversation explains the reasoning and lets the manager request changes. An artifact gives the work something to stand on. A report, proposal, or small app can remain useful after the chat ends. It has a name, a purpose, and a place where colleagues can find it. People can examine the result without replaying every prompt that produced it. This is the role we see for Finn’s Library alongside conversations. A generated output should be easy to inspect and return to. If the user changes an assumption, the revised result should be distinguishable from the version that was previously reviewed. A beautiful display is only useful when people know what they are looking at. Keep the action visible. An interface that prepares a proposal should make that different from an interface that commits a change. Reviewing a staffing suggestion is not publishing the roster. Editing a quote is not sending it to the buyer. A clear action boundary gives people confidence to explore without accidentally changing the business. Some work will still be faster in a familiar editor. People who review dozens of records need sorting, selection, and comparison. AI should reduce the effort around those tools, not remove them because conversation is fashionable. Let the work move between forms. Our direction for Finn is a workspace where a request can become the most useful kind of result: a conversation, a document, a table, or a small interactive tool. People can ask for a change and inspect what changed before proceeding. The best interface is not the one with the fewest buttons. It is the one that makes the next decision clear. Let conversation handle ambiguity, let structured views handle comparison, and let explicit controls handle consequential actions. Further reading Sierra: Agents as a Service: https://sierra.ai/blog/agents-as-a-servicePerspective https://joinfinn.com/blog/the-conversation-ended-the-job-didnthttps://joinfinn.com/blog/the-conversation-ended-the-job-didntA buyer asks for a custom quote on Monday. A manager approves the price on Tuesday. The buyer changes the quantity on Thursday. None of this is unusual. Yet a system designed around a single conversation can lose the thread precisely when the business needs it most. Waiting is part of the work. Business jobs rarely proceed in one uninterrupted burst. A supplier must respond. A customer must choose a time. A staff member must approve an exception. These pauses are not failures. They are ordinary parts of getting something done. The useful question during a pause is what the job is waiting for and who owns the next move. An unresolved property repair should show whether the team needs access from the tenant, a contractor’s estimate, or an owner’s decision. “In progress” alone says very little. Remember the request. Check what changed. Continuity should not mean blindly trusting yesterday’s information. A booking may have been canceled. A price may have changed. A payment may have arrived while a reminder was being prepared. Before taking the next action, the system needs current business truth. In the quote example, the earlier approval concerned a particular quantity and price. A later change may require another review. Good continuity preserves the reason for the previous decision while recognizing that it does not authorize every future version. Follow up with a reason. A useful follow-up tells someone what is needed and why. It might ask a buyer to confirm a detail that prevents a quote from being completed. It should stop when the customer responds, declines, or no longer qualifies. Repeated messages without a current purpose turn persistence into noise. For a repair, the next step may be an internal reminder rather than another message to the tenant. Customer contact preferences, business hours, and the state of the job should shape the communication. More activity does not necessarily move the work forward. Give ongoing work a home. Finn’s Tasks and operating views are part of this broader idea: businesses need to see work that outlasts a chat. A recurring Task and a single unresolved request are different things, but both need a clear purpose, an owner, and visible outcomes. The ambition is continuity people can understand. When they return, they should see what happened, what remains, and what they can do next. Closing the conversation should never make the unfinished job disappear. Further reading Sierra: The next Horizon in agents: https://sierra.ai/blog/horizonPerspective https://joinfinn.com/blog/your-best-operating-knowledge-isnt-in-a-manualhttps://joinfinn.com/blog/your-best-operating-knowledge-isnt-in-a-manualAsk the most experienced person at a front desk how they handle a difficult booking. The answer usually starts with “It depends.” Then come the details: the room type, the guest’s history, the arrival time, and who can approve an exception. A one-page procedure rarely captures all of it. Experience is valuable because it notices the exceptions. Manuals tend to describe the intended process. Experienced employees know where it bends. A wholesale account manager knows which missing details will delay an order. A café owner knows when a catering request needs a kitchen review before anyone promises a delivery time. That knowledge can improve AI behavior, but it should not be treated as automatically correct simply because someone said it. A workaround may be outdated. An exception may have applied to one customer. Capturing judgment should include asking when it applies and who can approve it. Turn a story into a reviewable rule. Start with a real explanation of how the job is done. Ask what information the employee checked, what alternatives they considered, and why they escalated. Separate the general policy from the special circumstances of that case. For example, a property manager might explain that repairs above a spending threshold require owner approval, while an urgent safety issue follows a different process. Those are business decisions to document and review. A transcript containing both should not silently become permission for an agent to act. Give knowledge an owner. A useful operating instruction needs someone responsible for keeping it current. When a policy changes, the team should know which guidance has been replaced. If two sources conflict, the conflict should reach the person who can resolve it rather than be hidden inside an answer. Finn’s knowledge experience should support this discipline: bring relevant material together, make its source understandable, and connect approved guidance to permitted work. The value comes from maintained business knowledge, not the number of files uploaded. Let the people closest to the work improve it. Operators should be able to identify a bad answer, explain the missing nuance, and propose a better approach. Review and testing then turn that suggestion into a controlled change. This gives the business a way to improve without making every adjustment a vendor project. We believe the strongest enterprise AI will reflect the expertise of the people who serve customers every day. Preserving that expertise means making it explicit, questioning it where necessary, and ensuring the business still owns the final decision. Further reading Decagon: The customer relationship was always yours: https://decagon.ai/blog/our-bet-on-youPerspective https://joinfinn.com/blog/who-owns-your-ai-on-monday-morninghttps://joinfinn.com/blog/who-owns-your-ai-on-monday-morningThe demonstration worked. The team approved the launch. Then Monday arrives with a changed policy, an unavailable connection, and a customer request nobody included in the test. Who decides what happens next? That question belongs in the business case before the launch party. Ownership needs a name. An AI agent can span several systems without owning any of the business decisions inside them. Someone must decide whether its answers are useful, whether its actions remain appropriate, and which failures need immediate attention. A shared inbox is not a substitute for that responsibility. For an appointment business, the operating owner might be the practice manager. IT supports connections and access. A designated reviewer handles policy changes. These can be lightweight responsibilities in a small company, but they still need to be understood. Sort exceptions by consequence. A missing document and an incorrect customer action should not receive the same response. The first may wait for a routine review. The second may require stopping the affected workflow, checking what changed, and contacting the responsible person. A good operating view makes the unfinished or questionable work visible. It should help people determine whether the issue comes from missing information, an approval, or a failed action. The purpose is to direct attention, not overwhelm the team with every technical event. Change deserves its own review. A new promotion can alter pricing behavior. A connection update can change what an agent can do. A revised instruction can improve one case while breaking another. Treating these changes as routine text edits understates their effect on real work. Before publishing a material change, test ordinary cases and the exceptions that matter. Make clear which behavior was approved and how people will notice problems afterward. The size of the review should match the consequence of getting it wrong. Buying software does not outsource business judgment. A platform can provide tools for testing, history, permissions, and operating review. It cannot decide which promise your company should make to a customer. The business must retain that authority whether it builds its own AI or subscribes to a product. This is how we think about Finn: software that helps a team operate AI with clarity. The goal is less repetitive work, with a manageable way to handle what remains. If nobody can explain who owns the agent on Monday morning, the rollout is missing an essential part. Further reading Decagon: AI agents are never done: https://decagon.ai/blog/the-new-build-vs-buy-calculusPerspective https://joinfinn.com/blog/your-company-doesnt-need-ai-that-knows-everythinghttps://joinfinn.com/blog/your-company-doesnt-need-ai-that-knows-everythingA folder contains an old price list, a sales presentation, and a signed customer agreement. All three mention the same product. Which price should an agent use? Giving it more documents does not answer the question. The company needs a clear way to distinguish background information from an authoritative record. More information can create more ambiguity. Businesses preserve drafts, exceptions, archived policies, and informal discussion. These are useful records of how work happened. They are not equally suitable as instructions for what should happen now. A quote needs current commercial terms. A booking needs current availability. An explanation of a policy needs the approved policy that applies to the customer. Choosing the relevant source is part of doing the job, not a finishing touch on the answer. Separate history from current truth. A previous conversation can explain why a customer requested a change. It cannot prove the change is still pending. The customer may have called another employee or completed it through a different channel. Consider a billing follow-up. The earlier conversation says a payment was overdue. Before sending a reminder, the workflow should check the billing record again. Remembering the conversation helps explain the situation; checking the record prevents an unnecessary or embarrassing message. The right answer depends on the person asking. Two employees can ask the same question and legitimately receive different results because their access differs. A branch manager should not gain access to another branch’s private records simply because an agent can search them. Access needs to apply when information is retrieved and when an action is performed. Hiding a link after confidential information has already appeared in an answer is too late. A useful explanation can acknowledge missing access without exposing the protected content. Make uncertainty actionable. When two approved sources disagree, a confident guess is not progress. Show the conflict and identify the decision required. When a record is stale or a connection unavailable, explain what cannot yet be established. Finn’s knowledge and connected systems serve different roles in this picture. Knowledge explains the business; current records describe its state. Our view is that trustworthy AI comes from using both carefully. Knowing when to ask a person is part of intelligence, not an admission that the product has failed. Further reading Glean: From enterprise search to enterprise context: https://www.glean.com/blog/from-enterprise-search-to-enterprise-context-what-ai-agents-actually-needPerspective https://joinfinn.com/blog/a-faster-employee-doesnt-always-make-a-faster-companyhttps://joinfinn.com/blog/a-faster-employee-doesnt-always-make-a-faster-companyA proposal that once took two hours now takes ten minutes to draft. It still waits two days for pricing approval and another day for a customer detail. The employee is faster. The customer barely notices. This is why personal AI productivity and business performance need to be examined together. Look at the spaces between tasks. Work spends time waiting for decisions, missing information, and ownership. These delays can be larger than the time spent producing the document or updating the record. Improving one step leaves the rest of that journey intact. For a hospitality group, preparing a guest-service summary quickly is useful. Getting the right person to resolve the issue before the guest leaves may be more important. The question is where elapsed time accumulates and which of those waits the business can reasonably reduce. A shared conversation needs shared purpose. Putting more people and an agent in a thread does not automatically improve coordination. Participants need to know what outcome they are working toward, which proposal is current, and who is expected to decide. Otherwise the thread becomes another place to ask for status. Imagine a sales representative and an operations manager reviewing a custom order with Finn. The agent can help prepare the proposal and surface missing details. The people bring commercial judgment and delivery responsibility. A useful shared view makes their contributions explicit rather than treating every message as permission to proceed. Reduce the effort required to decide. An approval request should include the relevant proposal, the exception, and the consequences of the decision. Asking “Can I proceed?” without that context simply transfers research work to the approver. Likewise, a handoff should identify what has already been checked and what remains uncertain. This lets the next person contribute judgment instead of reconstructing the job. Better preparation can reduce coordination effort even when the decision itself must remain human. Measure the journey as well as the person. Track elapsed time, time waiting for review, and repeat requests for information alongside drafting speed. A faster draft can still be a worthwhile improvement, but those additional measures show where further work is needed. Our vision for Finn’s human–agent collaboration is to make the whole job easier to finish. Some conversations are private; others involve a group. Across both, the useful unit of progress is a clear decision or completed action that helps the next person move forward. Further reading Glean: Proactive AI for single and multiplayer work: https://www.glean.com/blog/proactive-ai-for-enterprisesPerspective https://joinfinn.com/blog/dont-make-your-customer-start-overhttps://joinfinn.com/blog/dont-make-your-customer-start-overA customer explains a damaged delivery, provides the order number, and uploads a photo. Then a person joins the conversation and asks for the order number again. Whatever the reason inside the business, the customer experiences one thing: the effort they already made did not count. Continuity is a service decision. An automated interaction and a human interaction may be handled by different systems. The customer still sees one company. They should not have to understand its internal boundaries to receive help. A useful handoff carries the request, the relevant records, the information already collected, and the reason a person is needed. It also distinguishes what the customer reported from what the system verified. A summary that turns an unverified claim into a fact can create a different kind of service problem. Give the receiving employee a next step. A transcript can preserve everything while still making the employee search for what matters. A concise handoff should explain the pending decision: approve an exception, investigate a mismatch, or clarify something the agent could not establish. For a property manager, that might mean a tenant has provided access times but a contractor has not confirmed availability. For a hotel, it might mean a guest requested a room change and the front desk needs to review available options. The next person should be able to start from there. Do not confuse continuity with skipping checks. Sometimes a person must verify identity or confirm a consequential change. Explain why the check is needed and reuse appropriate information where possible. Avoid making the customer repeat unrelated details simply because a new employee has joined. The same care applies across channels. Moving from a public conversation to a private one can protect sensitive information. Carrying context should respect who can see it, rather than copying the entire history into every channel. Make help easy to reach. A request for a person should lead to a clear path, with an honest indication of availability and what will happen next. Trying to keep every conversation automated can turn an appropriate escalation into an obstacle. Finn’s customer and employee sides are built around a common purpose: helping the business finish the request. A human handoff can be a successful step in that journey. The standard should be whether the customer makes progress, not whether the software keeps the conversation to itself. Further reading Parloa: Customer automation’s trust problem: https://www.parloa.com/blog/cx-automation-has-a-trust-problem/Perspective https://joinfinn.com/blog/your-next-workspace-starts-with-a-conversationhttps://joinfinn.com/blog/your-next-workspace-starts-with-a-conversationA customer asks for a different delivery date. An employee opens the order, checks availability, messages a colleague, updates the record, and writes back. The request took one sentence. Completing it took a tour of the company’s software. We have grown so used to that tour that we rarely question it. The request should be the starting point. Our view is simple: businesses have spent years organizing work around software. AI gives us a chance to organize software around the work. An employee should be able to describe an outcome without first knowing which application, menu, and form can produce it. That does not make the underlying systems irrelevant. Orders still need an owner. Payments still need a reliable record. Permissions still apply. What changes is who carries the request between those systems. Software can take on more of the coordination that employees currently perform by hand. A conversation can open more than a chat. Imagine asking for a report on outstanding property repairs. The useful result is a report you can inspect, discuss, and share. Ask how an extra contractor would affect the backlog, and a small calculator may be more helpful than five paragraphs. Ask to assign the work, and you need a reviewable proposal with names, dates, and responsibilities. A conversation is a natural way to express intent, but it is not the best display for every result. Tables, documents, forms, and small apps still have a place. The workspace should make it easy to move between asking, inspecting, correcting, and acting while keeping the work connected. People need a place in the conversation. An employee might ask Finn to prepare a wholesale quote, invite an account manager to review the price, and continue after approval. The account manager needs to see the exact proposal, not a vague request to approve whatever the agent does next. A later change to the discount should be visible before anything is sent. That is why we see customer conversations and internal collaboration as connected parts of the business. A customer can stay in email while the employee works in the Finn workspace or a connected team channel. They need different views of the same job, with appropriate access for each person. The best workspace makes responsibility clearer. Putting AI in the middle must not make work harder to understand. People should know what was requested, what changed, what is waiting, and who can move it forward. If a connection fails, the interface should expose the unfinished step. If a person must decide, that decision should have a clear owner. This is the direction behind Finn’s AI OS: a place to talk, work together, review artifacts, and complete permitted actions across company software. The test is whether someone can finish a real job with less coordination and more clarity. A more impressive conversation alone is not enough. Further reading Moveworks: The AI Assistant on Web: https://www.moveworks.com/us/en/resources/blog/ai-assistant-on-webPerspective https://joinfinn.com/blog/what-would-your-business-do-with-more-capacityhttps://joinfinn.com/blog/what-would-your-business-do-with-more-capacityEvery business has a list of things it would do if the team had more time. Follow up with smaller accounts. Check on a guest after a problem. Find out why a regular customer stopped booking. These jobs rarely appear in the backlog. They disappear before anyone writes them down. Look at the work you have stopped considering. Cost reduction is a reasonable reason to adopt AI. But it starts with the work already being done. We think leaders should also examine useful work that never happens because each individual opportunity seems too small to justify the effort. Consider a DTC brand that can give its largest wholesale accounts personal attention but leaves smaller buyers with a standard form. Or a property manager who handles urgent repairs but rarely has time to summarize recurring problems across buildings. More capacity could change the level of service they offer, not simply the time spent offering it. Extra activity has to earn its place. More follow-ups are not automatically better. A customer may not want another message. More reports are not useful if nobody makes a decision from them. Before automating neglected work, ask who benefits, what would change, and how you would know whether the extra effort helped. For an appointment business, the opportunity might be helping eligible customers find a suitable opening. Success could mean a confirmed booking that would otherwise have remained empty. It should also account for opt-outs, staff effort, and whether the customer was happy with the experience. Sending more messages is only an intermediate step. Find the next constraint before you remove the first. Suppose an agent can prepare far more quotes than a sales team previously handled. If every quote waits three days for a manager, the business has moved its bottleneck. It may need clearer pricing rules, a narrower approval requirement, or more review capacity before faster drafting produces faster sales. The same applies to hospitality. Handling more guest requests creates little value if housekeeping has no room in its schedule. A useful operating view connects demand with the team’s ability to deliver. AI should make that constraint visible rather than hide it behind a rising activity count. Make a deliberate choice about the time returned. When a workflow becomes easier, decide where the recovered time goes. An account manager could cover more customers, spend longer on complex orders, or improve service for existing buyers. Those are different strategies. The choice belongs to the business, and employees should help shape it. Start with one neglected opportunity and a small, measurable scope. Include the cost of supervision and the downstream work it creates. Compare the outcome with what happened before. Our ambition for Finn is to make more useful work economically possible while keeping the people responsible for the business in control of what gets done. Further reading Wonderful: Unlocking Capacity: The Real ROI of AI: https://www.wonderful.ai/blog-articles/unlocking-capacity-the-real-roi-of-aiPerspective https://joinfinn.com/blog/every-team-ai-one-set-of-controlshttps://joinfinn.com/blog/every-team-ai-one-set-of-controlsThe person who sees an opportunity for AI may be a reservations manager, a finance analyst, or someone answering customer emails. They know the repetitive work because they do it. A company should make those ideas easier to try without asking every team to become its own security and infrastructure department. Make the approved path useful. If getting help requires a long process and the approved tool cannot do the job, employees still have a problem to solve. A workable company AI strategy needs an accessible place to ask, experiment, and produce something useful, alongside clear limits on what can be accessed or changed. For a finance team, that might mean preparing a draft explanation of an invoice using approved records. For a hotel team, it could mean summarizing guest-service requests. Each team should understand which sources and actions are available before it relies on the result. Separate business decisions from shared infrastructure. A department understands what a good result looks like. IT understands which applications, model providers, and data arrangements the company can support. Both responsibilities matter. Asking one side to make every decision slows the work and can leave important details unexamined. A shared AI Gateway can give connected applications common controls for model access, data handling, and spending. Teams can then build around their own work without each inventing a separate provider connection and cost policy. Those controls cover traffic routed through the Gateway; they do not automatically govern every AI tool used anywhere in the company. Model access is not permission to act. Allowing an application to use a model does not authorize it to issue a refund, change a booking, or email a customer. Those actions still require business permissions and, where appropriate, approval of the specific proposal. A spending limit and a refund limit answer entirely different questions. Keeping that distinction clear helps the organization expand access thoughtfully. An employee may be allowed to draft a customer response but not send it. A branch manager may approve actions for one location without seeing another location’s records. Useful freedom comes from permissions that match the job. Give people an understandable boundary. When a request cannot proceed, explain the next step. A budget limit may require an application owner’s review. Restricted data may require an approved processing route. Missing access may require a different employee. Quietly trying a less restricted route would defeat the rule the company intended to apply. Our view is that enterprise AI should combine broad participation with clear responsibility. Finn’s workspace gives people a place to work with agents; its Gateway gives connected AI applications shared controls. The business still decides which work to authorize, who owns the outcome, and when a person needs to step in. Further reading Moveworks: The AI Strategy Paradox: https://www.moveworks.com/us/en/resources/blog/ai-strategy-paradoxPerspective https://joinfinn.com/blog/the-work-starts-after-the-answerhttps://joinfinn.com/blog/the-work-starts-after-the-answer“Can you send me a quote for 200 custom pieces?” It sounds like one question. Behind it are product details, pricing, delivery dates, and someone who can approve the deal. The customer should not have to manage all of that. Write down what “done” means. For this illustrative wholesale order, the goal is an approved quote saved against the right customer and delivered to the right person. A friendly explanation of wholesale pricing does not finish that job. Neither does a draft that nobody knows is waiting for review. Define the result before you design the conversation. Which record changes? Who needs to decide? What should the customer receive? These questions make a vague promise of automation into something a team can test. Keep the customer and the team in the same story. The customer may start in email while the account manager works in Slack. Finn’s customer and employee agents serve both sides of that exchange. The useful handoff includes the request, the proposed quote, the pricing source, and the decision required. The employee should not need to interview the customer again. Approval needs to refer to the exact proposal. If the quantity or discount changes afterward, the earlier approval is no longer enough. The customer conversation can stay simple even when the work behind it requires care. Check the result before announcing it. Suppose the quote saves successfully but the email service rejects the recipient. The correct status is “quote saved; delivery needs attention.” Calling the entire job complete would hide the one step that still matters to the customer. The same distinction applies to a hotel’s late-checkout request or a property repair. A message to housekeeping is not a confirmed room release. A contractor assignment is not a completed repair. Each business decides which recorded result closes the job. Start with the handoff you repeat every day. Choose a familiar request, connect the records it needs, and make the approval step clear. In Finn, that means giving the agent the right knowledge and permitted actions, then testing the journey from both the customer’s and employee’s perspective. A useful test includes an ordinary request, a missing detail, a rejected approval, and a failed action. You should be able to see what happened and who owns the next step in every case. That is a better foundation for growth than a perfect opening reply. Further reading Wonderful: AI Doesn’t Care About Your Org Chart: https://www.wonderful.ai/blog-articles/ai-doesnt-care-about-your-org-chartCustomer operations https://joinfinn.com/blog/choose-your-first-ai-taskhttps://joinfinn.com/blog/choose-your-first-ai-taskStart with a sentence someone on your team would actually say: “Every afternoon, follow up on tomorrow’s unconfirmed appointments.” It tells you far more than “We need an AI strategy.” There is a job, a time, and a reason to do it. Choose a repeatable inconvenience. Look at work your team already repeats. A spa checks tomorrow’s bookings. A café prepares the next day’s catering list. A property manager follows up on open maintenance requests. Ask the people doing that work where they lose time and which mistakes they regularly catch. Choose a task with accessible records and a clear result. If nobody can explain the current process, spend time clarifying it first. AI does not settle a disagreement about who owns a booking or which policy is current. Give the job a small, precise boundary. For an appointment reminder, specify the location, date range, eligible booking status, approved sender, and permitted contact window. Exclude people who have opted out. Decide whether Finn may send the reminder or should prepare a list for review. Sending and confirming are different outcomes. If the first Task only sends reminders, measure it against that goal. Recording a customer’s reply or changing a booking introduces additional actions that need their own rules. Preview the people affected. Before activation, inspect a sample of selected appointments. Include a canceled visit, an appointment that has just been confirmed, a missing contact detail, and a customer at another branch. A good preview explains why each record is included or excluded. Have a team member review the proposed wording too. A reminder should say what the customer needs to know, not reveal internal notes. For a dental practice, appointment administration should stay separate from clinical advice. Make the second week easier than the first. Assign someone to review exceptions and adjust the Task. Keep the history so they can distinguish a scheduling problem from an unavailable connection or a request awaiting approval. Pausing future starts should be straightforward when business hours or policies change. Finn Tasks give recurring work a home alongside conversations and results. Once one job is dependable, expand a single dimension: another location, another permitted action, or another customer group. You will know what changed, and your team will know what to watch. Further reading Wonderful: How to Identify the Right AI Use Cases: https://www.wonderful.ai/blog-articles/how-to-identify-the-right-ai-use-casesGetting started https://joinfinn.com/blog/measure-the-finished-jobhttps://joinfinn.com/blog/measure-the-finished-jobA billing reminder went out. The customer opened it. The account is still overdue. All three facts can be true. When you measure AI at work, the last fact matters as much as the first two. Separate activity from the business result. For an illustrative utility billing journey, track reminders delivered, customers who requested help, payment arrangements recorded, and payments posted. These events answer different questions. A click is useful engagement information; it is not money collected. Choose the source of truth for each measure. The messaging provider can confirm delivery. The billing system confirms a posted payment. When those sources disagree or a result is still pending, keep that uncertainty visible. Keep the denominator honest. If you report a completion rate, define which requests count. Show eligible requests, attempted requests, and completed requests separately. Otherwise, excluding difficult cases can make a weak process look healthy. Record how many jobs needed employee help and why. An appropriate handoff is often the right outcome, especially when someone disputes a charge or needs an exception. Measure whether the handoff reached an owner with enough information to act. Look for work that came back. A closed conversation can reopen because the underlying request was never resolved. Review repeat contacts and corrected records alongside initial completion. Use a review window that suits the job: a booking change and a monthly billing cycle have different timelines. For a DTC order, check whether the requested change appeared in the order system. For a hotel, check whether the guest’s request reached the responsible team and was fulfilled. For a property repair, distinguish scheduled, attended, and resolved. Put time saved next to time spent. Compare the employee effort before and after introducing the workflow. Include reviewing drafts, answering exceptions, and maintaining the setup. Use a comparable sample of work, rather than multiplying a best-case demonstration by every request the company receives. Then decide what that extra capacity is for: faster follow-ups, more account coverage, or fewer backlogs. Finn’s operating history and business records can support that review, but the outcome belongs to your business. Set the baseline, agree on the measure, and review it with the people doing the work. Further reading Moveworks: Agentic AI and ticket resolution: https://www.moveworks.com/us/en/resources/blog/agentic-ai-it-ticket-resolution-closureBusiness outcomes https://joinfinn.com/blog/put-company-knowledge-to-workhttps://joinfinn.com/blog/put-company-knowledge-to-work“Prepare a quote using our wholesale prices.” To help, AI needs more than a folder of files. It needs the right price list, the right customer, and a clear boundary between preparing a proposal and sending it. Give each source a job. An approved policy explains what the business allows. A customer record identifies who you are serving. An order system shows what has already happened. A previous conversation provides context. Treating all four as interchangeable text makes it harder to spot an outdated answer. In an illustrative wholesale workflow, a sales presentation might contain an old discount example. The current approved pricing policy should control the quote. When two sources conflict, show the conflict to the person who owns the decision instead of silently choosing the more convenient answer. Make the draft easy to inspect. A useful quote draft identifies quantities, prices, assumptions, and any exception needing approval. A property report should identify its reporting period and the records behind it. A small calculator should make its inputs visible rather than conceal assumptions in a polished total. Finn’s Library brings uploaded and agent-created artifacts together. The point is to help a team find the work again, review it, and continue the conversation. Naming a file well and connecting it to the request can matter more than adding another dashboard chart. Keep access attached to the person. A shared knowledge base does not mean every employee should see every document. A location manager may need operating procedures without access to another property’s customer records. Test with the roles that will actually use the workflow, including someone who should be denied access. Keep the same care when selecting AI processing. Finn AI Gateway applies model access, data, and spending rules to requests routed through it. Those controls do not automatically cover unrelated AI tools used elsewhere in the company. Let the conversation continue. The first draft is rarely the end. “Use the new quantity.” “Explain the difference.” “Send it after I approve.” Each follow-up should make clear which artifact or proposal is being changed. Before an external action, check the current record and the relevant approval again. Start by connecting one maintained knowledge source to one useful output. Put an owner in charge of keeping that source current. When the team can find the answer, inspect the draft, and take the next permitted action without reconstructing the request, the knowledge base has become part of everyday work. Further reading Moveworks: Employee support and AI resources: https://www.moveworks.com/us/en/resources/blogKnowledge and AI