Build an AI Assistant Service Catalog Clients Can Choose

TL;DR

• Organize your AI assistant service catalog by client outcomes, such as answering questions and handing unresolved requests to a person.
• Describe every service with eight fields: outcome, qualifying client job, prerequisites, visible deliverables, exclusions, operating burden, owner, and next step.
• Test every candidate for repeatability, prerequisite readiness, manageable burden, boundary clarity, and meaningful distinction.
• Assign one decision to each candidate: launch, combine, keep custom, or remove.

An agency can show a client website chat, voice, phone answering, lead capture, booking, routing, tools, and automations, yet still leave one practical question unanswered: “Which service can I choose?” That confusion prolongs sales conversations and makes every request look like a custom project. A short menu of bounded outcomes gives clients comparable choices while helping the agency screen out unclear or burdensome work.

Key Takeaways

• A catalog entry is a bounded client choice, not a loose description of what the agency could build.
• Every entry should state the completed job, required materials, visible result, limits, burden, owner, and buying path.
• Channels and tools belong inside entries as delivery mechanisms rather than catalog categories.
• Broad appeal does not make a service repeatable. Variable access, rules, and exceptions can make popular work unsuitable for a standard menu.
• Custom work remains valid when its differences define the engagement.

Turn Capabilities Into Choices Before Scope Is Written

A feature list makes the client translate technology into business value. “AI chat, phone, integrations, and booking” may sound capable, but it does not identify the result, fit conditions, prerequisites, or stopping point.

A useful catalog performs that translation before project scope is written. Each entry represents one recognizable client job, such as:

• Answer common questions and pass unresolved requests to a person.
• Capture an interested visitor’s details and help that visitor book a meeting.
• Help a customer find approved information and route the remaining request.

Clients can compare these units because every option answers the same practical questions: What job will this complete? When does it fit? What must already exist? What will the client receive? Where does the service stop?

The catalog has a narrow role. It is not a pricing table, retainer package, proposal, statement of work, or complete operating model. It helps a client select a service before the agency creates those later commercial and delivery documents.

That boundary creates a useful tradeoff. A short menu improves choice clarity but cannot represent every possible variation. If every entry includes a long list of optional additions, the buyer must interpret the offer again. The menu has returned to being a capability list.

Use a standard entry when the agency can state a stable outcome and repeat the central delivery pattern. Keep a service custom when unusual systems, data rules, approval needs, or client processes determine most of the effort. Custom does not mean undesirable. It means the work needs diagnosis before it can become a selectable unit.

This framework assumes the agency already has plausible service candidates. Agencies still deciding what they might sell can first choose candidate services by client type. The catalog step begins after those candidates exist and focuses only on making them comparable.

Use Eight Fields to Make Every Entry Comparable

Give every candidate the same anatomy. A common format prevents one entry from reading like a slogan while another reads like a project plan.

The outcome must be narrow enough to judge. “Improve customer service” could mean almost anything. “Answer approved FAQs and send unresolved requests to the support team” describes an observable result.

The qualifying client job prevents a desirable outcome from becoming a universal recommendation. A booking service fits when visitors already seek appointments and a usable scheduling path exists. Wanting more leads alone does not establish that fit.

Prerequisites show whether the service has a realistic starting point. An answer-and-handoff entry might require approved website or help content, a handoff destination, and basic routing rules. A capture-and-book entry might require agreed lead fields, qualification prompts, and a booking destination.

Exclusions stop the entry from quietly absorbing unrelated work. For answer-and-handoff, exclusions might include unsupported answers, sensitive advice, and resolution of cases that require staff judgment. For capture-and-book, they might include open-ended sales consulting or administration of the client’s calendar.

Keep these descriptions concise. The catalog needs enough detail for comparison, not project-specific obligations, acceptance rules, or contract language. Those belong in a later proposal.

Visible deliverables describe what the buyer can observe. “Configured routing logic” describes agency activity. “Unresolved questions reach the designated team with conversation details” describes a usable result.

Operating burden belongs beside the outcome because services that sound similar can require very different effort. An answering service based on stable, approved pages may be relatively repeatable. One that depends on several changing systems and many exception paths may carry a heavier burden even if its client-facing promise sounds simple.

The owner field is a basic admission gate. If nobody within the agency can own the service unit, it should not enter the catalog. Name one person or role type here without expanding the entry into a responsibility matrix.

The next step should match the buyer’s readiness. A short fit review can confirm that the outcome and prerequisites apply. Pricing, detailed scope, and delivery terms can follow after selection.

Group Services by Outcome, Then Record the Mechanism

Clients should not have to choose among chat, voice, phone, tools, or automation as if those labels described separate business results. They describe how a result may be delivered.

Start with outcome families tied to recognizable client jobs:

• Answer and hand off: Answer approved questions, then route unresolved or sensitive requests.
• Capture and book: Collect relevant lead details, then offer or start a booking step.
• Find and route: Help someone locate approved information, then direct the remaining request to the right destination.
• Check and follow up: Retrieve permitted information or trigger an agreed next action.

Record the technology within the entry. An answer-and-handoff service might use website chat for one client and phone for another. A capture-and-book service might use a chat form, a voice conversation, a calendar action, or several of these mechanisms together.

Split channel variations into different entries only when the client is making a different decision or when prerequisites, exclusions, or operating burden change materially. A different interface alone does not create a different service outcome.

