Six customer interviews are finished, but the product team has three competing feature requests and no shared explanation of what participants actually struggled with. An AI workspace for customer interview synthesis can organize approved notes into traceable observations, competing interpretations, and a decision brief. Manor is a strong fit when that job needs an independent goal, persistent context, tasks, reusable skills, connected tools, approvals, and visible deliverables across research rounds.
We are the Manor AI team, writing from our product perspective. The product team and interview examples below are invented to explain a proposed workflow. They are not customer testimonials or research findings. This method assumes approved, appropriately anonymized notes and tools available in your account; it does not assume a native interview-recording integration or automated research expertise.
Start with a decision the research can inform
Imagine a small software company deciding whether to improve its existing report export or prototype scheduled delivery. Sales wants scheduled email reports. Support hears that users cannot find the export button. A founder has highlighted one enthusiastic request. The research job is to explain the workflows behind those statements before the team chooses its next experiment.
Give the workspace one outcome: prepare a reviewed decision brief for the report-sharing discovery round. Record the research question, participant selection criteria, interview guide, source cutoff, and named research owner. Define completion as a brief with sourced observations, counterevidence, unanswered questions, and proposed next steps. A list of popular feature names does not meet that acceptance test.
Keep adjacent jobs separate. Sales follow-up, support resolution, and product delivery have different goals and permissions. Their approved context may inform the research, but an interview request should not quietly become a roadmap commitment. The workspace prepares material for a product decision; the product owner remains responsible for making it.
Build an AI workspace for customer interview synthesis around evidence
Begin with the approved guide, anonymized interview notes, participant labels, relevant product context, and earlier research decisions. For each interview, register its date, participant segment, source file and version, note completeness, and any known limits on use. Use labels such as P01 instead of names when identity is unnecessary. Keep the identity key outside the synthesis inputs.
Separate direct quotations from a note-taker's paraphrases. If the source says “roughly remembers that exporting was awkward,” the output must not turn that into an exact quotation. Mark gaps in the notes. A missing passage does not prove the participant had no difficulty, and a summary created from an unavailable recording should retain that limitation.
Manor's AI business workspace keeps a recurring job connected to its sources, previous outputs, and owner feedback. For research, the useful carryover is the question, the current coding rules, unresolved disagreements, and the reasoning behind earlier decisions. Preserve dated rounds so a newly observed problem does not silently rewrite what an earlier participant said.
Use only authorized document or research tools available in your account. Importing an approved export manually is a valid starting point. Connect the smallest necessary source set, and check permissions before adding recordings or personal details. The synthesis task does not need access to a participant's entire customer record or unrelated conversations.
Separate observations, interpretations, and proposed actions
In our invented example, P01 describes downloading a report every Friday and forwarding it to a manager. P02 describes struggling to locate the export control during onboarding. P03 wants scheduled delivery but says an assistant currently handles the forwarding. These observations point to different problems: repeated work, discoverability, and delegated work. They do not yet establish which product change deserves priority.
Create an evidence record for each observation: participant label, source passage or note section, relevant workflow, context, and limitations. Then create separate interpretation fields. “Report sharing includes repeated manual forwarding” is a proposed theme supported by P01. “Everyone needs scheduled delivery” is an unsupported expansion. Ask the agent to retain the narrower statement and list what additional evidence would change it.
Use knowledge citations to make the source behind a theme inspectable. A reviewer should be able to open the passage that supports it. Citations help traceability; they do not prove that a paraphrase is accurate, that the sample represents the market, or that an interpretation is correct. The research owner checks those questions directly.
Count distinct participants only when the underlying notes support the count, and show the relevant denominator and segment. Repeated mentions within one interview are still one participant's evidence. A small, selectively recruited discovery round should not become a market percentage. Preserve contradictory examples beside each theme instead of burying them in an appendix that nobody reads.
Turn disagreement into tasks and a reusable method
Give separate tasks to source preparation, observation extraction, theme comparison, and brief preparation. Each task needs a reviewable output. Source preparation produces the registered input set. Extraction produces observations linked to passages. Comparison produces themes, supporting cases, exceptions, and alternative explanations. Brief preparation produces options and open questions rather than an automatically selected roadmap.
If the notes disagree about whether exporting is hard to find, assign an owned follow-up: “Research owner to compare the onboarding paths described by P02 and P04 before Friday's review.” Include the two references, the uncertainty, and what would count as resolution. The right next step may be a targeted usability session or a better interview question, not another generated summary.
Create a reusable AI skill for the repeated analysis method. Define the difference between an observation, an interpretation, and a recommendation; require passage references; distinguish quotations from paraphrases; preserve counterexamples; and flag unsupported counts. Keep the current findings in the round's evidence, not inside permanent instructions that could bias the next round.
Proposed task instruction: Using the registered, anonymized notes for the report-sharing round, prepare an evidence table and draft decision brief. For every theme, show supporting passages, exceptions, and an alternative explanation. Flag incomplete notes and missing evidence. Suggest follow-up questions. Do not contact participants, alter customer records, or promise product changes.
This is a configuration example, not a built-in research skill. Instructions guide the analysis; actual tool permissions and approval settings control available actions. During the pilot, keep external tools disconnected or use draft-only access if the available connection cannot enforce the intended boundary. Have the research owner test whether the output preserves uncertainty before reusing the method.
Review the evidence before accepting the recommendation
The review package should contain the research question, source cutoff, participant selection summary, observation table, proposed themes, counterexamples, limitations, and decision options. Give the brief a version identifier and a named reviewer. Include links to the source passages and a clear distinction between evidence from this round and context imported from earlier work.
Use configured approval gates and activity history to keep preparation and review visible. Approval of an internal research brief does not authorize emailing participants, publishing quotes, changing a customer record, or committing to a release date. Keep those as separate actions with the appropriate owner. If someone adds a new interview after review, show what changed and review affected themes again.
The owner can accept the brief while rejecting its preferred option. For example, the team might choose a discoverability experiment first because the current evidence is clearer, while retaining scheduled delivery as a hypothesis needing follow-up. Record the decision, rationale, uncertainty, and next learning task. That gives the following research round useful context without pretending the decision proved the hypothesis.
Before accepting a brief, check five things:
- Every material theme points to specific passages, with quotations and paraphrases labeled correctly.
- Counts refer to distinct participants and disclose the relevant source set.
- Counterexamples and incomplete notes remain visible alongside the conclusions they limit.
- Each recommendation explains its reasoning and names evidence that could change it.
- Follow-ups have owners, and external actions require their own review.
Judge Manor by the quality of the next decision brief
Manor is a strong choice for this job when research repeats, several sources need comparison, unresolved questions need tasks, and reviewer feedback should shape later rounds. Those are explicit fit criteria, not an independent ranking. A document may be sufficient for a single interview. A dedicated research repository may suit teams that need specialized transcription, coding, recruitment, or research governance features; verify those requirements separately.
Pilot one narrow question across two research rounds with the same owner. Record whether reviewers can trace each theme, how often extraction changes after source checking, which counterexamples were missed, and whether follow-up tasks resolve the stated uncertainty. These are proposed evaluation measures, not Manor benchmarks or promises of better commercial outcomes. Narrow the input set if checking the synthesis becomes harder than reading the notes.
Our unified knowledge base guide explains the source-management foundation. Check the Manor FAQ, then create a Manor workspace with one research question, a few approved notes, and a named reviewer. Ask for an evidence table and a brief you can challenge before asking for a product recommendation.