User Guide: How Comcast Technology Solutions' Finance Team Puts Zuora AI to Work

At Comcast Technology Solutions, Chris Skalet didn’t set out to reinvent finance. He just wanted to stop clicking through invoices one at a time. A few small, deliberate experiments with Zuora AI later, his team is spending its time on analysis instead of admin and Skalet has a new theory about what finance can be.

Skalet’s approach is a useful model for finance professionals who want to apply AI without giving up control: start with a known task, give the tool specific instructions, validate the result against trusted numbers, and keep production decisions with the people who own the business process.

Chris treats Zuora AI less like an autonomous replacement for finance and more like a capable colleague. The tool can help investigate, explain, query, and execute approved work, but the finance professional supplies the context and remains accountable for the outcome.

A practical workflow looks like this:

• Ask: Describe the business outcome and the boundaries of the task.
• Inspect: Review the data, logic, query, or records the AI identifies.
• Validate: Compare the result with known examples, trusted totals, or expected behavior.
• Decide: Determine whether the result is ready to use, needs refinement, or should not move forward.

The example prompts below are adapted from Chris’s workflows. A useful prompt pattern is: business context + specific task + scope and time period + expected output + constraints or approval step.

The challenge

Distributed teams can introduce small setup inconsistencies that are difficult to catch manually. For Comcast Technology Solutions’ Finance team, it was a communication profile that didn’t match its account type. Chris needed a way to find those exceptions without turning a routine audit into a broad, risky change to live data. This was also his first real test of the tool: a bounded, low-stakes question where he could review every result record by record before trusting Zuora AI with anything bigger.

How Chris solved it with Zuora AI

Chris started with a read-only comparison against a small, well-understood account set, asking Zuora AI to flag records that didn’t match the expected profile-to-account-type relationship, explain why, and leave the underlying data untouched. The tool surfaced several accounts with an incorrect profile attached, and his team corrected them by hand. It was a small win, but it told him the tool could actually see what he needed it to see, before he handed over anything higher-stakes.

Example prompt

Review the communication profiles associated with [account set or account type] for [time period]. Compare each profile with the account type and return only records that appear inconsistent. Output a table with account ID, account name, account type, current profile, expected profile, and reason for the exception. Do not change any records.

Validate before acting

• Confirm that the comparison uses the intended account-type rules.
• Review every exception before making a correction.
• Check that the user’s permissions prevent unintended changes.
• Preserve the audit trail or existing review process for the correction.

The challenge

Some CTS customers have draft invoices that need to be posted after the system generates them. In ad delivery, a single monthly cycle can involve dozens or hundreds of invoices, and Chris recalls posting roughly 60 of them for one customer at close, one click at a time. “It was kind of a mind drain,” he says. “I could be doing something better than that with my time.”

How Chris solved it with Zuora AI

Chris handed Zuora AI the invoice list and had it separate ready-to-post invoices from exceptions, then post only the invoices he explicitly approved. Nothing changed about who decided what should happen; the tool didn’t act on an inferred intention, only on his explicit instruction. What disappeared was the manual click-through itself, and the risk of losing track partway through it.

Example prompt

For [customer/account set] and [billing period], identify invoices that are still in draft status and appear ready for posting. Return a table with invoice ID, account name, invoice date, amount, status, and any blocking exception. Do not post or email anything until I explicitly approve the final list.

After reviewing the list, a follow-up instruction could be:

Post only the approved invoice IDs from the list above. Exclude any invoice with an exception or a status other than draft. Do not email customers. Return the posted count, invoice IDs, and any errors.

Validate before acting

• Confirm the invoice list and billing period.
• Exclude records with exceptions or unexpected statuses.
• Check that the action is permitted for the user and environment.
• Review the confirmation and reconcile the posted count against the approved list.

The challenge

Billing workflows can contain business rules that accumulate over time, and when an order type is handled incorrectly, finance needs to understand where that behavior comes from and what change would fix it, without pushing an untested change into production. Diagnosing this kind of issue used to mean stacking several layers of expertise and waiting on people who weren’t always available on demand. 

How Chris solved it with Zuora AI

Chris asked Zuora AI to trace the relevant logic, explain the current behavior, and propose the smallest change that would produce the expected result. He used the tool to rewrite and test the fix in a sandbox, then moved the validated version into production himself, through the team’s approved process. He still knew the business rule, still defined the expected result, and still made the final call on what shipped. “The speed to fix something in the time you have the idea makes all the difference,” Chris shares. 

