FDE01Forward deployment
Course 02

Start working with the customer

What should you agree on at the first meeting?

On this pageBy the end of this lessonBefore you beginTurn information needs into access you can arrangeExplain what records are for instead of requesting everythingMake sure participants understand what they are agreeing toPrepare the first working meeting step by stepDiscuss the six-week date together with scopeWhen access is withdrawn, revise the research and decisionGive updates and escalation a clear purposePractice the methodCheck your understandingYour record and next stepReferences

By the end of this lesson

  • State the research purpose, permitted records and participants, and permissions still missing.
  • Prepare a clear participant explanation and a first-meeting agenda.
  • Offer workable choices when deadlines or access change, with an update and escalation arrangement.

Before you begin

  • Bring your responsibility note and next-step plan from Lesson 1. Mark the actions that require customer permission.
  • Read Beichen's engagement scenario: a six-week date is in the contract, the team has not met frontline staff, and the data owner withdraws access to raw tickets because the purpose is unclear.

Read the Beichen case and introductory data

Two perspectives on the same delivery
Two perspectives on the same deliveryDiscovery explains the business and users; engineering checks feasibility. Share evidence and trade-offs so an authorized customer owner can decide.Business discoveryEcho · needs / use / valueEngineering deliveryDelta · build / test / operateShared delivery decisionEvidence & trade-offsAuthorized customer owner
Discovery explains the business and users; engineering checks feasibility. Share evidence and trade-offs so an authorized customer owner can decide.Swipe to view the full diagram.

Turn information needs into access you can arrange

Lesson 1 identified people to meet and information to obtain. Now make that possible: who contacts participants, which shifts can be observed, which records can be read and whom to contact when arrangements change. A supportive email can help, but it does not replace these details. Label unconfirmed arrangements as pending rather than making a schedule look settled.

State the decision the research supports, such as identifying East China day-shift incident tasks suitable for a limited pilot. Work backward from that decision to the access needed. Understanding task steps may not require customer names or full incident narratives. Specific activities make it easier for data and operations owners to approve access or offer alternatives.

The working agreement can fit on one page and link to the customer's existing approval process. Include the purpose, allowed and excluded activities, contacts, update times and how changes are handled. It checks shared understanding; it does not replace a contract, formal access approval or applicable organizational rules.

Explain what records are for instead of requesting everything

Connect every requested field to a research question. To investigate specialist waiting, you may need an event identifier, request and response times, and the escalation route. If individual performance is outside the study, do not add names and rankings for convenience. Ask the data owner about ambiguous fields, including timestamp boundaries and the meaning of empty values versus zero.

Also explain who can access the records, where they will be stored, when retention will be reviewed and how they will be deleted. Check whether supposedly anonymized records still identify someone through equipment, timing or an unusual incident. GOV.UK's research-data guidance offers practical ideas for collecting less and controlling sharing. Customer specialists must confirm the applicable legal basis, retention requirements and employee-data rules; foreign guidance is not a local compliance conclusion.

Vague requestA request that can be checkedStill to confirm
Give us all the ticketsRequest fields needed to analyze specialist waitsField definitions and permitted scope
Only our team will use themName permitted roles and the storage locationContractors, exports and backups
Delete them afterwardAgree a retention-review point and deletion ownerHow copies are deleted and execution recorded
Interviews will not affect staffExclude performance data and identifiable quotationsUnderstanding of purpose and withdrawal

Make sure participants understand what they are agreeing to

Customer permission to run research does not mean every employee understands or agrees to an interview. Before starting, explain who you are, which work you want to understand, whether recording is involved, who will see the notes and how participation can stop. Say that the study is not an individual performance review only if the actual sharing arrangements support that statement.

Suppose an employee worries that their manager will see their exact words. Clarify whether the concern is identity, content or performance consequences, then explain the current arrangement. If anonymous sharing has not been agreed, say so and avoid recording identifiable material for now. Do not promise absolute anonymity to keep the interview moving. A role, shift or unusual incident may identify a speaker even without a name.

GOV.UK's informed-consent guidance emphasizes understanding the purpose, recording and voluntary participation. Use it to check your explanation rather than copying its terms. Requirements vary by jurisdiction and organization; customer privacy or legal specialists should review the arrangement where needed. For self-study, the synthetic materials are enough. You do not need to recruit employees or collect personal records.

Prepare the first working meeting step by step

Bring the responsibility note from Lesson 1 and list what this meeting must establish, rather than beginning with product features. Beichen lacks frontline and operations input and an explicit data purpose. The business owner can explain the desired result, while the appropriate owners must confirm access and support. Record actions for absent people instead of answering on their behalf.

