Advisor playbook: execute an engagement A to Z

This playbook is the working procedure for an advisor. Use it with the Full user manual for screen-level instructions. The sequence describes a typical bounded engagement; the timing is illustrative and should be agreed with the sponsor.

A. Qualify and prepare

Before the first session, write one sentence describing the result the client wants and one sentence describing the work in scope. “Understand standard order intake through release” is useful. “Transform the entire business with AI” is too broad to guide evidence collection.

Identify the executive sponsor, day-to-day work owner, data custodian, and people who perform the work. Ask where policy, actual system permissions, process documentation and execution records live. Distinguish access to a source from authorization to change a system.

For this local build, use synthetic or otherwise approved pilot information. The operator must complete the deployment, identity, source access and retention decisions before real client collection. Record unresolved setup dependencies in the engagement plan; do not assume a form setting has enforced them.

Prepare the engagement record and collection notice. Agree what the client will receive, who will see it, the intended review cadence, and the permitted delivery channel. Establish where the final package and distribution log will be stored.

Research public context before the meeting. Use Business research with operator-configured Exa, or capture public pages manually. Start with the official website, then inspect appropriate public sources for the offer, customers, footprint, people and recent changes. Keep source URLs and dates. Do not scrape private interviews into a public search query. Draft a short account with Known, Inferred, Assumed and Missing information distinguished; public leadership listings do not establish internal accountability.

Bring that draft to kickoff. Ask the team to correct it explicitly: “Here is what we found publicly. What is wrong, outdated or missing?” Preserve both the original public claim and the team's correction with their own origins. Treat suspected bottlenecks and inferred process steps as questions until evidence supports them. The current release collects sources through Exa but does not generate this synthesis with an AI model.

Exit evidence: reviewed scope; named sponsor and work owner; roster plan; source/visibility policy; exclusions; first review date; agreed deliverable audience.

B. Run a bounded kickoff

Use four or five kickoff questions. Ask for a recent example, not only a general process description. Listen for the completed output, the business value of that output, demand conditions, places work waits, and decisions that require escalation.

Suggested opening: “We will first document how this work happens, then ask the people involved to check the description. We will test an explanation for delay before recommending a change. This interview does not grant system access or authorize automation.”

Record the sponsor’s preferred explanation as a hypothesis. Ask what evidence would show that another explanation is stronger. Name the output unit—released orders, accepted jobs, fulfilled requests—so later analysis concerns system results.

Create follow-up requests only where information is missing. Avoid asking every person every possible question. Preserve the exact request and original response. After acceptance, cite the source as an account from that participant, with an exact locator.

Exit evidence: a recorded kickoff account; explicit output measure or missing-baseline reason; initial flow boundary; competing explanation; prioritized evidence questions.

C. Collect and assess evidence

Collect at least one concrete work walkthrough from someone who performs the work. Ask them to trace a recent item from trigger to output, including waiting, returns, workarounds, and handoffs. Ask the owner separately about exceptions and acceptance criteria.

Inspect documentary and execution sources where permitted. A policy describes intended rules; an execution record shows an observation; an employee account explains experience. Keep these types separate. Record exact source locations and independent origins. Repeated copies of a single document do not strengthen source independence.

When accounts conflict, preserve the conflict and identify the discriminating evidence. Example: one team says “approved” when another means “verified.” Ask what decision was taken, by whom, under which source, and what the receiving team expects.

Accept reviewed sources; keep uncertainty in the interpretation. Retract unusable sources with reasons and inspect the dependent stale records. Use the source policy when deciding what text can be included in any client-facing summary.

Exit evidence: a source register with origins and locators; named gaps and conflicts; sufficient information to draft concrete task cards. Unknown information stays unknown.

D. Build the work record

Write one task per bounded trigger-to-output unit. Use verbs and observable outputs. “Manage procurement” is a duty; “Check that the supplier packet contains a tax form and bank verification reference” is a task.

For each task, name one accountable owner and the performer, describe inputs/instructions/output, identify systems, state human checkpoints, and list denied actions and stop conditions. Select sources and a review date. Save incomplete proposals when necessary, then resolve the missing owner or evidence before review.

Group tasks with a duty label. Create an explicit duty record when responsibility for that continuing area needs review. Define each handoff’s receiving condition, input/output mapping, exception owner and failure handling. A receiving check is more useful than an unlabeled arrow.

Inspect the company graph. Read the selected relationship labels aloud. Use By team to check coverage and Reporting chart to check recorded managers. Do not infer a manager from seniority, job title or task ownership.

Exit evidence: reviewed task definitions; an explicit list of remaining conflicts; meaningful receiving checks; no unexplained orphan work.

E. Confirm with the people

