List the work in client language
A service catalog should describe the work a client recognizes rather than the internal labels a provider uses. Write entries such as inbox triage, invoice follow-up, calendar coordination, and weekly reporting. For each entry, name the output the client receives. A catalog built from internal job titles leaves the client guessing what is included.
Group the entries by the outcome they support, such as customer response, financial administration, or executive support. Keep the number of groups small enough to scan. Add one example output for each entry, with client data removed. The example does more than a paragraph to set the expected standard.
Keep the catalog separate from the sales brochure, even when they share language. The brochure explains why the client should buy, while the catalog explains what will happen after they do. A catalog that reads like marketing leaves the operational questions unanswered. Write it for the person who has to approve an invoice or assign a task.
Define what each service includes
For each entry, list the tasks included, the tools used, and the volume assumption behind the price. State whether the service covers drafting, sending, filing, and follow-up, because those steps are often the source of disagreement. A client who expects the assistant to send a message may be surprised to learn that the service ends at a draft. Name the handoff point in plain words.
Include the review step in the description and name who performs it. If the client reviews every outbound message, say so and describe the turnaround. If the assistant reviews against a written standard, describe the sample and the escalation rule. The review model changes both the risk and the effort, so it belongs in the catalog.
State the turnaround and the review path
Give each service a response window and a delivery window, and define when the clock starts. A request received at the end of the client's day should not be measured as if it arrived in the morning. State the business hours, the holiday calendar, and the channel that starts the clock. Precision here prevents most late-delivery disputes.
Describe what happens when the work needs a client decision. Name the person who approves, the information they must provide, and the effect on the timeline. A service that pauses for approval should show that pause in the catalog. Clients accept a documented pause far more readily than an unexplained delay.
Publish the exclusions and the change process
Write a short exclusion list for each service, such as work that requires a licensed professional, decisions above a stated threshold, or tasks outside the approved tool. Exclusions are not a rejection of the client. They define where a different process or a different owner is required. A clear exclusion protects both the assistant and the client.
Describe how a client can add a service or change the volume. Name the request channel, the notice period, and the person who approves the change. State how the price and the schedule adjust. A change process turns an ad hoc request into a planned decision instead of an argument about the last invoice.
Show what the client is not paying for as clearly as what they are. A client who sees that after-hours coverage or travel booking sits outside the standard service can decide whether to add it. That choice is better than discovering the gap during a live request. Transparency here builds trust rather than losing the sale.
Set the request channel and intake fields
Name one channel where requests enter the service and list the fields a complete request must contain. The fields usually include the output, the due time, the source material, and the approver. A request that arrives in a chat thread with none of those details will consume time before work can start. The catalog should make the complete request the easy path.
Explain what the assistant will do with an incomplete request. The usual pattern is to acknowledge it, ask for the missing field, and hold the clock until the request is complete. Write that rule in the catalog so the client expects it. The intake standard becomes part of the service rather than an internal preference.
Price the catalog against real effort
Test each price against the actual time the work takes, including review, rework, and waiting for approvals. A low price built on the fastest month will fail in a normal month. Use the team's own time records rather than a market guess. The catalog should be profitable at the volume it promises.
Show the assumptions behind the price, such as the number of requests per week or the number of accounts covered. When an assumption changes, the price can be revisited without renegotiating the whole relationship. A catalog with visible assumptions is easier to defend than a single blended rate. List the assumptions beside each entry rather than in a separate appendix.
Review the catalog with the client each quarter
Review the catalog with the client every quarter and compare the promised service with the requests that actually arrived. Add the work that has become routine and remove the entries no one uses. Ask the client which description was unclear. The review keeps the catalog aligned with the relationship rather than the sales deck.
Update the version and the effective date whenever an entry changes. Tell the assistant which line changed and give one example of the new expectation. Keep the old version for the current billing period. A catalog that changes quietly creates the same disputes it was meant to prevent.
Sources
Open the original publisher and confirm the current version, definition, and scope before using a source for a business decision.
Turn the reading into a role brief
Bring the recurring tasks, tools, schedule, access limits, and owner-only decisions. Start with one work sample and one clear review path.
Plan a Philippines-based role
