Campaign Asset CRM

On Campus

Working on-site at Google's Sunnyvale campus was something else. The scale of the place hit immediately. Free restaurants, game centers and cafes, the reality of work-life here was fun and astonishing. Watching employees play soccer in the full size pitch in the middle of campus during lunch was an experience.

The people were just as distinguished. My primary contact for the duration of my stay, Luca, quickly became of my favorite people I've met through work. When he found out I'd never seen the Golden Gate Bridge, he drove me an hour up to San Francisco to see it in person. Everyone I worked with was open, collaborative, and genuinely easy to be around.

The Challenge

After taking in the sights it was time to get to work. What I learned was that Google's various product teams had no centralized system for managing customer references. When a team wanted to use a reference contact for an opportunity or event, there was no way to check if that contact was approved, see how recently they'd been used, or submit a formal request. Approvals happened over email and usage history wasn't tracked at all.

IBM placed me on-site at Google's Sunnyvale, California office to design a CRM that would bring all of this into one place: approvals, activations, requests, and event tracking, built on Salesforce Lightning.

Research & Discovery

Working on-site gave me direct access to account managers, campaign coordinators, and team leads. I ran stakeholder interviews and workflow audits to understand how references moved through the organization. The tension was clear quickly: Google needed detailed metadata for tracking and reporting, but the people actually using references day-to-day just needed to find the right contact and move on.

The research also turned up a less obvious problem. When a sales team needed a reference for a prospect, there was no way to see when and where certain contacts had been used previously. Good references were going underused internally due to lack of visibility.

Design Approach

Using a reference was a two-part process. First, the contact needed to be internally approved and activated. Then, teams could submit requests to use that contact for a specific opportunity or event. I designed the system around this workflow, starting with a dashboard that showed managers exactly where things stood: how many requests were waiting, which contacts needed activation, and what events were coming up.

From the dashboard, managers could open any pending request and approve or deny it directly. A links panel gave quick access to the reference database, asset database, event database, contact nominations, and historical requests. The goal was to make the entire approval and request cycle manageable from one screen.

Everything was built within the Salesforce Lightning Design System. That constrained some layout choices, but it also meant Google's existing Salesforce team could maintain and extend the platform without outside help. I worked within those constraints on purpose. The goal was a tool that would last, not one that needed a design team to keep running.

Requests & Activations

The request flow let teams submit peer-to-peer reference requests tied to specific opportunities. The form pulled in context from the linked opportunity, like account name and product family, then let users filter the contact database by persona, region, country, product category, industry, SLA, and expected event date. Instead of asking around to find a contact, teams could search for exactly what they needed.

Approved references still needed to be activated before use. I designed a stepped activation flow that walked managers through confirming they'd reached out to the contact, selecting them from the database, and filling in details like primary workload, use cases, engagement frequency, and start date. Once activated, the contact joined the reference community and was available for future requests.

Patterns & Handoff

Beyond individual screens, I documented reusable patterns for record layouts, search and filter behavior, detail panels, and form conventions. All of it aligned with Salesforce Lightning standards but shaped around Google's specific workflows.

This mattered because engineering would own the platform after my engagement ended. Every pattern I handed off included interaction specs, edge case handling, and the reasoning behind design decisions, so the team building it could make smart tradeoffs without having to guess at intent.

The Outcome

The platform replaced a process that had been running on email and memory with a single system for managing references end to end. Managers could see what was pending, approve or deny requests, and track which contacts were active, all from one place. Teams could search for the right reference instead of asking around.

The activation flow gave the process real structure for the first time, making sure contacts were onboarded properly and their availability was tracked. And because everything lived in Salesforce Lightning, Google's own team could keep building on it after I was gone.