The following hypothetical meeting sequence can serve as your agenda. Put facts and pending issues on the table, offer at least two workable paths, and finish with named actions. Check how business, data and operations participants each understand the scope. Where their accounts differ, preserve the difference and arrange confirmation; do not summarize it as unanimous agreement.

  • Step 1: restate the purpose: 'We are locating delays in day-shift incident work; a rollout to everyone has not been approved.'
  • Step 2: check records and participants: permitted fields, who arranges user access, and who confirms operational limits.
  • Step 3: compare options: approved record analysis with interviews, or an initial redacted summary followed by a decision about raw records. Explain the different information limits.
  • Step 4: confirm allowed and prohibited actions. Record pending permissions with their owners.
  • Step 5: agree the next update and scope review. Check that participants can explain exactly what has been approved.

Discuss the six-week date together with scope

In Beichen's published scenario, the contract contains a six-week date while field research remains unarranged. Inspect the contract and earlier records to distinguish existing obligations, expectations and unverified assumptions. You cannot independently change contractual obligations or interpret 'launch in six weeks' as evidence that every feature is ready. Changes require confirmation by those authorized to handle the contract and scope.

Prepare three choices: retain the date with narrower permitted scope, retain the target scope with staged delivery, or obtain critical information before confirming a feasible plan. A recommendations-only trial for a few day-shift tasks is a hypothetical option, not an approved Beichen arrangement. Explain what each option preserves, delays and still needs to establish.

A pilot still needs supporting evidence, safety limits and operational preparation. Redefining the milestone as a demonstration or shadow test must make clear that it does not establish production readiness. In a shadow test, the system produces suggestions without changing the actual workflow, allowing comparison of outputs. It still requires data permission and does not remove access or usage restrictions.

When access is withdrawn, revise the research and decision

The data owner's withdrawal of raw-ticket access because no purpose statement exists is part of Beichen's published scenario. Stop activities that depend on that permission. Confirm whether retained records may still be used and how they should be handled. Do not switch accounts or ask the sponsor to bypass the restriction. Identify whether the gap concerns purpose, fields, storage or another approval, then address it.

Alternatives include analysis by authorized staff inside the customer environment, redacted fields or workflow observation without raw records. Each still needs permission. Each also loses information: summaries may hide exceptions, while missing narratives may prevent checking labels. Include those limits in findings so the business owner understands which decisions remain unsupported.

Update the plan: can the activity continue, what information will be missing, and who must reconfirm scope? Trust grows through honest handling of change and reliable, controllable actions, not obtaining every record. Similarly, keep support pending until the operations owner confirms it. Business support does not substitute for operational preparation.

Give updates and escalation a clear purpose

You do not need many meetings for every role. Agree suitable routes for routine updates, scope decisions and urgent issues. Routine updates state confirmed findings, the next action and the next update time. A decision request presents options, costs and the decision-maker. When possible harm or unauthorized use appears, follow the established protective procedure and notify the appropriate owner.

A common mistake is treating 'as soon as possible' or 'stay in touch' as an arrangement. Add owners and times without guaranteeing an unverified repair date. Another is interpreting access restrictions as a difficult personality. Record the person's actual requirement and the next action. For example: 'Raw-ticket access is paused. We will supply the field and purpose description today; until approval, we will use only the existing synthetic practice material.' This helps everyone understand how to proceed.

Practice the method

Exercise 02

Draft a one-page working agreement for Beichen, then test it against the access-withdrawal scenario. Do not fill in approval or signatures on the customer's behalf.

  1. 01

    State the decision the research supports in one sentence, keeping the recommendations-and-drafts-only limit explicit.

  2. 02

    List up to five access requests. Give each a purpose, fields or participants, permission owner and pending details.

  3. 03

    Write an interview introduction covering recording, purpose, visibility and how to stop participating.

  4. 04

    Offer two substantively different scope options for the six-week date. Mark what needs contractual or business confirmation.

  5. 05

    Assume raw-ticket access is withdrawn. Revise the method and state what the replacement records cannot establish.

  6. 06

    Read the agreement from the customer's perspective: what have I agreed to, what remains unapproved, when is the next update, and whom do I contact? Fill the gaps.

Check your understanding

Write your answer before opening the explanation, then check what you might have missed.

Why involve data and operations owners if the business owner supports the project?

Business priority, data use and operational support are different responsibilities. Check actual delegated authority so one person's approval is not extended to matters they cannot authorize.

Can you switch straight to aggregated data when raw-record access is withdrawn?

Confirm that aggregated data is permitted and check how retained records must be handled. The alternative still needs approval, and its information limits must be stated.

Must research stop completely if a participant declines recording?

Discuss an acceptable method, such as brief notes with agreement. Avoiding audio does not remove consent or purpose requirements. If no acceptable way to collect the material exists, do not collect it.

Your record and next step

A one-page agreement covering goals, access, responsibilities and communication.

For each permission, record who approved it, its purpose and its limits. Make promised outcomes and dates easy to find, and distinguish them from matters still to be agreed.

Take the working agreement, permitted access, pending questions and update times into Lesson 3. They determine the research methods available; a research plan must not silently expand permission.

References

GOV.UK / Getting informed consent for user research GOV.UK / Managing user research data and participant privacy GOV.UK / User research in discovery