InsertChat shows why outcome grouping matters. Its task pages cover sales, booking, support, commerce, billing, onboarding, retention, and recruiting. Those categories demonstrate a range of client jobs, but they should not automatically become matching entries on an agency menu. The agency still needs to define bounded outcomes that its clients can recognize and its team can repeat.

InsertChat supports chat, voice, and phone delivery, as well as tools and workflow actions. Agencies evaluating its tools should record only the mechanisms needed for a chosen service unit. This keeps the client-facing menu centered on the completed job rather than exposing a platform inventory.

Outcome grouping has a limit. Answering an approved FAQ and retrieving live account information may both look like “answering questions,” but they can require different access, controls, exclusions, and operating effort. Keep them separate when those differences would change the buyer’s choice. Preserve minor channel variations inside one entry when the outcome and service conditions remain the same.

Apply Five Tests Before a Service Reaches the Menu

The ability to deliver a service once does not make it catalog-ready. Apply five qualitative admission tests to each completed worksheet.

These tests are decision aids rather than a measured scoring model. Mark each condition as clear, uncertain, or weak and record the reason. The reason is more useful than a calculated total.

Repeatability asks whether the same service logic survives a change of client. Branding, source material, and routing destinations can vary. The central job and delivery pattern should not need to be redesigned each time.

Prerequisite readiness concerns the service unit rather than a complete project-readiness assessment. Ask whether the usual suitable buyer can provide what the catalog entry requires. If extensive discovery is routinely needed just to identify the starting materials, the service is probably still custom.

Operating burden prevents broad appeal from hiding unpredictable work. A wide promise may attract many buyers, but every delivery could require different connected systems, exception rules, or review steps. For a first catalog, repeatable delivery should take priority over a promise designed to fit almost anyone.

Boundary clarity allows a client to understand the limit without reading legal language. “Answers from approved content and hands off unresolved questions” is bounded. “Complete AI customer support” leaves too much open to interpretation.

Meaningful distinction controls menu size. If buyers cannot explain the difference between an “FAQ assistant” and a “support routing assistant,” combine them when their prerequisites and burden also align. Technical differences alone do not justify separate choices.

Use four possible decisions after the tests:

• Launch when all five conditions are clear enough for a standard entry.
• Combine when two candidates lead to the same client decision and have compatible service conditions.
• Keep custom when the work is useful but exceptions or variation define delivery.
• Remove when the candidate lacks a distinct outcome, dependable starting point, or defensible boundary.

Splitting every variation creates choice overload. Combining too aggressively can hide differences that affect access, risk, or effort. Combine candidates when the outcome and purchase decision are the same. Keep them separate when choosing one changes the conditions in a way the buyer needs to see.

Complete Two Entries, Then Choose the First Catalog

The following entries are illustrative examples. They demonstrate the intended catalog depth and do not represent customer results or universal delivery requirements.

These entries omit prices, contract terms, project schedules, recurring reporting, and detailed client duties. They give buyers enough information to recognize the suitable choice and give the agency enough detail to compare delivery conditions.

Consider an illustrative agency reviewing six candidates: FAQ answers, support handoff, lead capture, meeting booking, phone answering, and custom app automation.

FAQ answers and support handoff serve one continuous client job. Buyers want routine questions answered and exceptions sent to staff. Their prerequisites and burden also align, so the agency combines them as FAQ-to-handoff.

Lead capture and meeting booking also form a continuous job for the clients this agency intends to serve. The same conversation gathers agreed details and offers the next step, so the agency combines them as lead-capture and booking. If booking required substantially different access or operating effort, it could remain separate.

Phone answering does not become its own service merely because it uses another channel. The agency records phone as a possible delivery mechanism within the relevant outcome entry and adjusts the stated prerequisites, exclusions, and burden where needed.

The custom app automation candidate changes with every client. Each request involves different data, connected systems, logic, and exceptions. The agency keeps it custom because variation defines the work. A broad automation entry would promise repeatability the agency does not yet have.

The agency removes a standalone AI chat setup candidate. Clients cannot distinguish its outcome from the two stronger entries, and its name describes a mechanism rather than a completed job.

The first catalog therefore launches with two service units: FAQ-to-handoff and lead-capture and booking. Two is not a general benchmark. It is simply the smallest set this agency can currently distinguish and repeat.

Complete the eight fields for every candidate, apply the five tests, and assign one decision to each: launch, combine, keep custom, or remove. Publish only the smallest set that clients can tell apart and the agency can deliver repeatedly. Once a client selects an entry, turn a selected service into a client proposal. The chosen units can later feed a wider productized operating model, but the catalog’s job ends with a clear first menu.

FAQ

How many entries should the first catalog contain?

There is no universal count. Stop adding entries when the remaining candidates lack repeatability, boundary clarity, or meaningful distinction. A smaller menu with visibly different outcomes is easier to compare than a larger one built from technical variations.

Are AI assistant service tiers the same as a service catalog?

No. A catalog identifies standalone service units clients can select. Tiers usually combine services or vary quantities and access. Establish clear entries before making later packaging decisions.

When should a service remain custom?

Keep it custom when discovery, system connections, data access, exceptions, or review requirements determine most of the work. Consider a standard entry only after repeated delivery reveals a stable outcome, common prerequisites, clear exclusions, manageable burden, and an owner.

Can one entry use chat, voice, and phone?

Yes, when those channels support the same client outcome. Record them as delivery mechanisms and reflect material differences in prerequisites, exclusions, and burden. Create separate entries only when the client is choosing a different result or meaningfully different service conditions.