BURKI ASSISTANT COPY REVIEW WORKSHEET
Prepared October 12, 2026. Free manual resource, not an automated audit.
Original guide: https://burki.dev/blog/duplicate-burki-voice-assistant

PURPOSE
Reuse a standalone assistant's saved configuration while checking which facts,
dependencies and permissions belong to the new desk. Duplicate creates a new
persistent assistant immediately; it is not an unsaved preview. This worksheet
does not create a copy, change settings or verify a voice call.

No production assistant was copied or called to prepare the fictional example.
Use only information approved for the intended organization and assistant.
Do not paste provider keys, passwords or private customer records into this file.

1. INTENT AND IDENTITY
Review owner:
Organization/account:
Source assistant name and ID:
Source is standalone, not Guided/builder runtime: yes / no / unknown
Reason to copy:
Facts or conversation habits to preserve:
Facts/configuration the new assistant should not receive:
Would a smaller approved baseline or manual setup be more suitable?

Creation intentionally authorized by:
Creation result and time:
New assistant name and ID:
If the result was unclear, list checked for an existing copy before retry: yes / no
Unexpected additional copies found:

2. COPY MAP
For each row record the observed copied value, intended target and review result.
Do not assume a blank means not applicable; use unknown when it was not inspected.

Assistant name:
Instructions and greeting:
Business name, hours, timezone and holiday exceptions:
Contact process and any callback/booking promise:
Voice mode, model, voice and speech-recognition language:
Active status (can copy; do not assume inactive):
Dedicated assistant API-key override block (reset; organization keys may apply):
Other provider/JSON/custom settings (no blanket inline-secret redaction promise):
Webhook, transfer, messaging and post-call destinations:
Spam scenarios and selected-mode support:
Non-native/shared tool assignments and custom configuration:
Native integration actions requiring explicit installation:
Required Knowledge documents and actual processing states:
Phone numbers/routing to arrange separately:
Source call/history review kept separately when appropriate:

Copy boundaries: assigned phones, Knowledge documents, call history and settings
history are not copied. Native integration assignments are skipped. Other tools
and JSON configuration can carry over. A copied reference may still point to a
shared organization tool; changing the shared tool is separate work.

3. FICTIONAL WORKED REVIEW
Source: North Desk. Target: South Desk.
Preserve: direct public answers, one question at a time, latest caller correction.
Replace: North weekday closing time 17:00 with approved South time 16:00.
Review: North request endpoint still present after the name/instructions change.
Missing: source Knowledge documents are not attached to South.
Provider: copied model setting has not established credentials/funding readiness.

Correct status:
- Copy created: yes in this hypothetical example.
- Branch text updated: yes in this hypothetical example.
- Correct request destination: not yet verified.
- Knowledge/provider prerequisites: incomplete.
- South telephone/business-action acceptance: not established.

Do not write that a production copy was created from this planning example.

4. PUBLICATION AND LIVE DEPENDENCIES
Actual Publish -> Published version status:
Unpublished / published version number / legacy live settings / unavailable
Read at:
Unsaved edits:
Saved settings revision:
Assigned actions reviewed:
Intended phone assignment and actual route:
Knowledge/provider/calendar dependencies that remain live:

An unpublished assistant needs intentional saving, review and appropriate
authorized checks before Publish assistant and real calls. A published
assistant's saved edits remain drafts until Publish saved changes. Legacy live
settings means saving currently changes connected calls. Do not assume every
copy is inactive or unpublished. Publishing alone does not verify the phone.

5. EXPECTED VERSUS OBSERVED ACCEPTANCE
No tests were run for this worksheet. Write expected results before running any
separately authorized test. Keep text review, browser audio and telephone proof
separate. Leave observations unknown rather than borrowing source-assistant proof.

Case A: Ask South's weekday closing time.
Expected: approved South hours and timezone, not North's.
Observed response:
Evidence:

Case B: Caller changes North to South.
Expected: latest desk correction retained and approved South facts used.
Observed response:
Evidence:

Case C: Question requires a document absent from the copy.
Expected: honest uncertainty and approved staff process.
Observed response:
Evidence:

Case D: Caller asks for a request/booking/callback.
Expected: actual supported confirming result, or clear statement it was not done.
Observed action/result:
Destination receipt, if applicable:
Evidence:

Case E: Review copied custom destination/shared tool.
Expected: intended target and permissions independently reviewed.
Observed configuration:
Acceptance evidence:

Case F: Real telephone use.
Expected: correct assistant/publication, actual phone route and authorized call proof.
Observed route and result:
Evidence:

6. COSTS AND DECISION
The copy operation does not start a voice conversation or send a message. It does
not establish a free-plan entitlement. Later platform/model/voice/carrier usage
and number rental can cost money. Review the actual account allowance and
https://burki.dev/pricing before any separately authorized test or production use.

Open blockers:
Owner for each blocker:
Review decision and scope:
Approved next action:
What has actually been verified:
What remains unknown: