Defining what an AI assistant would need to support fieldwork
A four-week discovery engagement exploring how SPAR’s zone leads coordinate assignments—and where an intelligent assistant could help.
We found that leads supplied the continuity their tools lacked: carrying information between systems, finding replacement workers, and making sure changes reached the field. Our research informed three UX recommendations: keep task context together, surface coordination problems earlier, and make knowledge about reps easier to retain.
- B2B / Enterprise
- UX Research
- AI Product Discovery
- My role
- Lead Product Designer, alongside one other designer and partners in Product and Engineering
- Client
- SPAR, a global merchandising and marketing services company
- Scope
- Four-week discovery engagement, preceded by stakeholder conversations and interview scheduling.
- Result
- Research findings and UX recommendations. The engagement paused before detailed design, implementation, or outcome measurement.
Job Level Assignment (JLA) / One of the existing tools zone leads used to manage and reassign fieldwork, shown in a contextual mockup.
The coordination work behind every assignment
SPAR’s zone leads coordinate merchandisers across stores, programs, and changing schedules. They match people to jobs, respond to cancellations, and maintain relationships with reps and store teams.
SPARview and related tools supported planning and reporting, but completing an assignment change still required repeated searches, calls, texts, and manual updates. Leads connected the pieces themselves.
Our challenge was to understand where an intelligent assistant could reduce that effort while preserving the judgment involved in choosing and coordinating the right person for a job.
My role and collaboration
I set the research direction, guided my design partner, and led client conversations. We shared interviews, synthesis, and concept development.
My design partner and I contributed the design findings to a shared final readout deck, alongside content from Engineering and Product. The AI co-pilot direction emerged collaboratively. Engineering owned the systems and data recommendations; our design work established the user needs and working patterns those recommendations would need to support.
Following the work across systems
We conducted 11 interviews across operational leadership and field management, including four zone leads. We explored daily workflows, assignment decisions, communication patterns, and attitudes toward automation. We also reviewed existing applications and mapped the processes connecting them. The fourth week focused on synthesizing our findings and preparing our contributions to the shared final readout.
Stakeholders had described the tools as disjointed. Watching leads walk through their work showed what that meant in practice: information had to be found again, decisions depended on knowledge outside the systems, and saved changes required additional steps to reach the field.
“These windows that you see open are the ones that I use every single day… Status report, JLA, Manage Merch, Store Visit Reporting and Mobile Device Fetch.”
A cancellation made those dependencies particularly clear.
One cancellation, six coordination steps
When a rep cancelled by phone or text, the lead had to:
step 01
Find the affected work
Status Report
Filter by zone, client, store, and task.
Repeated lookup
Switch tools
step 02
Find it again in Job Level Assignment (JLA)
JLA
Search for the same store and select the tasks needing coverage.
Repeated lookup
step 03
Find a replacement
JLA + calls/texts
Consider distance and knowledge of each rep, then call or text as needed to confirm availability.
step 04
Save the new assignment in JLA
JLA
Select the replacement and update the assignment.
Switch tools
step 05
Send the change to the rep’s app
Mobile Device Fetch
Look up their ID and run Mobile Device Fetch.
Separate app update
Switch tools
step 06
Update Status Report
Status Report
Record the rep’s commitment and planned work date.
Reassignment workflow / A single cancellation required the lead to find coverage, update multiple records, and ensure the new assignment reached the replacement rep.
The lead carried the task’s context through the entire sequence. Finding a replacement was only one part of the work; they also had to reconcile records, secure a commitment, and ensure the assignment reached the person doing it.
This pointed to an opportunity to preserve context throughout reassignment, reducing the need to reconstruct the same job across tools.
Assignment decisions depended on more than job records
Systems held information such as distance, existing assignments, completion times, and job requirements.
Leads contributed a different kind of knowledge: who reliably showed up, who was comfortable with the work, which jobs someone preferred, and how they worked with store staff.
What the system tracks
- Travel distance and routes
- Current assignments
- Past completion times
- Job requirements
- Store hours and access rules
the decision
Who should
take this job?
What the zone lead knows
- Who reliably shows up
- Who is comfortable with the work
- Which jobs someone prefers or can take
- How they work with store staff
- Where they may need support
Job assignment / Choosing a replacement combined operational records with knowledge built through working relationships.
Much of that knowledge lived in memory, personal spreadsheets, calls, and texts. It was difficult to share or pass on to a new lead.
One role, two working modes
Our synthesis identified two recurring modes of work. Leads moved between them as circumstances changed.
Reconciling systems
Pulling reports, maintaining trackers, checking eligibility, and comparing records. Duplicate searches and manual updates made this work more difficult.
Resolving people issues
Responding to cancellations, chasing commitments, and handling store or client escalations. Important conversations happened outside the systems, and problems could emerge with little warning.
Time spent resolving an immediate issue also took leads away from checking for the next one.
“I don’t even get notified of the request. I just have to stumble across it when I’m in JLA.”
Three recommendations for assignment support
Recommendation 01
Keep the task and its context together
Finding
A reassignment required repeated searches and updates across tools.
Recommendation
A persistent rep/store workspace bringing assignments, status, notes, materials, mileage, and issues into one view. The intent was to help leads move through a task while retaining the information they needed.
Recommendation 02
Make emerging problems easier to see
Finding
Leads could discover unanswered requests, missed dates, and coverage issues too late.
Recommendation
Surface these signals alongside unanswered outreach and unresolved coverage needs, helping leads identify where follow-up was required.
Recommendation 03
Make assignment knowledge easier to retain
Finding
Important knowledge about reps and stores sat outside the systems.
Recommendation
Make skills, availability, preferences, constraints, and history easier to capture and reference when considering assignments.
What this meant for an AI assistant
The research helped frame potential assistance around identifying problems, gathering relevant context, and narrowing options. Our recommendations retained lead control over consequential assignment changes.
It also exposed a dependency: useful assignment support would need information that existing job records did not contain.
Engineering developed recommendations for data integration and communication capture. Together, the design and engineering work described the operational records, communication, and rep knowledge a future platform would need to connect.
Rep Knowledge in Leads’ Heads
The data that matters most isn’t in any system.
Skills, true availability, real capacity, reliability patterns, preferences, exclusions, choice reasoning — the information that drives every assignment decision lives in zone leads’ memory and personal spreadsheets. New leads inherit none of it.
Out-of-Network Data
The work happens in places the system can’t see.
Critical context lives in phone calls, text threads, ad hoc spreadsheets, and side conversations with reps, managers, and store contacts. None of it is captured against the assignment, rep, or store it relates to.
Engineering readout / Engineering’s contribution to the shared readout identified rep knowledge and informal communication as gaps a future assignment-support system would need to address.
The UX recommendations established needs for subsequent design. Detailed assistant behaviors, technical feasibility, and effects on the workflow remained to be evaluated.
Where discovery ended
The engagement paused after week three. We devoted the fourth week to synthesis and preparing the final readout, bringing together findings and recommendations from Design, Engineering, and Product.
Formal workflow prioritization, wireframes, detailed technical solution design, baseline measurement, and implementation planning did not proceed. The recommendations were not implemented, and operational improvements were not measured.
Proposed · not yet tested
What I would test next
I would use the cancellation scenario to evaluate the recommendations together: could a lead identify the problem, assess replacements, and coordinate the change while keeping relevant information in view?
I would look for fewer repeated searches and updates, earlier visibility into coverage problems, and whether leads could capture and use rep knowledge during real assignment decisions.
The central learning was how much coordination happened between the tools. Any proposed assistant would need to account for that work—and the judgment sustaining it.