Musgrave store-visits workflow interview

Raw source preview

Raw, unprocessed file text shown below. Preview truncated for readability.

---
title: "Musgrave Store Visits Interview - Peter Kenefick"
status: processed
source_type: meeting transcript
session_date: 2026-07-23
duration: "48m 1s"
customer: "Musgrave"
participants:
  - Peter Kenefick
  - Desmond Leo
  - Gary Walsh
  - Declan O'Reilly
  - Fernando Guevara
product_area: "ShopTalk / EmpathyIQ store visit feedback"
tags: [musgrave, store-visits, customer-closeness, shop-talk, employee-feedback, product-options]
---

# Musgrave Store Visits Interview - Peter Kenefick

## Source Files

- [Empathy IQ and store visits transcript.docx](<./Empathy IQ and store visits transcript.docx>) - original Word transcript/recording export.
- [source-transcript.txt](./source-transcript.txt) - plain-text extraction from the Word file.

## Executive Summary

Peter is trying to respond to a new CEO-led "customer closeness" / store closeness push inside Musgrave. The goal is to get more Musgrave employees into stores, help them capture observations, and make that feedback useful without forcing Peter's insights team to mediate every follow-up.

The request is still unclear because there are several possible goals mixed together:

- Help employees capture their own store-visit notes, photos, and voice feedback.
- Let employees access or receive their own submitted feedback after the visit.
- Let employees optionally share feedback with internal teams or store owners.
- Let Musgrave still analyse store visits in aggregate over time.
- Make the experience low-friction enough that employees actually use it.
- Support a cultural change programme, not just a one-off survey.

The main product tension is this: the simplest version is a generic survey link, but that does not give employees useful ownership of their feedback. The richer version starts to look like an authenticated employee panel / mission hub, which may be strategically better but is much larger and could become a bespoke Musgrave build.

## People And Roles

- **Peter Kenefick:** Musgrave customer contact. He is interpreting a still-forming internal business request rather than bringing a fully defined brief.
- **Desmond Leo:** Head of Product at EmpathyIQ.
- **Gary Walsh:** CTO at EmpathyIQ.
- **Declan O'Reilly:** Founder.
- **Fernando Guevara:** UX.
- **Adele:** Musgrave stakeholder Peter wants to brief before a CEO webinar.
- **Niall:** Musgrave CEO, referenced as the source of the customer/store closeness push.

## What Problem Is Being Solved?

### 1. Store closeness needs to become easier to practise

Musgrave wants more employees to go into stores and pay attention to what is happening there. This is partly cultural: employees should be closer to stores, customers, and execution on the ground.

Peter thinks ShopTalk / EmpathyIQ may help by giving employees a simple way to capture what they see during store visits.

**Key evidence:** 00:36-01:00, 13:51-14:25.

### 2. The insights team should not have to mediate every store-visit output

Today, Peter's team controls access to EmpathyIQ and acts as the gatekeeper for research findings. That works for formal research projects, but it may not work for ongoing store visits by many employees.

Peter wants employees to have line of sight to their own feedback so they can use it without always asking the insights team to pull it out.

**Key evidence:** 01:04-02:59, 08:26-09:56, 14:25-15:03.

### 3. Employees may need to share their own feedback

The most concrete missing feature is that a person who completes a store-visit survey cannot easily receive or share their own submission.

Possible sharing targets include:

- themselves
- their team
- marketing or trading teams
- store owners, who may be outside Musgrave systems

**Key evidence:** 03:01-03:44, 15:04-18:15.

### 4. Musgrave may still want aggregate analysis later

Peter does not want to lose the ability to analyse all store visits in aggregate. Even if the day-to-day loop is decentralised, the insights team may still want quarterly or monthly themes.

**Key evidence:** 13:21-13:48.

### 5. The ask is partly about culture, not only research

If the real goal is behaviour change, the product may need to encourage participation, not just collect feedback. This opens up ideas like missions, employee engagement, participation tracking, and gamification.

**Key evidence:** 25:21-27:44, 32:39-36:47.

## Constraints And Challenges

### 1. The brief is not fully formed

Peter repeatedly says he has not fully thought through the shape of the request. He is also interpreting a wider business push rather than carrying a detailed product brief.

This means we should avoid committing to a large build until Musgrave decides what success means.

**Key evidence:** 11:54-12:51, 28:46-31:49, 47:13-47:36.

### 2. Success is not yet defined

Fernando asked what the CEO would consider success: number of store visits, behaviour change, or a specific insight. Peter did not yet know.

This matters because different success metrics imply different products.

- If success is "more visits", then participation, nudges, and gamification matter.
- If success is "better store action", then sharing and follow-up matter.
- If success is "better insight", then analysis and reporting matter.

**Key evidence:** 26:36-27:44.

### 3. Friction and security pull against each other

Peter wants low friction. He does not want employees to deal with a heavy login or full platform UX, especially if they only do one or two visits a year.

Gary warned that low friction can mean weak security. If feedback can be shared outside Musgrave, an open link or PDF can expose sensitive business information.

**Key evidence:** 16:54-17:33, 19:17-24:42, 29:07-31:33.

### 4. Identity matters if users receive their own feedback

If the system sends a summary back to "the person who submitted", it needs to know who that person is. An anonymous link cannot safely do that.

