Decide Which Client Reports Should Stop Being Custom

Custom reporting becomes permanent faster than you think

A client asks for one extra column before a business review. Another wants a different chart. Someone on your team adds supplier detail because it might be useful. The report gets sent, nobody objects, and the new version quietly becomes the expectation.

Six months later, the firm has a different reporting process for every account. One advisor exports contract data. Another rebuilds spend charts. The founder rewrites the summary because only the founder understands what the client cares about. Delivery dates move when the report takes longer than expected.

The answer is not to force every client into the same PDF. Different clients have different contracts, stakeholders, decisions, and reporting requirements. The answer is to decide which differences matter and price the work that goes beyond the standard.

Put every recurring client report into one of four treatments: standardize it, configure it, price it as custom work, or retire it.

Start with the decision, not the document

Do not begin this review by comparing logos, layouts, and page counts. Ask what decision the report is supposed to support.

For each recurring report, record:

• The client audience and the person who owns the resulting decision
• The question the report answers
• The data required and its source
• The reporting period and delivery date
• The advisor responsible for review and delivery
• The action that should follow when the report shows an exception
• The contract, package, or approved request that requires the work

If you cannot name the decision, the report may be a habit rather than a service. A monthly spreadsheet nobody discusses should not survive because it has always gone out on the first Friday.

This is also why a dashboard does not automatically replace a report. A dashboard gives the client current visibility. A report may still need to explain an exception, preserve a point-in-time record, or prepare an executive for a decision. Use each for the job it does.

Standardize the operating facts

A standard report should protect the facts every client needs, not make every account look identical.

For a technology advisory firm, the common structure may include contract changes, upcoming renewals, active projects, unresolved decisions, supplier issues, spend movement, savings evidence, and next actions. The exact list depends on your service model. What matters is that the team agrees on the fields, source, owner, and review rule.

Keep the structure stable enough that another advisor can prepare the update without reverse-engineering the last version. A useful standard defines:

• Required sections and the purpose of each one
• Approved data sources
• Cutoff date and freshness rule
• Exception thresholds that need commentary
• Reviewer and client delivery owner
• Where decisions and follow-up actions are recorded

Asana's current status update template guidance makes a useful distinction: a template preserves structure and placeholders rather than copying live data from an old report. That is the right operating idea. Reuse the frame. Pull the current account facts. Do not duplicate last month's report and hope somebody notices what changed.

Configure what changes by client

Some differences belong in the standard service. A client may have a different executive audience, reporting cadence, technology categories, fiscal period, or threshold for material spend. Those are controlled configuration choices when the data and workflow remain the same.

Define the choices your team supports. For example, a client could receive monthly or quarterly delivery, choose from an approved set of spend views, and name the stakeholders who receive the report. The advisor should not redesign the process each time.

Configuration should be visible in the client record. Record the package, cadence, audience, included sections, delivery route, review owner, and next scheduled date. If the instruction lives only in the previous report or one person's inbox, it is not a controlled option.

Connect the reporting choice to your client service model. A high-touch account may receive more interpretation or a different review cadence. That does not mean every request is automatically included.

Price custom analysis when the work is actually different

A request becomes custom when it changes more than presentation. New data collection, manual reconciliation, a one-off model, new supplier research, a special compliance format, or analysis for an audience outside the agreed service can create real delivery work.

Before accepting it, show the tradeoff:

• What question the client wants answered
• Why the standard report does not answer it
• What new data, analysis, review, or meeting is required
• Who will do the work and when it can be delivered
• Whether the request is a one-time project or a recurring addition
• The fee, changed scope, or approved exception

If it is recurring, price the recurring work. If it is temporary, set an end date. Do not let a one-time favor become a permanent service because nobody recorded the boundary.

Use your scope change process when the request changes active delivery. Compare the work with your service pricing model before deciding that supplier compensation will somehow cover it.

Retire reports that do not earn the work

Retiring a report is not the same as giving the client less visibility. Sometimes it means replacing a stale file with current portal access. Sometimes it means moving one useful section into the business review and dropping six pages nobody reads.

Ask the client who uses the report, what decision it supports, which section they rely on, and what happens after they receive it. Do not ask, "Do you still want this?" Most people will say yes to a free option. Ask them to identify the use.

A report is a retirement candidate when it duplicates information already available, no longer matches the contract or service, repeatedly receives no discussion or action, relies on data nobody trusts, or exists for a stakeholder who has left.

Close it deliberately. Record the reason, client confirmation, final delivery date, replacement view if one exists, and any tasks removed from the recurring schedule.

Audit the last reporting cycle

Pull every report your firm delivered during the last month or quarter. Do not start by designing a perfect template. Start with the work you already performed.

For each report, compare the promised service with the actual preparation. Mark the standard sections, configured differences, custom analysis, manual data repair, review time, client use, and resulting decisions. Then assign one of the four treatments.

You will probably find reports that need two treatments. The core update can become standard while a special analysis becomes paid scope. A portal can carry live contract and project visibility while the advisor writes a shorter decision brief for the client review.

Advisor OS CRM connects clients, contacts, contracts, projects, tasks, QBRs, proposals, suppliers, commissions, and reporting. The Advisor OS client portal gives clients current visibility into contracts, spend, projects, roadmaps, decisions, and documents. Use the system to keep the facts connected, then decide where advisor judgment is worth the work.