Example prompt

For [order type] in [tenant/environment], the expected billing outcome is [describe the outcome]. Trace the workflow logic that determines the current behavior. Return: 1) the relevant rule or code, 2) an explanation of the current behavior, 3) the smallest proposed change, 4) assumptions, and 5) potential downstream impacts. Do not change production.

After the tool proposes a change:

Rewrite the relevant logic for the proposed change. Show the before-and-after behavior and provide positive, negative, and edge-case test cases for the sandbox. Identify any dependencies or approval steps. Do not deploy or modify production.

Validate before acting

• Define the expected business result before reviewing the technical change.
• Test both the intended scenario and nearby edge cases.
• Compare sandbox results with known examples.
• Review the change with the appropriate technical or support partner when needed.
• Move the change to production only through the approved process.

The challenge

Month-end analysis often requires pulling information from invoices, credit memos, payments, and tax reports separately and stitching the results together by hand,  time spent before analysis even begins.

How Chris solved it with Zuora AI

Chris asked Zuora AI to combine invoices, credit memos, payments, and tax information into a single query. He compared the output against numbers his team already trusted, flagged where they diverged, explained what the correct result should look like, and had the AI refine the query until it matched. It was back-and-forth validation, not blind acceptance, but once the output matched, his team had one reliable report instead of a manual reconciliation exercise. “My team’s analyzing stuff instead of downloading and checking summaries,” Chris shares. “Those manual tasks are gone.”

Example prompt

For [period], combine invoices, credit memos, payments, and tax information by [account/customer/product]. Return: 1) reconciliation totals, 2) the records and fields used, 3) unmatched or duplicate records, 4) variances, and 5) likely causes. Explain the joins and assumptions. Do not change any data.

For validation:

Compare this result with the trusted totals below. Identify every variance, explain the likely cause, and revise the query only where the variance is caused by query logic. Keep a clear record of the changes and return the final query in a reusable format.

Validate before acting

• Reconcile totals to trusted source reports.
• Check for duplicate records created by joins.
• Test a small, known sample before expanding the query.
• Review how credits, payments, tax, and timing differences are represented.
• Keep the final query and validation notes available for repeatable month-end use.

The challenge

When a business adds a product area or expands its customer base, billing complexity can become a real constraint on how fast that expansion can happen. CTS’s own ad-delivery business was onboarded with roughly 300 customers, built out one account at a time. It’s slow, manual work that made every new customer feel like an isolated task.

How Chris solved it with Zuora AI

Chris describes a newer operating model: start with a customer list and let Zuora AI surface missing data, flag inconsistent configurations, and separate exceptions from standard cases. Account creation and changes still go through the team’s existing permissions and review; the AI does the surfacing, not the deciding.

Example prompt

Using the approved customer list, account template, and [product or business-unit rules], identify missing fields, inconsistent configurations, and records that require manual review. Group exceptions by type and return customer ID, account name, missing or inconsistent field, recommended next action, and confidence or rationale. Do not create or modify accounts.

Validate before acting

• Confirm the source list and account template.
• Separate repeatable configuration from exceptions.
• Review a sample before scaling the process.
• Ensure only authorized users can create or modify records.
• Track unresolved exceptions through the team’s existing operating process.

Chris’s approach is cautious and practical. He wants to see results quickly, but he also expects the tool to operate within existing controls.

Use these guardrails when applying the same model:

• Start in a sandbox or with a small, well-understood sample.
• Use explicit instructions. State the scope, expected result, exclusions, and whether the tool may take action.
• Separate investigation from execution. Ask the tool to identify and explain before asking it to change or post anything.
• Validate against trusted data. Known totals and known examples are essential for checking output.
• Respect role-based permissions. A read-only user should remain read-only.
• Keep a human decision-maker in the loop. Especially when a change could affect billing outcomes.
• Document the final result. Retain the approved query, change, or reconciliation logic for repeatability.

Finance teams can begin without redesigning their whole operating model:

1. Choose one repetitive task with a clear definition of done.
2. Test it against a small sample the team already understands.
3. Ask the AI to explain its approach and surface exceptions.
4. Compare the output with trusted results and refine the instruction.
5. Expand only after the team can explain what happened and why.
6. Keep production execution subject to existing permissions and review.

The larger lesson from Chris’s experience is that the best starting point is not the most ambitious task. It is the task that gives finance a safe, visible win and creates more room for the work only finance can do: applying context, judgment, and business insight.