Issue confirmation requests only after the task text is ready. Ask participants to review the exact current version and explain disagreements. Ensure that local account and invitation assurance match the training or pilot context; stronger real-client assurance is an operator dependency.

Review returned decisions. Correct responses count only after acceptance and only for the exact version/hash. Needs change, Not mine, and Unsure are valuable results. Resolve the issue, revise, and ask again. Do not change a participant’s response to improve the dashboard.

Explain to the client that “Human confirmed” means the relevant people accepted the described work. It does not mean a policy owner approved a permission grant, that a duty is fully confirmed, or that the task can run autonomously.

Exit evidence: current confirmation coverage; an exclusion list for unconfirmed/stale tasks; participant disagreement preserved in history.

F. Test what limits progress

Define the system output and a plausible limiting mechanism. Record a leading alternative. Build a discriminator capable of separating them. For example, compare how much time orders spend waiting for intake corrections with time waiting for credit review, in comparable cohorts.

Define metrics before interpreting results: formula, unit, cohort, source, owner, window, baseline, target, missing-data reason and guardrail. Use null for a missing baseline. Do not substitute an estimate into a measured-baseline field without explaining its source and limitations.

Use framework analyses where they clarify the question. Write evidence-bound analysis and review prerequisites. The current product supports human-authored work; it does not supply autonomous diagnosis. Structural readiness checks are a floor, not evidence that the test is well designed.

Exit evidence: a testable hypothesis, alternative, discriminator, defined metric, and sufficient independent sources—or an explicit collection plan for what is missing.

G. Plan a bounded intervention

Choose a small change that addresses the proposed mechanism. Name the accountable owner, prediction, measurement, stop conditions, and review date. Preserve the original prediction before collecting the result. Write what would lead you to stop, reverse or revise the intervention.

If assistance is being considered, create an agent proposal tied to exact work versions. Keep requested, approved, provisioned and observed scopes separate. Current export packages are drafts for review. Customer authority and live execution remain a separately configured and accepted integration.

Create a manual workflow only when task and handoff descriptions are current. Review its sequence and branch rules. A manual case can record what a human observed; it cannot verify an external action on its own.

Exit evidence: intervention record, preserved prediction, owner, observation plan, guardrails, reviewed workflow where useful, and explicit deployment boundaries.

H. Observe, review and learn

Record observations with time and locator. Track manual case progress, failures and bounded retries. Inspect expired deadlines and stale workflow bindings. The advisor must arrange follow-up outside the application because this version does not send reminders or escalations.

At the weekly review, begin with changed evidence and unfinished commitments. Compare the prediction with actual observations. Ask about population changes, staffing, product mix, seasonality, concurrent changes, and other confounders. Avoid declaring causation from a before/after difference alone.

Write an outcome review. Supported, Falsified and Inconclusive are distinct judgments. A missed target with poor measurement coverage may be inconclusive; a credible discriminating observation can falsify the proposed mechanism. Preserve the frozen prediction and measurement snapshot. Reviewing a falsified outcome returns the hypothesis to review.

Exit evidence: dated observations, outcome interpretation with limits, decision/owner/next action, and next review date.

I. Prepare and deliver the client record

Choose a report for its audience. An executive report emphasizes the decision and next action. A weekly report emphasizes changes, observations and commitments. An audit report identifies the application activity actually covered. Internal work and agent packets belong with implementation reviewers.

Select records deliberately. Write the summary in plain language: scope, what was learned, supporting observations, competing explanation, decision, next action, and limitations. Avoid unsupported claims of efficiency gains, complete coverage, verified authority, or successful deployment.

Preview the exact frozen report. Check names, dates, states, source locators, exclusions, audience, and unnecessary sensitive material. Record the review rationale. Download only when the current bindings pass. If evidence changes, regenerate and review a fresh report.

Deliver manually through the agreed channel. Record which version went to whom and when in your distribution log. Give the client a readable report and offer the structured register where it helps. Keep checksums with the original package.

Exit evidence: approved packet; delivery record; named owners and due dates; known limitations; agreed next engagement step.

J. Close or hand over

Review open commitments and sources due for refresh. Name the continuing record owner. Explain how later changes invalidate confirmations or reports. Provide the client-facing material and the appropriate operator or implementation handoff separately.

Have the operator verify backup and restoration for the installation. Follow the engagement’s approved retention and distribution policy; this pilot does not implement comprehensive client erasure or legal hold. Record unresolved infrastructure or integration decisions in the technical backlog.

An engagement is ready to close when its agreed questions are answered or explicitly bounded, its outputs are reviewed and delivered, and each remaining action has an owner. A visually complete graph is not a substitute for those conditions.

Suggested cadence

These are facilitation suggestions, not service-level or delivery-time promises. Adjust the cadence to evidence availability and the agreed scope.