Options include:

- ask for email at the end
- require login
- treat employees as panelists
- use one-time email authentication

Each option has trade-offs.

**Key evidence:** 20:21-23:03, 24:09-24:42.

### 5. External sharing creates DPO / DPIA questions

Some store owners may not be inside Musgrave systems. If employee feedback is shared externally, Musgrave must decide how comfortable it is with that feedback leaving the controlled platform.

Audio, photos, transcripts, and negative comments all create risk. Gary called out that frictionless external sharing may create data protection issues.

**Key evidence:** 18:45-24:09.

### 6. Voice notes create accuracy and privacy trade-offs

Peter preferred transcript over raw audio. Gary noted that raw audio can create data protection issues because it includes someone's voice, while transcription can be inaccurate for accents or store-specific wording.

**Key evidence:** 18:15-19:17.

### 7. The use cases vary widely

Peter described several different visit types:

- new joiner store visits
- marketing campaign checks
- trading or range checks
- general store observations
- competitor visits
- formal projects where insights will analyse the results

One generic tool may not serve all of these well.

**Key evidence:** 04:06-07:18, 10:24-11:17, 39:18-40:30.

### 8. Avoiding bespoke build remains important

A large custom Musgrave store-visit tool may not fit EmpathyIQ's desire to behave more like a scalable tech company. Some options below reuse existing platform concepts better than others.

This should be an explicit trade-off for Declan and Peter.

## Solution Options Discussed

### Option 1 - Use the current generic store-visit survey link

**What it is:** Keep using a generic survey link for store visits. Musgrave can share the link plus a guide or video explaining how to do a store visit.

**What already works:**

- Employees can submit store visit feedback.
- Feedback can be collected in one dataset.
- Peter's team can analyse results in aggregate later.
- It can be used quickly for the upcoming CEO/socialisation moment.

**What it does not solve:**

- Employees cannot easily receive or share their own submitted feedback.
- Peter's team may still need to pull outputs manually.
- It may not drive culture change by itself.
- It does not create a persistent employee engagement loop.

**Best for:** Immediate rollout, no or low build, proving basic usage.

**Risks:** It may feel like just another link. It may not create ownership or sustained participation.

**Key evidence:** 14:25-15:03, 38:01-39:18, 40:53-41:43.

### Option 2 - Add a simple "send me / share my summary" flow after survey completion

**What it is:** After completing a store-visit survey, the employee can send a summary to themselves or another email address. The summary could include scores, comments, transcript text, and uploaded pictures.

**Possible UX:**

1. Employee completes the store-visit survey.
2. The final screen asks: "Do you want to send a summary?"
3. The employee enters one or more email addresses.
4. The system sends a summary or protected link.

**What it solves:**

- Employees can use their own feedback without Peter's team pulling it manually.
- They can share feedback with internal teams or store owners.
- It keeps the workflow close to the existing survey pattern.

**Key risks:**

- If the survey is anonymous, the system does not know who submitted.
- If external store owners receive links or PDFs, the feedback can leave Musgrave control.
- A PDF attachment is easy, but has little access control after sending.
- A protected link is safer, but adds login or one-time-code friction.

**Best for:** A focused feature addition if Musgrave accepts the security and authentication trade-offs.

**Key evidence:** 17:33-18:48, 19:17-24:42.

### Option 3 - Require lightweight authentication for employee submissions

**What it is:** Employees authenticate before completing store-visit tasks, likely as panelists or through one-time email codes. This makes it possible to safely show each employee their own feedback and history.

**What it solves:**

- The platform knows who submitted each visit.
- Employees can access their own past submissions.
- Sharing can be more controlled.
- Security is stronger than anonymous links.

**Trade-off:**

- It adds friction.
- Peter worries that heavy login/setup may reduce engagement.
- Gary argued that one-time setup friction may unlock lower-friction features later.

**Best for:** Any route where people need a history, ownership, or secure sharing.

**Key evidence:** 20:21-23:03, 29:07-31:33.

### Option 4 - Create a Musgrave employee panel / mission hub

**What it is:** Treat Musgrave employees as an internal panel or community. Employees log in and see tasks or missions, such as store visits, website checks, campaign checks, competitor observations, or internal surveys.

**Possible features:**

- employee profile / panel account
- assigned missions
- store visit tasks
- optional points or rewards
- participation tracking
- history of completed visits
- future employee surveys
- aggregate reporting

**What it solves:**

- Stronger identity and security.
- Better support for culture change.
- Better long-term employee engagement.
- Reusable beyond store visits.
- Could support HR or leadership-led tasks, not only insights-led research.

**Why it is appealing:**

Desmond suggested this because if the goal is culture change, a panel/community model may fit better than a one-off survey link.

**Risks:**

- Larger build.
- More change management.
- Ownership may shift beyond Peter's insights team, possibly toward HR or leadership.
- Could become a bespoke Musgrave solution unless mapped carefully to the broader platform roadmap.

**Best for:** A more ambitious 18-24 month vision if Musgrave wants store closeness to become a permanent operating behaviour.

**Key evidence:** 25:21-27:44, 32:39-36:47, 39:18-40:30.

### Option 5 - Gamify visits but keep outputs controlled by insights

**What it is:** Encourage people to complete store visits through