Anthropic's own field marketing team had a familiar problem. Every Sunday night, someone collated updates from across the business into a slide deck, delivered live at Monday stand-up, then forgotten by Wednesday. As the team supporting sales reps grew, the manual routine could not keep up, and the updates stopped being useful because nobody had time to work out what mattered to each rep's own patch. The fix was not a new tool. It was Claude Code, pointed at a business problem instead of a codebase.
The approach: explain the problem, not the code
The marketer behind this build is not technical. The starting point was describing the challenge to Claude Code the way you would brief a product manager: a weekly Slack message to each sales rep, personalised to their accounts, covering what is happening in marketing and how it helps their customers. A rough template followed, a "top three things this week" format, since reps respond better to action items than to a wall of updates. A separate rollup template covers managers who want a team-wide view rather than individual accounts.
From there, Claude Code was connected through MCP to BigQuery, the team's source of truth pulling data from HubSpot, Clay, and Salesforce. The build started narrow, with just events and webinars, then expanded to include blog content, ebooks, and customer stories, personalised against each rep's territory and recent account activity. Nobody wrote a line of BigQuery SQL by hand. Claude Code handled that part, and the marketer reviewed the output each week until the templates settled.
Why this shape of automation works for Australian businesses
We see this pattern constantly with clients in Sydney and Melbourne. The bottleneck is rarely a lack of data. Most businesses already have a CRM, a spreadsheet, or a reporting tool that holds everything needed to brief a sales team, a client base, or a franchise network. What is missing is someone to rewrite that data forty different ways for forty different people, every week, without fail. That is repetitive work, and it is exactly the kind of task Claude Code and an MCP connector into an existing data source can take on.
Connecting to one existing data source, a CRM, data warehouse, or spreadsheet, through an MCP server, rather than building new infrastructure
A short brief describing the audience, the format, and what "useful" looks like for each recipient
A narrow first version covering one data type, expanded once the output is trusted
A human reviewing the output weekly until the template stabilises, then reviewing on exception only
What it costs to build, and what it saves
A build of this scope, one MCP connector, a handful of templates, and two to three weeks of iteration, typically runs from $8,000 to $18,000 depending on how many systems it needs to read from and how messy the underlying data is. That is a fixed, one-off cost. Compare that against the labour it replaces: a marketer spending even four hours a week on this kind of reporting, at a fully loaded cost of around $150 an hour, is roughly $31,200 a year in time that could go toward campaign work instead. The build pays for itself well within the first year, and it keeps paying every week after that.
Does the source data already live somewhere queryable, a CRM, warehouse, or structured spreadsheet, or does it need to be collected first
Who reviews the output before it goes out, and for how long
What happens if the underlying data is wrong. Personalised reports built on bad data do more damage than no report at all
Where this breaks down
This pattern is not a fit for every business, and it is worth being upfront about where it stalls. If the source data is scattered across email threads, personal spreadsheets, and someone's memory, an agent cannot personalise what does not exist in structured form yet. If nobody is willing to review the first few weeks of output, small errors compound and the reports lose trust fast. And if the business genuinely needs the reporting to be identical for everyone, a shared newsletter is the cheaper and safer option, not a personalised agent. The Anthropic case study worked because someone owned the review step and the data was already centralised in BigQuery. Skip either of those and the project stretches well past the estimate above.
There is also a data-privacy angle worth flagging for regulated Australian sectors. If the CRM or warehouse holds client financial or health information, check what the MCP connector can see before wiring it up, and keep the same access controls you already apply under the Privacy Act. A personalisation agent should never be the reason sensitive data ends up somewhere it was not meant to go.
If your business has a weekly report that nobody reads because nobody has time to make it relevant to the person receiving it, that is usually a sign the underlying data is already in good enough shape to automate. [Book a session](/contact) and we will tell you honestly whether it is a two-week build or a bigger job.
