Problem Solving

"Can you tell me about a situation with a customer when there wasn't a clear policy to use, and you needed to make a judgment call? How did you approach your decision, and what happened?"

At Jivox, I handled both pre and post-sales for P&G. The initial scope involved reporting data flowing out from our platform into their DAM and reporting tools. Performance metrics against each creative would be associated in P&G's reporting system, allowing brand managers across the world to see how well certain creative templates performed.

Mid-implementation, P&G asked if they could use their DAM to bring assets into our platform rather than uploading manually. We did not have this capability. Building a dedicated product feature would require significant resource and time.

I proposed an interim solution on the call. Their DAM already had the capability to push to S3, so P&G's developers could configure it to push assets into a bucket, and on our side we would pull those assets into the platform. We had worked with S3 buckets extensively, so I was confident this approach would work. I also gathered initial requirements for a proper product integration and scheduled a follow-up session to capture the full scope.

Leadership saw the potential to scale this out to other clients, so we built the dedicated integration. P&G benefited from the interim solution in the short term and the tighter integration in the long term. They were satisfied with how the situation was handled.

"When responding to a customer, how do you decide what information to include, and what to leave out?"

What to include:

• An answer that resolves what they need. If additional context helps reduce follow-up replies, I include that too.
• The right level of detail for the audience. A developer gets technical specifics. An account manager gets a middle-ground explanation. An executive gets a summary.

What to leave out:

• Internal terminology or jargon that does not help them.
• Technical detail that is not relevant to their role or question.
• Unnecessary backstory or context that does not move things forward.
• Timelines I cannot commit to.

"Have you had a time when a customer was reporting a technical issue that you didn't know the answer to? What was your approach, and how did it end up?"

At Adobe, a client wanted to run campaigns through an SSP we had not worked with extensively. We had an integration in place, but it had not been tested at scale. The campaign was set up, but it was not spending at all.

It was blocking spend and needed to be resolved. I requested a bid request sample from the SSP and tested against it using Postman, but I could not get a positive response. In most cases, these issues have straightforward fixes. This one did not.

I communicated to the client that I had escalated the issue to engineering and opened a ticket. I also kept the client copied on email threads with the SSP so they had visibility into the progress. However, I continued investigating. While adjusting bid values during testing, I noticed that their bids were formatted with one additional decimal point compared to what I had seen in other integrations. I tested by adjusting the values and received a successful response.

I asked the SSP if this was something they could adjust on their end, and they confirmed it was. They amended the deal configuration and the campaign started spending. The client was satisfied with the resolution.