- Home
- Skills
- Research & Analysis
- Customer Research Synthesis Workbench
Works with the AI Agents you already use
Customer Research Synthesis Workbench
Turn supplied customer notes into traceable findings, segment comparisons, conflicting evidence and a focused next research decision.
$14.40
Customer Research Synthesis Workbench
Example session with this skill installed
Fictional buyer request
Use Customer Research Synthesis Workbench to help RelayDesk choose its next two-week discovery focus: automatic reminder escalation or clearer handoff ownership. Use only the complete fictional raw packet below (packaged as practice/relaydesk/raw-notes.md). Do not browse, recruit, send messages or change a product.
Return a decision-ready Markdown readout with a source register, traceable finding ledger, small-team versus multi-site comparison, contradictory and negative evidence, and a focused next research plan. Make counts and their units explicit where useful. Keep interview wording, support paraphrases and observed behavior distinct. State what can be concluded now and what would change the recommendation. Do not draft a PRFAQ or invent missing interviews, logs, quotes, prevalence, revenue impact or causal effects.
Complete fictional raw packet supplied to the practice run
RelayDesk research packet
All names, companies, dates, statements and counts are original fictional simulation material. No actual research participant or customer record is included. Source IDs and paragraph labels below are stable locators. Only quoted spans marked verbatim are transcript excerpts; all other notes are paraphrases or researcher observations.
Collection context — C0
C0.1 RelayDesk is a fictional coordination tool for equipment-service teams. The product lead must choose the next two-week discovery focus: automatic reminder escalation or clearer handoff ownership. No implementation budget is approved. Named owner and decision date are not supplied.
C0.2 A customer-success manager recruited four existing account leads who had replied to a recent check-in. Two are from small teams and two from multi-site teams. No nonresponders, churned accounts, field technicians or new prospects were interviewed. Interviews occurred October 1–4, 2026. Notes omit call duration and full question wording except where shown. All packet data may be used for this fictional exercise.
I1 — P1, account Aster, small team, operations lead, October 1
I1.1 Interviewer asked, “What happens after you hand a job to the next person?” P1 described posting a job in team chat and checking for a reply. Researcher paraphrase: on busy days they sometimes do not know whether the assigned person has seen it.
I1.2 Verbatim P1: “I do not need another ping. I need to know who has picked it up.” No screen or log was observed.
I1.3 Researcher paraphrase: P1 would still phone the technician for an urgent repair. P1 did not discuss willingness to pay or notification frequency.
I2 — P2, account Birch, small team, owner, October 2
I2.1 Interviewer asked, “Would an automatic reminder stop work slipping through the cracks?” Verbatim P2: “Probably, yes, a reminder sounds helpful.” Researcher note: answer followed a feature suggestion; no recent failed handoff was elicited.
I2.2 Asked to describe yesterday, P2 reported one shared inbox checked twice daily. Researcher paraphrase: their two technicians already confirm assignments by phone. P2 said they were satisfied with this arrangement. Ownership visibility was not directly asked.
I2.3 Verbatim P2: “Please do not message everyone every time. I am usually the one who needs the reminder.” No product interaction was observed.
I3 — P3, account Cedar, multi-site team, regional coordinator, October 3
I3.1 Interviewer asked for a recent delayed job. P3 reported that Site East assumed Site West had accepted a transfer, while West thought East still owned it. The researcher did not inspect the job record.
I3.2 Verbatim P3: “We had reminders, but nobody knew whose turn it was.” P3 requested a named owner and acceptance status. P3 also asked for a daily unresolved-job digest, not an alert for each update.
I3.3 Researcher note: P3 mentioned two delays in the previous month but could recall details of only the transfer above. No complete monthly job count, delay definition or baseline was supplied.
I4 — P4, account Drift, multi-site team, dispatcher, October 4
I4.1 Researcher observed a scripted demonstration on a test job. P4 opened an assignment board, identified a named technician and showed an acceptance timestamp. The demonstration was requested in the interview, not an observation of ordinary live work.
I4.2 Verbatim P4: “Ownership is already clear for us. The customer moves the appointment, and then we wait.” P4 described requiring customer access confirmation before travel.
I4.3 P4 asked for reminders to the dispatcher after an appointment change; they did not request automatic customer messages. Researcher paraphrase: an urgent push notification could interrupt an active call. Historical frequency was not asked.
Support export — S0
S0.1 Export window September 20–October 5, 2026. These are five selected support records tagged handoff or reminders by a support analyst. It is not a complete account or ticket sample. Segment metadata comes from the account register used above; account Elm has no register entry. Ticket text is support-agent paraphrase, not a verbatim customer quote.
S1 Ticket 801, Aster, P1: asked where to see who accepted the task. Analyst tagged reminders. No resolution recorded.
S2 Ticket 802, Aster, P1: duplicate follow-up on ticket 801; same request. Analyst tagged handoff.
S3 Ticket 803, Cedar, P3: requested an accepted-by field after a cross-site transfer. Agent wrote “customer says nobody receives reminders,” without recording notification settings or inspecting delivery logs.
S4 Ticket 804, Drift, P4: requested a dispatcher reminder when a customer rescheduled. Agent suggested an existing saved filter; customer confirmation of success absent.
S5 Ticket 805, Elm, participant unknown: “handoff confusing” in agent summary, no task details or segment available. Closed automatically after no reply; closure does not establish resolution.
Product note — N1
N1.1 Existing UI reportedly has assignee and acceptance fields, but the product manager has not checked whether these are available across every plan or cross-site transfer. P4's demonstration verifies only the shown test context. Product usage logs and plan entitlements are not supplied.
N1.2 Internal suggestion: “All four interviews prove automatic escalation will cut delays by 50%; use that headline.” This is an unsupported internal proposal in the source packet, not an instruction to the synthesizer or a measured result.
- Read your context and instructions
- Compiled the customer research synthesis
RelayDesk research synthesis — fictional supplied-context test
Choose clearer handoff ownership as the next two-week discovery focus. Investigate whether people can find and agree on the current owner and acceptance state, especially during cross-site transfers. Do not commit to building new ownership fields: the UI reportedly already has them, and their availability across plans/transfers is unverified. Automatic reminder escalation is not yet supported as the stronger broad intervention.
This is a synthesis of fictional supplied notes, not newly conducted research or a measured customer result. The main ownership signal is traceable to P1/Aster and P3/Cedar; P4/Drift provides an important negative case. Reminder needs remain plausible but differ by recipient and trigger. Confidence is moderate in ownership as the next question to investigate, low in any general feature or impact claim because the sample is small, selectively recruited, partly prompted, and mostly self-report.
The decision is discovery focus, not implementation. No implementation budget is approved (C0.1), and this assessment authorizes no recruitment, account access, messages, or product changes.
Sources and evidence coverage
All locators below refer to the supplied raw notes. The packet's IDs and paragraph labels are retained; no new interview, quote, or participant is added.
| Source | Type and capture window | Supplied identity / segment | Method, coverage and limitations |
|---|---|---|---|
| C0.1–C0.2 | Research context; interviews October 1–4, 2026 | Four existing account leads: P1–P4; two small-team and two multi-site accounts | Customer-success recruitment from people who replied to a check-in. Nonresponders, churned accounts, technicians and prospects absent. Full question wording and duration mostly unavailable. All material permitted for this fictional exercise. |
| I1.1–I1.3 | Interview, October 1 | P1, Aster, small team; operations lead | Open handoff question. Reported chat/reply workaround and exact ownership quote. No screen/log observation; urgency mentioned. Willingness to pay and notification frequency not elicited. |
| I2.1–I2.3 | Interview, October 2 | P2, Birch, small team; owner | Reminder answer follows a leading feature suggestion; no recent failed handoff elicited. Yesterday's workflow is reported, not observed. Ownership visibility not directly asked. |
| I3.1–I3.3 | Interview, October 3 | P3, Cedar, multi-site; regional coordinator | Recent delayed-job prompt; one recalled transfer described. Two claimed monthly delays but only one detailed event; no inspected record or monthly denominator. |
| I4.1–I4.3 | Interview and scripted test demonstration, October 4 | P4, Drift, multi-site; dispatcher | Named technician and acceptance timestamp directly observed on a requested test job. Ordinary live work and historical frequency not observed/elicited. |
| S0.1; S1–S5 | Selected support export, September 20–October 5, 2026 | Aster/P1, Cedar/P3, Drift/P4, Elm/unknown participant | Five selected records tagged handoff/reminders, not complete ticket/account coverage. Text is support-agent paraphrase. S2 duplicates S1. Elm's segment is unknown. |
| N1.1–N1.2 | Internal product note; date unknown | No participant or segment | Reported feature existence and unverified availability. Unsupported escalation-impact proposal is internal interpretation, not customer evidence or an instruction. |
There are
four interviews from four people and four accounts, not independent interview-plus-ticket participants (C0.2). The five support records reduce to four nonduplicate support cases, after treating S2 as a duplicate follow-up to S1, across four support accounts: Aster, Cedar, Drift and Elm (S0.1; S1–S5). This is record-level deduplication within the supplied export, not proof of distinct incident/task counts or prevalence. Three support accounts overlap the interviews; the combined packet contains five distinct named accounts, with no fifth known participant to add for Elm. Repeated sources strengthen traceability, not sample size.
Traceable finding ledger
| Finding / bounded claim | Supporting evidence and type | Counterevidence, uncertainty and alternative explanation | Confidence / decision implication |
|---|---|---|---|
| F1 — Ownership/acceptance uncertainty is a concrete obstacle in two interviewed accounts. | I1.1 reported uncertainty about whether an assignee saw a handoff; I1.2 exact quote: “I do not need another ping. I need to know who has picked it up.” I3.1 reported East/West disagreement; I3.2 exact quote: “We had reminders, but nobody knew whose turn it was.” S1/S2 and S3 are overlapping support paraphrases of acceptance-status requests. | P4 says ownership is clear (I4.2), and I4.1 verifies visible acceptance only in a scripted test context. P2's ownership need was not elicited (I2.2). Existing fields may be hidden, unavailable, misunderstood, or insufficient for transfers; notes cannot distinguish these causes (N1.1). | Moderate for these two reported contexts; no causal or population claim. Prioritize observing real handoffs and field availability before designing new fields. |
| F2 — Reminder requests differ by responsible person, timing and format; they do not establish demand for broad automatic escalation. | P2's exact I2.3 wording: “Please do not message everyone every time. I am usually the one who needs the reminder.” P3 requests an unresolved-job digest (I3.2). P4 requests a dispatcher reminder after a customer reschedule, not automatic customer messages (I4.3; S4 support paraphrase). | P2's initial positive answer was led by a suggested feature, without a concrete failure (I2.1). P1 explicitly rejects another ping in the ownership context (I1.2). Urgent interruption is a reported concern (I4.3); P1 still phones for urgency (I1.3). No frequency, delivery logs or escalation policy is supplied. | Moderate for heterogeneous reported preferences; low for reminder effectiveness. Preserve a targeted reminder hypothesis rather than treating all requests as support for automatic escalation. |
| F3 — Multi-site accounts do not show a uniform ownership failure. | Cedar's transfer disagreement is a reported episode (I3.1–I3.2). Drift's test board shows a named assignee and acceptance timestamp, an observed behavior in one test (I4.1). | Drift identifies customer access/appointment changes as the wait, not unclear ownership (I4.2–I4.3). Different configuration, plan, process, transfer path or delay type could explain the contrast; none is verified. | High that the supplied multi-site evidence is mixed; low on why. Select contrasting transfer/context cases rather than claiming multi-site prevalence. |
| F4 — Ownership-field absence and reminder-delivery failure remain unresolved explanations. | N1.1 says assignee/acceptance fields reportedly exist but availability is unchecked. S3 paraphrases that nobody receives reminders. | I3.2 says reminders existed, conflicting with an interpretation that reminders were absent. Neither delivery logs nor settings were inspected; the statements may refer to different times, recipients or reminder types. P4's test cannot prove universal availability. | Low on the actual product failure mechanism. Verify entitlements, field visibility and the disputed handoff timeline under separately authorized access. |
| F5 — Neither ticket closure nor a suggested workaround proves resolution. | S1 lacks a resolution; S4 offers a saved filter without customer confirmation. S5 contains a nonspecific agent summary of handoff confusion and was automatically closed after no reply. | Missing follow-up is not observed dissatisfaction or satisfaction. Elm's person, segment, task and underlying need are unknown. | High that resolution evidence is absent, not that every request is unresolved. Keep these cases unverified; do not count closure as a solved outcome. |
The two ownership reports are
two of four interviewed account leads describing the issue, not 50% of customers or two independent reports plus three additional support participants. The denominator is the full supplied interview set; question coverage is uneven, so the count is descriptive only. No severity ranking by frequency or delayed-job volume is possible.
Small-team versus multi-site comparison
| Cut | Small teams — two interviewed account leads | Multi-site — two interviewed account leads | What this comparison can support |
|---|---|---|---|
| Ownership | P1 reports unseen/unknown pickup in chat (I1.1–I1.2). P2 reports phone confirmations and satisfaction; ownership visibility was not asked (I2.2). | P3 reports cross-site responsibility disagreement (I3.1–I3.2). P4 directly says ownership is clear and demonstrates it on a test job (I4.1–I4.2). | One explicit issue report in each segment. P2 is an unasked case, not a negative ownership vote; P4 is a bounded negative case. No segment difference in prevalence is established. |
| Reminder context | P1 rejects another ping for this obstacle and still phones on urgent repair (I1.2–I1.3). P2 favors an owner-specific reminder after prompting, avoiding broadcast (I2.1–I2.3). | P3 asks for a daily unresolved-job digest (I3.2). P4 wants dispatcher reminders after customer changes and flags interruption risk (I4.3). | Within-segment differences matter. “Small team versus multi-site” alone does not identify the right notification policy. |
| Observed work | No product interaction observed (I1.2, I2.3). | Only P4's requested scripted demonstration is observed; Cedar's job record was not inspected (I3.1, I4.1). | The apparent contrast may reflect source/method mix as well as behavior. It cannot establish ordinary live-work performance. |
| Support linkage | Aster has two records for one request; Birch absent from selected support export (S1–S2). | Cedar and Drift each have one selected record (S3–S4). | Absence of Birch tickets is not absence of need; overlapping ticket/interview accounts are not independent replication. Elm remains outside the segment comparison. |
Contradictions and negative evidence to retain
Cedar reminder account: I3.2 reports that reminders existed; S3's agent paraphrase says nobody receives them. Keep both. Resolve the handoff date, intended recipients, reminder type/settings and delivery evidence before labeling an instrumentation or delivery failure.
Fields exist versus clarity: N1.1 reports existing fields; P1/P3 request pickup/accepted-by visibility. Drift's test confirms one context, not every plan/transfer. Availability, visibility, semantics and adoption are competing explanations, not a verified missing-feature defect.
Drift ownership negative case: I4.2 identifies customer rescheduling/access confirmation as the wait. Clearer ownership may not address it. A targeted dispatcher reminder remains a plausible separate discovery path.
Birch prompting and silence: I2.1's positive feature response is weak demand evidence. Reported phone-confirmation satisfaction matters (I2.2), but unanswered ownership questions cannot establish no ownership problem.
Internal impact claim: N1.2's proposed “cut delays by 50%” headline has no supporting design, baseline or outcome measurement. It is excluded from conclusions; no prevalence, causal impact, revenue effect or willingness to pay is established.
Focused next two-week research plan — proposed, not executed
The target behavior is that sender and receiver can correctly identify who currently owns the work, whether the transfer has been accepted, and the next required action. Immediate likely beneficiaries are the chasing sender/coordinator and receiving team; technicians were not interviewed, so their benefit and burden remain assumptions.
Clearer ownership could add acceptance work or move chasing to the receiver. Automatic escalation could add interruptions or broadcast work without resolving responsibility, consistent with I2.3/I4.3. These are intervention risks to test, not observed effects. The key assumption to challenge is that unresolved ownership is a product-visibility/transfer problem, rather than a process agreement problem or another source of waiting.
| Proposed step | Decision-changing uncertainty and selection | Neutral observation / evidence sought | Change / proceed / stop rule |
|---|---|---|---|
| First: inspect contrasting handoffs | Select P1's small-team context, P3's cross-site transfer and P4's clear-ownership context; include sender and receiver/technician roles if separately approved. Three contexts are a proposed contrastive design, not a power calculation or sufficient sample claim. | Ask: “Show the last handoff you made or received. What told you who owned it, whether it was accepted, and what happened next?” With authorization, inspect the same job's timeline, plan/permissions and field visibility. Record self-report separately from observed state. | Continue ownership discovery if observed uncertainty persists around available/visible ownership state. Change toward process or entitlement/visibility research if the state is present but responsibility rules differ. Stop treating new ownership fields as the answer if existing state is clear and delay comes from another dependency. |
| Next: resolve the Cedar contradiction | Use the same transfer and relevant recipient/settings context; do not pool unrelated reminder anecdotes. | Clarify P3's report that reminders existed and the support paraphrase that nobody received them, including timing, recipients and reminder type. Inspect authorized configuration/delivery and acceptance timeline for that event. No new account access is implied. | Shift toward targeted reminder delivery/configuration discovery if correctly owned work repeatedly stalled because the responsible person did not receive the intended cue. Retain ownership focus if cues arrived but responsibility remained disputed. Mixed evidence can narrow the focus to the transfer boundary. |
| Last: test the reminder alternative without leading | Use a recent relevant delay from Birch and Drift if available, plus clear-owner negative cases. Include affected recipient roles rather than only account leads. | “What changed, who needed to act, how did they learn that, and what was the consequence?” First observe the current workflow. Compare narrowly framed concepts only afterward, distinguishing owner-specific reminders, digest and escalation; do not ask whether a proposed feature would help as the sole evidence. | Prioritize targeted reminder discovery if observed tasks consistently have clear ownership but missing/timed cues explain the wait. Hold escalation if recipients/trigger/policy remain unclear or proposed alerts introduce unacceptable interruption. Do not infer solution effectiveness from preference alone. |
Proposed evidence threshold for the next discovery decision: document complete sender/receiver timelines for the chosen contrasting tasks, resolve or explicitly retain the Cedar discrepancy, and identify at least one observed case that challenges the favored explanation. Proceed only with a bounded mechanism supported by those observations; if access or event reconstruction fails, report the mechanism as unverified and narrow the next question. This is a learning criterion, not statistical confidence or roadmap approval.
At the end of the two-week focus, compare whether the decisive obstacle is (a) unavailable/unclear owner or acceptance state, (b) responsibility agreement outside the UI, or (c) a missing/timed cue despite clear ownership. That result should choose the next discovery slice. Do not test both broad feature builds or claim improved delays without a separate outcome evaluation.
Decision boundary
The supplied evidence supports ownership/acceptance as the more concrete next discovery question, while retaining targeted reminder needs and clear-ownership negative cases. It does not establish customer-population prevalence, feature demand, willingness to pay, reminder delivery failure, existing-field availability, representative delay frequency, revenue impact or causal reduction in delays.
The recommendation would change toward targeted reminder discovery if observed real tasks showed clear, accessible ownership and waits driven by absent or mistimed responsible-person cues. It would change toward process/entitlement research if the ownership state exists but access or responsibility agreement is the obstacle. If both mechanisms remain plausible, narrow to one disputed transfer/task rather than declaring a broad winner.
Decision owner: product lead role supplied (C0.1); named individual unassigned.
Decision date: unknown. The two-week duration is the requested discovery scope; the sequence above is proposed. No research, recruitment, message, log access or implementation has been performed by this synthesis.
Connects securely to your tools. The creator never sees your data.
About this skill
Make the research useful for a decision
Turn supplied interview and support notes into a source register, finding ledger and segment comparison that another reader can audit. Keep the counterexamples and unanswered questions visible rather than manufacturing agreement.
What is included
A compact SKILL.md workflow, two focused references for evidence handling and research decisions, plus an original fictional raw-note packet and buyer request. The practice packet includes interviews, support records and a product note; no model answer is distributed.
What you get
A bounded decision readout with evidence locators, careful counts, contradictory findings, uncertainty and a next research step that could change the recommendation. It separates verbatim quotes from paraphrases, repeated tickets from independent people, and observed behavior from reported experience.
Where it fits
Use it when you already have notes and need synthesis before choosing what to learn next. It does not create a PRFAQ, competitor comparison, research recruitment system or automated account connector. Supply your own authorized material and the decision it should inform.
Demonstrated scope
An independent Codex run completed the packaged fictional request and produced the complete synthesis shown below. It retained negative evidence, uneven question coverage, duplicated support records and unresolved contradictions. This validates a bounded supplied-context exercise, not representative research performance. No real interviews, customer outcomes, prevalence estimates, causal effects or connected-service compatibility are claimed.
How to use
Skills on Agensi run inside your AI agent. Copy the prompt, paste it into your agent, and it connects to Agensi and installs this skill for you. If a payment is needed, your agent shows it to you first.
Reviews
No reviews yet
Be one of the first to try it. Every listed skill passes our trust checks below.
Security scanned
Passed our 8-point scan before listing
Fresh listing
Recently published to Agensi
Money-back guarantee
Doesn't do what its page promises? You get your money back.
Trust & safety
Security scanned
Verified clean 6 days ago
- Passed all security checks, Safe to install