When I joined the work, Funlab’s US venues ran their function bookings on a separate platform, disconnected from the Salesforce org that already ran the entire Australian and New Zealand business. The brief was simple to say and hard to do: make Salesforce the single system of record for the US, ready before the next US brand opened on it.
I owned the Salesforce engineering for that program. Here is what shipped, and why it mattered.
The shape of the problem
Two things made this more than a configuration job.
First, the US is a genuinely different market on Salesforce. Sales tax there is per-state and per-jurisdiction, nothing like Australia’s flat, price-inclusive GST, so US bookings need real calculated tax on every line before a quote or invoice goes out. US documents, payment timing, telephony, date formats, and support routing all diverge from how AU and NZ work.
Second, there was no separate US org to build in. Everything shipped into the same live org running 50+ Australian venues and 6 in New Zealand. So every US feature had to be additive, switched on by venue and region, and incapable of breaking workflows two countries already relied on every day.
The program ran in two deliberate phases. First an offline phase: Salesforce as the internal system for the US team, covering tax, booking and management flows, documents, and telephony. Then an online phase that wired Salesforce into the e-commerce booking flow so guests could book US functions on the web.
What I delivered
US tax, calculated automatically
The core piece was integrating AvaTax (Avalara’s managed package) so US tax calculates automatically against each booking’s line items, per state. US venues map to the right tax entity — one state resolves to its own subsidiary, everything else to a default. A percentage service charge recalculates on top of the line-item total with tax applied to the correct base, and tax-exempt bookings zero out cleanly and flag the exemption for audit.
What this means for the business: US staff never hand-calculate tax, and every quote, invoice, and contract leaves the system with jurisdiction-correct figures from the first booking.
A booking-to-document workflow built for the US
I built the create and manage booking flows for US venues and connected them to Conga for documents and Conga Sign for e-signature. A US booking moves through quote, deposit due, deposit paid, and full payment, with the right document generated and emailed at each stage. Document generation waits for tax to finalize, so contracts never go out carrying stale numbers. Payment timing, surcharge rules, and reminder cadence run on US schedules, independent of the AU/NZ reminder jobs.
New US brands launched on the same platform
Once the foundation existed, new US offerings became configuration instead of rebuilds. That is the whole payoff of getting the platform design right. I delivered the Salesforce side of launching a new hybrid activity-and-function brand in the US, rolled out in phases, and later a complete whole-venue booking flow.
That second one is a good snapshot of the velocity the platform now supports. A single release shipped roughly three dozen tracked changes — a new Opportunity record type and booking flow modelled on an existing pattern, US finance fields and a tax-exempt path, a full set of document templates and e-signature, automation for finals, overdue balances, stage progression and tasks, and support routing under US rules — alongside a batch of platform-wide cleanups. None of it required touching the AU/NZ paths.
Telephony and support routing
US support needed its own plumbing. I set up dedicated US case, refund, and lead queues, wired web lead capture into Salesforce for US venues, and supported the migration of US telephony onto Amazon Connect, consolidating venues that had been spread across separate phone systems onto one platform.
Keeping the platform current underneath it all
Platform work does not pause for a launch. During the same window I completed the migration from Standard to Enhanced Omni-Channel ahead of Salesforce’s retirement deadline, so routing kept working through a forced platform change with no interruption on the floor.
The outcomes I’m proud of
The US runs on Salesforce as its system of record. Bookings, tax, documents, payments, and support all live in one org instead of a disconnected tool.
New US brands launch as configuration, not re-platforming. Both subsequent launches came online on the foundation rather than as separate builds. That is the clearest evidence the multi-region design holds.
US, AU, and NZ logic all coexist in one org, gated by region and venue, with no fork to maintain. And none of it disrupted the live AU/NZ business; every US feature went in additively to a production org two countries depend on daily.
What I learned
The lesson that stuck was restraint. On a launch this size the easy move is to fork: US-only code paths, US-only objects, US-only everything. It buys short-term speed and a maintenance bill you pay forever. Designing the US in as a region of the existing platform, a flag and a venue attribute rather than a parallel system, was harder up front and paid for itself the moment the second and third US product lines landed as configuration instead of projects.
The other lesson was about the managed packages. Integrating around AvaTax and Conga was most of the real difficulty, because you own the outcome without owning the code. Respecting those boundaries, coordinating through fields I controlled and never assuming I could see inside the box, is what kept the launch stable once real booking volume hit it.
Close
This was the kind of work I like most. A real deadline, a live system you cannot afford to break, and one platform decision in the middle that either compounds in your favor or haunts you for years. Two years on, Funlab’s US business books, taxes, documents, and gets paid through the same Salesforce org as the rest of the company, and adding the next US brand is a configuration conversation, not a rebuild.