The conceptual case for connecting your WFM data to AI is easy to make. The harder question is what it actually looks like when someone builds it and runs it in production.
Thomas O'Rear, Senior Director of Operations at FuturHealth, has been running the Assembled MCP since launch. He manages customer service, a revenue-generating sales and retention team, and clinical partnerships — the last of which he treats like a BPO relationship. His stack includes Assembled, Zendesk, Google BigQuery, and PostHog, all connected to Claude.
Here's what he's built and how it works.
Weekly business review: 98 slides, 15 minutes, every Monday
Before Claude, producing a comprehensive business review meant pulling exports from each tool, stitching them together, reformatting for leadership, and hoping nothing had changed by the time it landed in inboxes. It was a half-day task. It happened because it had to, not because anyone enjoyed doing it.
Thomas rebuilt this from scratch using Claude. A Python script, written with Claude's help over a few sessions, pulls live data from Assembled, Zendesk, BigQuery, and PostHog, then generates a 98-slide branded deck that covers operational metrics, voice AI performance, customer sentiment, and intent analysis. The deck is formatted to FuturHealth's color scheme and presentation template, because he shared the company's brand deck and presentation template with Claude during the build.
The script runs every Monday morning. It takes about 15 minutes. When it finishes, each team leader has a section covering their function — service delivery, white-glove support, clinical partnerships — with their key metrics for the prior week, compared to the week before and to month-to-date and quarter-to-date benchmarks.
A few things worth noting about how this actually works:
The deck is dynamic. If Thomas wants to look back six weeks and see how a specific metric has trended, he can adjust the time window and rerun. The output reshapes around whatever period he specifies.
The build required upfront token investment. Getting the scripts right and QA-ing the data against source systems took real time. But that cost was finite. Once the scripts were stable, he moved them off Claude entirely — the Monday morning run hits API keys directly, not a live Claude session. The expensive part happened once.
"Could I have done that a year ago? Absolutely. That technology is mature. Would I, as a customer service director, have been able to structure that on my own? No."
That's the real shift. The gap between "this is technically possible" and "a non-engineer can build and maintain it" collapsed.
BPO billing reconciliation: from a day's work to a clean artifact
For teams managing outsourced agents, billing reconciliation follows a familiar and unpleasant pattern. The invoice arrives. You export productive hours from your WFM platform. You spend time matching line items, converting between rate structures, identifying gaps, and writing up variance explanations to send back to the vendor. For teams with multiple BPO partners, this repeats every month.
Thomas built a financial tracking skill to handle this. The setup: the skill already has context on FuturHealth's invoicing structure. When a new invoice comes in, he uploads it to Google Drive, runs the skill, and points it at the relevant queues in Assembled.
Claude pulls the invoice from Drive, pulls productive hours from Assembled by queue, matches billed hours to actuals, calculates dollar variances by line item, and generates a formatted reconciliation artifact, ready to share with the vendor.
The output includes the total billed hours, the Assembled actuals, the variance by role and queue, the hourly rates, and a flag on any line items that couldn't be reconciled cleanly. It's the same document a vendor manager would produce after an hour of manual work, but it takes a few minutes and requires no manual matching.
Where there are gaps (roles or line items that don't map directly to Assembled queues), Thomas provides that context in the skill instructions. The skill knows the queues to use, the rate structures to expect, and the format the vendor needs. It doesn't guess.
This is a useful template for any BPO-heavy operation. The workflow isn't specific to FuturHealth's vendors or tools. It's a pattern: define the skill once around how your invoices are structured, connect Assembled and wherever your invoices live, and run it monthly.
Multivariate forecasting: when Assembled's built-in model isn't enough
Assembled's forecasting is built for teams with enough history to find reliable patterns. For mature operations with stable seasonality, it does the job well.
FuturHealth is in a different situation. They're growing fast, in a space (GLP-1 weight loss) that's still expanding its patient base. The forecast isn't just a function of historical volume — it depends on what the marketing plan looks like, how customer acquisition is pacing against revenue targets, and what that implies for new patient contacts. Standard time-series forecasting on historical WFM data misses most of that signal.
Thomas's solution: pull Assembled metrics through the MCP, layer in acquisition data from other connected tools, and build multivariate forecast models using Prophet (a forecasting library originally built at Meta, well-suited to business time series with external regressors). Then push the refined forecast back into Assembled at the daily, weekly, and hourly level.
The result is a forecast grounded in what's actually driving volume, not just what happened last quarter. And it runs inside Claude, with the output published back to Assembled. No data engineering team required.
"A lot of what we've been able to do is leverage the MCP server for Assembled, bring those metrics out, do much more complicated forecasting using Prophet... The great thing about how Assembled has built the MCP server is that I can go take that, build that plan, iterate on it, and then push it back in."
This won't apply to every team. If your volume patterns are stable and your forecasting accuracy is already solid, the complexity isn't worth it. But for high-growth teams, acquisition-driven businesses, or any operation where external factors heavily shape contact volume, the MCP opens up modeling that wasn't tractable before without a dedicated data science function.
What makes these workflows work
These workflows are what an agentic workforce management operation looks like in production: repeatable automation running every week, not a demo or a proof of concept.
A few things are consistent across all three:
The skill does the work, not the prompt. None of these run on a clever one-liner in the chat box. Each workflow has a defined skill behind it — a precise set of instructions that encodes the context, the data sources, the logic, and the output format. Thomas spent time building them well. That upfront investment is what makes them repeatable and transferable to other team members.
Context lives in the skill, not in your head. The BPO reconciliation skill knows FuturHealth's queue names and rate structures. The business review script knows the brand colors and slide template. The forecasting workflow knows which external signals to pull. None of that context has to be re-explained each time. It's already there.
Mature workflows leave Claude. Once a workflow is stable, Thomas moves it off live Claude sessions and runs it via local scripts or scheduled jobs that hit API keys directly. This keeps token costs bounded and makes the automation less fragile. Claude is for building and iterating; cheaper execution paths handle production runs.
Security is a design decision, not an afterthought. FuturHealth is in healthcare. They treat CX conversation data as PHI, maintain a BAA with Anthropic, and built an internal MCP layer that explicitly controls which data is accessible to which models. That architecture is worth understanding even if you're not in a regulated industry. It's a clean model for any organization that needs to limit data exposure.
Where to start
The most practical first step is the same regardless of your stack: pick the question you answer manually every week. Build a skill around it. See what 15 minutes of automated work looks like. Then go from there.
If you're an Assembled customer, the MCP setup takes about five minutes. The instructions are in the Help Center.
