{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "The Finn blog",
  "home_page_url": "https://joinfinn.com/blog",
  "feed_url": "https://joinfinn.com/blog/feed.json",
  "description": "Perspectives, guides, and business use cases from Finn.",
  "language": "en-US",
  "authors": [
    {
      "name": "Finn",
      "url": "https://joinfinn.com/about-us"
    }
  ],
  "items": [
    {
      "id": "https://joinfinn.com/blog/what-is-agentic-automation",
      "url": "https://joinfinn.com/blog/what-is-agentic-automation",
      "title": "What is agentic automation? A plain-English guide.",
      "summary": "Understand the difference between an answer, a fixed automation, and an agent that can take permitted actions.",
      "content_text": "A 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.\n\nAn agent works toward a result.\n\nAn 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.\n\nThe 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.\n\nA fixed automation is often enough.\n\nIf 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.\n\nAgents 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.\n\nSeparate intention from completion.\n\nFor 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.\n\nThis 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.\n\nTry one bounded request.\n\nChoose 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.\n\nFinn 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.\n\nFurther reading\nMoveworks: Agentic Automation Explained: https://www.moveworks.com/us/en/resources/blog/what-does-agentic-automation-mean",
      "tags": [
        "Explainer"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/ai-agent-chatbot-or-task",
      "url": "https://joinfinn.com/blog/ai-agent-chatbot-or-task",
      "title": "AI agent, chatbot, or Task: what does your business need?",
      "summary": "Choose the right kind of automation for a question, a one-time request, or a recurring job.",
      "content_text": "“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.\n\nUse an answer when information is the result.\n\nA 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.\n\nCheck 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.\n\nUse an agent when the request requires action.\n\nA 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.\n\nStart 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.\n\nUse a Task when the job should recur.\n\nIn 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.\n\nSpecify 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.\n\nCombine them without confusing them.\n\nA 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.\n\nMeasure 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.\n\nFurther reading\nMoveworks: Agentic Automation Explained: https://www.moveworks.com/us/en/resources/blog/what-does-agentic-automation-mean",
      "tags": [
        "Explainer"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/build-a-useful-company-knowledge-base",
      "url": "https://joinfinn.com/blog/build-a-useful-company-knowledge-base",
      "title": "How to build a company knowledge base your AI can use.",
      "summary": "Turn websites, documents, SOPs, and policies into maintained guidance for everyday work.",
      "content_text": "Start 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.\n\n1. Choose the source that owns the answer.\n\nList 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.\n\nSeparate 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.\n\n2. Clean up conflicting instructions.\n\nLook 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.\n\nFor 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.\n\n3. Test retrieval with real questions.\n\nTry 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.\n\nTest 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.\n\n4. Establish a maintenance habit.\n\nAssign 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.\n\nUse 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.\n\nFurther reading\nMoveworks: Knowledge Discovery: https://www.moveworks.com/us/en/resources/blog/what-is-knowledge-discovery",
      "tags": [
        "How-to"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/set-ai-permissions-and-approvals",
      "url": "https://joinfinn.com/blog/set-ai-permissions-and-approvals",
      "title": "How to set AI permissions and approvals without slowing everything down.",
      "summary": "Define what an agent may read, prepare, change, and send—and which decisions stay with people.",
      "content_text": "A 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.\n\n1. List the exact effects.\n\nFor 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.\n\nAvoid 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.\n\n2. Define the exception that requires review.\n\nSpecify 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.\n\nIf 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.\n\n3. Keep access and model controls separate.\n\nAn 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.\n\nFinn 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.\n\n4. Test both permitted and denied cases.\n\nUse 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.\n\nMake 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.\n\nFurther reading\nMoveworks: AI Governance Frameworks: https://www.moveworks.com/us/en/resources/blog/enterprise-ai-governance-frameworks-types",
      "tags": [
        "How-to"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/employee-onboarding-with-ai",
      "url": "https://joinfinn.com/blog/employee-onboarding-with-ai",
      "title": "How to coordinate employee onboarding with AI.",
      "summary": "Connect the people, information, and approved actions behind a new employee’s first day.",
      "content_text": "A 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.\n\n1. Begin with a confirmed employee record.\n\nUse 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.\n\nKeep 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.\n\n2. Map the first-day requirements.\n\nFor 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.\n\nAI 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.\n\n3. Show what is actually ready.\n\nTrack 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.\n\nIf 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.\n\n4. Welcome the employee into a usable experience.\n\nGive 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.\n\nIn 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.\n\nFurther reading\nMoveworks: Employee Onboarding Automation: https://www.moveworks.com/us/en/resources/blog/enterprise-hr-onboarding-automation-guide",
      "tags": [
        "How-to"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/ai-it-support-with-a-clear-handoff",
      "url": "https://joinfinn.com/blog/ai-it-support-with-a-clear-handoff",
      "title": "How to introduce AI into IT support.",
      "summary": "Start with a small set of support requests and make the path to a person clear.",
      "content_text": "An 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.\n\n1. Select a narrow service.\n\nStart 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.\n\nA 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.\n\n2. Ask for useful details once.\n\nCollect the application, the observed error, and when the problem began. Avoid asking employees to paste passwords, recovery codes, or other secrets into a conversation.\n\nUse 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.\n\n3. Escalate with context.\n\nIf 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.\n\nAn 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.\n\n4. Review the outcome.\n\nTrack 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.\n\nFinn 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.\n\nFurther reading\nMoveworks: AI IT Support: https://www.moveworks.com/us/en/resources/blog/enterprise-guide-to-tier-1-help-desk-automation",
      "tags": [
        "How-to"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/test-an-ai-workflow-before-publishing",
      "url": "https://joinfinn.com/blog/test-an-ai-workflow-before-publishing",
      "title": "How to test an AI workflow before publishing it.",
      "summary": "Build a small test set that checks business results, permissions, and recovery—not just the wording of a reply.",
      "content_text": "A 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.\n\n1. Define the expected outcome for each case.\n\nFor 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.\n\nUse 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.\n\n2. Include the boundaries.\n\nTest 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.\n\nCheck 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.\n\n3. Simulate an incomplete action.\n\nConsider 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.\n\nWhen 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.\n\n4. Make the release decision explicit.\n\nRecord 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.\n\nRepeat 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.\n\nFurther reading\nMoveworks: End-to-End Service Orchestration: https://www.moveworks.com/us/en/resources/blog/end-to-end-service-orchestration-checklist",
      "tags": [
        "How-to"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/five-ai-use-cases-finance-operations",
      "url": "https://joinfinn.com/blog/five-ai-use-cases-finance-operations",
      "title": "Five AI use cases for everyday finance operations.",
      "summary": "Practical ways to reduce administrative work around invoices, accounts, and reporting while preserving financial authority.",
      "content_text": "Finance 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.\n\n1. Explain an invoice. 2. Prepare an overdue-account review.\n\nFor 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.\n\nFor 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.\n\n3. Assemble the facts behind a discrepancy.\n\nWhen 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.\n\nMissing information should remain missing. An agent should not infer a receipt, delivery confirmation, or approval merely because one would normally exist in the process.\n\n4. Draft a customer billing response.\n\nPrepare 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.\n\nReview the recipient, wording, and sending rules before delivery. Drafting a message and sending it are separate actions, especially when many accounts are involved.\n\n5. Prepare a recurring operating summary.\n\nA 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.\n\nIn 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.\n\nFurther reading\nMoveworks: AI Use Cases for Finance Teams: https://www.moveworks.com/us/en/resources/blog/ai-use-cases-in-finance",
      "tags": [
        "Use cases"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/ai-wholesale-quote-workflow",
      "url": "https://joinfinn.com/blog/ai-wholesale-quote-workflow",
      "title": "From inquiry to approved quote: an AI workflow for wholesale teams.",
      "summary": "Connect a customer request to current pricing, employee review, and a quote the business can stand behind.",
      "content_text": "A 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.\n\nCollect the details that change the price.\n\nAsk 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.\n\nRetrieve 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.\n\nPrepare a proposal people can inspect.\n\nShow 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.\n\nA draft should be clearly labeled. The operations team needs to distinguish what the buyer asked for from what the business is prepared to promise.\n\nApprove the exact offer.\n\nAsk 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.\n\nKeep 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.\n\nSave, send, and follow through.\n\nRecord 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.\n\nFinn’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.\n\nFurther reading\nMoveworks: Cross-Department Workflows: https://www.moveworks.com/us/en/resources/blog/enterprise-ai-agents-for-cross-department-workflows",
      "tags": [
        "Use cases"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/ai-appointment-follow-ups",
      "url": "https://joinfinn.com/blog/ai-appointment-follow-ups",
      "title": "An AI appointment follow-up journey that respects the customer.",
      "summary": "Connect reminders, replies, and booking updates without confusing a message sent with an appointment confirmed.",
      "content_text": "Tomorrow’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.\n\nSelect the right appointments.\n\nDefine 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.\n\nPreview 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.\n\nSend only what is needed.\n\nUse 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.\n\nFor a dental practice, keep this journey administrative. Questions requiring clinical judgment should reach an appropriate professional through the practice’s established process.\n\nTreat a reply as a new decision point.\n\nA 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.\n\nDo 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.\n\nReview the exceptions and the result.\n\nShow 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.\n\nUse 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.\n\nFurther reading\nMoveworks: Self-Service Automation: https://www.moveworks.com/us/en/resources/blog/self-service-automation-transforms-support-operations",
      "tags": [
        "Use cases"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/ai-property-maintenance-journey",
      "url": "https://joinfinn.com/blog/ai-property-maintenance-journey",
      "title": "From tenant message to resolved repair: an AI use case.",
      "summary": "Make the request, approvals, contractor coordination, and final outcome visible in one business journey.",
      "content_text": "A 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.\n\nEstablish the request and the property.\n\nConfirm 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.\n\nAvoid promising a repair time before availability is confirmed. Tell the tenant what has been recorded and which step comes next.\n\nPrepare the work for a decision.\n\nGather 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.\n\nAn 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.\n\nCoordinate access and scheduling.\n\nCollect 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.\n\nIf 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.\n\nClose against the actual outcome.\n\nDistinguish 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.\n\nFinn 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.\n\nFurther reading\nMoveworks: End-to-End Service Orchestration: https://www.moveworks.com/us/en/resources/blog/end-to-end-service-orchestration-checklist",
      "tags": [
        "Use cases"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/five-ways-teams-can-work-with-ai",
      "url": "https://joinfinn.com/blog/five-ways-teams-can-work-with-ai",
      "title": "Five useful ways employees can work with AI today.",
      "summary": "A practical starting point for research, drafts, analysis, and recurring reviews inside the business.",
      "content_text": "Employees 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.\n\n1. Prepare for an account conversation.\n\nAsk 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.\n\nThe 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.\n\n2. Compare documents. 3. Draft a response.\n\nCompare 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.\n\nFor 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.\n\n4. Create a small decision tool.\n\nA 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.\n\nTreat 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.\n\n5. Turn a useful review into a recurring Task.\n\nOnce 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.\n\nFinn 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.\n\nFurther reading\nMoveworks: Employee Productivity Use Cases: https://www.moveworks.com/us/en/resources/blog/agentic-ai-employee-productivity-impact-use-cases",
      "tags": [
        "Use cases"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/the-interface-should-fit-the-job",
      "url": "https://joinfinn.com/blog/the-interface-should-fit-the-job",
      "title": "The interface should fit the job.",
      "summary": "A conversation is a good way to ask. It is not always the best way to review, decide, or act.",
      "content_text": "Ask 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.\n\nStart with the decision, then choose the display.\n\nWe 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.\n\nConsider 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.\n\nAn artifact gives the work something to stand on.\n\nA 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.\n\nThis 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.\n\nKeep the action visible.\n\nAn 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.\n\nSome 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.\n\nLet the work move between forms.\n\nOur 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.\n\nThe 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.\n\nFurther reading\nSierra: Agents as a Service: https://sierra.ai/blog/agents-as-a-service",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/the-conversation-ended-the-job-didnt",
      "url": "https://joinfinn.com/blog/the-conversation-ended-the-job-didnt",
      "title": "The conversation ended. The job didn’t.",
      "summary": "Useful business AI needs to follow the work through waiting, change, and completion.",
      "content_text": "A 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.\n\nWaiting is part of the work.\n\nBusiness 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.\n\nThe 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.\n\nRemember the request. Check what changed.\n\nContinuity 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.\n\nIn 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.\n\nFollow up with a reason.\n\nA 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.\n\nFor 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.\n\nGive ongoing work a home.\n\nFinn’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.\n\nThe 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.\n\nFurther reading\nSierra: The next Horizon in agents: https://sierra.ai/blog/horizon",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/your-best-operating-knowledge-isnt-in-a-manual",
      "url": "https://joinfinn.com/blog/your-best-operating-knowledge-isnt-in-a-manual",
      "title": "Your best operating knowledge isn’t in a manual.",
      "summary": "The judgment your team uses every day deserves a better home than scattered conversations and someone’s memory.",
      "content_text": "Ask 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.\n\nExperience is valuable because it notices the exceptions.\n\nManuals 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.\n\nThat 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.\n\nTurn a story into a reviewable rule.\n\nStart 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.\n\nFor 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.\n\nGive knowledge an owner.\n\nA 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.\n\nFinn’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.\n\nLet the people closest to the work improve it.\n\nOperators 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.\n\nWe 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.\n\nFurther reading\nDecagon: The customer relationship was always yours: https://decagon.ai/blog/our-bet-on-you",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/who-owns-your-ai-on-monday-morning",
      "url": "https://joinfinn.com/blog/who-owns-your-ai-on-monday-morning",
      "title": "Who owns your AI on Monday morning?",
      "summary": "Launching an agent is a milestone. Running it well is an operating responsibility.",
      "content_text": "The 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.\n\nOwnership needs a name.\n\nAn 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.\n\nFor 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.\n\nSort exceptions by consequence.\n\nA 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.\n\nA 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.\n\nChange deserves its own review.\n\nA 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.\n\nBefore 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.\n\nBuying software does not outsource business judgment.\n\nA 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.\n\nThis 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.\n\nFurther reading\nDecagon: AI agents are never done: https://decagon.ai/blog/the-new-build-vs-buy-calculus",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/your-company-doesnt-need-ai-that-knows-everything",
      "url": "https://joinfinn.com/blog/your-company-doesnt-need-ai-that-knows-everything",
      "title": "Your company doesn’t need AI that knows everything.",
      "summary": "Useful business intelligence depends on knowing which information matters, which source to trust, and when to ask.",
      "content_text": "A 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.\n\nMore information can create more ambiguity.\n\nBusinesses 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.\n\nA 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.\n\nSeparate history from current truth.\n\nA 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.\n\nConsider 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.\n\nThe right answer depends on the person asking.\n\nTwo 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.\n\nAccess 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.\n\nMake uncertainty actionable.\n\nWhen 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.\n\nFinn’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.\n\nFurther reading\nGlean: From enterprise search to enterprise context: https://www.glean.com/blog/from-enterprise-search-to-enterprise-context-what-ai-agents-actually-need",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/a-faster-employee-doesnt-always-make-a-faster-company",
      "url": "https://joinfinn.com/blog/a-faster-employee-doesnt-always-make-a-faster-company",
      "title": "A faster employee doesn’t always make a faster company.",
      "summary": "Individual productivity gains matter. The next opportunity is the time work spends between people.",
      "content_text": "A 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.\n\nLook at the spaces between tasks.\n\nWork 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.\n\nFor 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.\n\nA shared conversation needs shared purpose.\n\nPutting 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.\n\nImagine 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.\n\nReduce the effort required to decide.\n\nAn 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.\n\nLikewise, 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.\n\nMeasure the journey as well as the person.\n\nTrack 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.\n\nOur 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.\n\nFurther reading\nGlean: Proactive AI for single and multiplayer work: https://www.glean.com/blog/proactive-ai-for-enterprises",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/dont-make-your-customer-start-over",
      "url": "https://joinfinn.com/blog/dont-make-your-customer-start-over",
      "title": "Don’t make your customer start over.",
      "summary": "A handoff should move the problem toward resolution, carrying the useful context with it.",
      "content_text": "A 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.\n\nContinuity is a service decision.\n\nAn 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.\n\nA 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.\n\nGive the receiving employee a next step.\n\nA 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.\n\nFor 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.\n\nDo not confuse continuity with skipping checks.\n\nSometimes 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.\n\nThe 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.\n\nMake help easy to reach.\n\nA 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.\n\nFinn’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.\n\nFurther reading\nParloa: Customer automation’s trust problem: https://www.parloa.com/blog/cx-automation-has-a-trust-problem/",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/your-next-workspace-starts-with-a-conversation",
      "url": "https://joinfinn.com/blog/your-next-workspace-starts-with-a-conversation",
      "title": "Your next workspace starts with a conversation.",
      "summary": "Business software taught us where to click. The next workspace should understand what we are trying to do.",
      "content_text": "A 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.\n\nThe request should be the starting point.\n\nOur 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.\n\nThat 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.\n\nA conversation can open more than a chat.\n\nImagine 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.\n\nA 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.\n\nPeople need a place in the conversation.\n\nAn 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.\n\nThat 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.\n\nThe best workspace makes responsibility clearer.\n\nPutting 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.\n\nThis 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.\n\nFurther reading\nMoveworks: The AI Assistant on Web: https://www.moveworks.com/us/en/resources/blog/ai-assistant-on-web",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/what-would-your-business-do-with-more-capacity",
      "url": "https://joinfinn.com/blog/what-would-your-business-do-with-more-capacity",
      "title": "What would your business do with more capacity?",
      "summary": "The most interesting AI business case may be the useful work your company cannot afford to do today.",
      "content_text": "Every 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.\n\nLook at the work you have stopped considering.\n\nCost 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.\n\nConsider 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.\n\nExtra activity has to earn its place.\n\nMore 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.\n\nFor 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.\n\nFind the next constraint before you remove the first.\n\nSuppose 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.\n\nThe 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.\n\nMake a deliberate choice about the time returned.\n\nWhen 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.\n\nStart 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.\n\nFurther reading\nWonderful: Unlocking Capacity: The Real ROI of AI: https://www.wonderful.ai/blog-articles/unlocking-capacity-the-real-roi-of-ai",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/every-team-ai-one-set-of-controls",
      "url": "https://joinfinn.com/blog/every-team-ai-one-set-of-controls",
      "title": "Let every team use AI. Give the company one set of controls.",
      "summary": "Teams need room to improve their work. IT needs a supported way to manage access, data, and spending across connected AI applications.",
      "content_text": "The 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.\n\nMake the approved path useful.\n\nIf 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.\n\nFor 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.\n\nSeparate business decisions from shared infrastructure.\n\nA 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.\n\nA 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.\n\nModel access is not permission to act.\n\nAllowing 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.\n\nKeeping 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.\n\nGive people an understandable boundary.\n\nWhen 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.\n\nOur 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.\n\nFurther reading\nMoveworks: The AI Strategy Paradox: https://www.moveworks.com/us/en/resources/blog/ai-strategy-paradox",
      "tags": [
        "Perspective"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/the-work-starts-after-the-answer",
      "url": "https://joinfinn.com/blog/the-work-starts-after-the-answer",
      "title": "The work starts after the answer.",
      "summary": "A helpful reply is a beginning. Here’s how to design the work that comes next, across customers, teams, and company software.",
      "content_text": "“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.\n\nWrite down what “done” means.\n\nFor 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.\n\nDefine 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.\n\nKeep the customer and the team in the same story.\n\nThe 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.\n\nApproval 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.\n\nCheck the result before announcing it.\n\nSuppose 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.\n\nThe 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.\n\nStart with the handoff you repeat every day.\n\nChoose 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.\n\nA 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.\n\nFurther reading\nWonderful: AI Doesn’t Care About Your Org Chart: https://www.wonderful.ai/blog-articles/ai-doesnt-care-about-your-org-chart",
      "tags": [
        "Customer operations"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/choose-your-first-ai-task",
      "url": "https://joinfinn.com/blog/choose-your-first-ai-task",
      "title": "Pick one job. Make it work.",
      "summary": "How to choose a first AI Task that has a clear purpose, manageable scope, and a result your team can trust.",
      "content_text": "Start 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.\n\nChoose a repeatable inconvenience.\n\nLook 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.\n\nChoose 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.\n\nGive the job a small, precise boundary.\n\nFor 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.\n\nSending 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.\n\nPreview the people affected.\n\nBefore 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.\n\nHave 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.\n\nMake the second week easier than the first.\n\nAssign 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.\n\nFinn 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.\n\nFurther reading\nWonderful: How to Identify the Right AI Use Cases: https://www.wonderful.ai/blog-articles/how-to-identify-the-right-ai-use-cases",
      "tags": [
        "Getting started"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/measure-the-finished-job",
      "url": "https://joinfinn.com/blog/measure-the-finished-job",
      "title": "Measure the finished job.",
      "summary": "Replies, clicks, and activity tell part of the story. Measure what changed for the customer and the team.",
      "content_text": "A 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.\n\nSeparate activity from the business result.\n\nFor 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.\n\nChoose 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.\n\nKeep the denominator honest.\n\nIf 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.\n\nRecord 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.\n\nLook for work that came back.\n\nA 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.\n\nFor 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.\n\nPut time saved next to time spent.\n\nCompare 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.\n\nThen 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.\n\nFurther reading\nMoveworks: Agentic AI and ticket resolution: https://www.moveworks.com/us/en/resources/blog/agentic-ai-it-ticket-resolution-closure",
      "tags": [
        "Business outcomes"
      ]
    },
    {
      "id": "https://joinfinn.com/blog/put-company-knowledge-to-work",
      "url": "https://joinfinn.com/blog/put-company-knowledge-to-work",
      "title": "Give good answers somewhere to go.",
      "summary": "Connect approved knowledge to current business records, useful drafts, and actions your team can review.",
      "content_text": "“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.\n\nGive each source a job.\n\nAn 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.\n\nIn 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.\n\nMake the draft easy to inspect.\n\nA 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.\n\nFinn’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.\n\nKeep access attached to the person.\n\nA 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.\n\nKeep 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.\n\nLet the conversation continue.\n\nThe 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.\n\nStart 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.\n\nFurther reading\nMoveworks: Employee support and AI resources: https://www.moveworks.com/us/en/resources/blog",
      "tags": [
        "Knowledge and AI"
      ]
    }
  ]
}