Prepare your Apple Messages demo

Use this guide after you have built the conversation experience. The submission should let a reviewer follow a customer request, understand the choices, and see the result without needing your team to explain missing steps.

Apple reviews the complete experience in the test environment, including its language and interaction design. Its current Experience Review instructions require an iPhone screen recording submitted through your messaging provider. In Bird, you upload the evidence through the business's Approval requirements; Bird coordinates the submission to Apple.

Prepare the account, script, and test data

Connect the Apple account to Bird and register the authorized testers in Apple Business Register. You can use a connected Draft business to send test messages while preparing the demonstration. Keep public entry points unpublished until the launch approval is complete.

Complete the Readiness review and Use cases documents from Approval requirements. Use the same service hours, supported tasks, languages, and handoff arrangements in those documents and in the experience you record. Remove abandoned ideas from the submission rather than describing them as finished features.

For each use case, write a short recording script with an entry point, opening request, choices, expected result, and one relevant recovery route. For a store appointment, the result is a reservation in the booking system followed by a matching customer confirmation. A time selection alone leaves the use case unfinished.

Before recording:

Prepare fictional customers, booking references, and other records needed for the demonstration. Avoid real customer details in messages, notifications, account screens, and operator views.
Make an operator available to receive the handoff. Give them the script, but have them perform the real assignment and service actions.
Refresh time slots, links, media, and any data that could expire while you record. Verify that the test booking or order system is reachable.
Rehearse on the iPhone you will use. Test the other supported device experiences as well; Apple recommends checking macOS where possible.

Demonstrate typing indicators

Typing indicators are part of Apple's Experience Review criteria for both automated replies and live agents. Make them visible in the iPhone recording. A dashboard preview or a successful message status does not demonstrate this behavior.

Before recording the full journey:

Check the automated reply. Send a customer request from the iPhone. Record the typing indicator appearing before the automated reply arrives. Apple's conversation design standards call for a 1-second indicator before each message in a sequence. Keep the automated welcome within the separate 5-second first-response requirement.
Check a sequence of replies. Trigger a use case that sends more than one message. Show the typing indicator before each reply, including the transition from introductory text to a native interaction. Keep these transitions in the recording so the reviewer can see their actual timing.
Check the live agent. Transfer the conversation to an operator. Have them begin typing a reply in Conversations while the iPhone records the customer view. Show the typing indicator, then the operator's delivered reply. Do not substitute a prepared message sent without demonstrating live composition.
Check the complete transition. Confirm on the iPhone that the indicator leads into the intended reply. If it is missing, remains visible unexpectedly, or the reply fails, investigate the connection and message result before recording the submission again.

Bird sends a typing signal before an outgoing reply and while an operator composes in the conversation reply box. Verify the actual device behavior for the path you submit. If a connected service needs to signal that it is preparing a reply earlier, its integration owner can use the conversation typing API.

Keep the typing sequence uncut in the submitted recording. Check the exported MP4 as well as the live rehearsal; editing, sped-up playback, or clips beginning at the delivered message can hide the evidence Apple needs.

Record a complete customer journey

Use the iPhone's screen recording to capture the customer view. Keep text readable, allow time to see each message, and show taps and returned answers in sequence. Record the operator's handling as supporting evidence where it explains assignment, a booking action, or recovery. The operator recording complements the iPhone view.

For the store-visit example, record this sequence:

Enter the conversation. Show the website or app placement being tested, or the test conversation link. Open the correct business and send the customer's request. Explain in the use-case document which placement this represents.
Receive the first reply. Show the typing indicator before the reply, then the operator's introduction or the automated assistant's disclosure. For automation, preserve the actual delay between the first customer message and the welcome so the response time can be assessed.
Choose the task. Start one run with an unclear request to show triage. In another run, request a styling appointment directly and show the service using that intent.
Complete the native interaction. Show the introductory message, received bubble, opened picker, selected option, and returned answer. Keep the option labels and any summary text visible long enough to read.
Perform the business action. Have the operator or connected service make the reservation. Show the customer confirmation with the same appointment and reference. Include the corresponding booking record in the supporting operator evidence.
Offer further help. Demonstrate the next route when the customer has another question. If your experience includes a satisfaction survey, show the descriptive choices and the returned answer.
Ask for a person. In a separate run, request a person partway through the task. Show the transfer notice, any wait expectation, the live typing indicator, and the receiving operator's introduction. The operator should continue from the existing context.
Recover from a problem. Demonstrate a realistic case such as a time that is no longer available. Show the replacement choices and the eventual result, rather than stopping on an error message.

Repeat the sequence for the other submitted use cases. Also capture the closed-hours response and a customer returning to an earlier request. If you offer multiple entry points, verify each one and make their coverage identifiable in the use-case document.

Keep the evidence continuous within each use case. Avoid cuts that hide a wait, an unanswered message, a failed selection, or a manual action needed to complete the request. Short titles between scenarios can help the reviewer navigate; staged previews and narration cannot demonstrate whether the real interaction works.

Check what the reviewer will see

Watch the exported recording from beginning to end without operating the service. Use the following review passes to catch common problems. Check Apple's current checklist alongside this practical review before submission.

Opening and service expectations. Can the customer tell who is answering? Does the automated welcome arrive within 5 seconds? Does the closed-hours reply give the team's next availability and time zone? If a transfer takes time, is the stated expectation realistic?

Choices and navigation. Can a customer understand the options without knowing your team structure? Does an unclear request get a useful triage menu? Can typed requests such as “agent,” “help,” and “menu” reach the appropriate next step? Check that each branch reaches an answer, a completed action, or someone who can help.

Native message presentation. Read the received and reply bubbles as well as the expanded interaction. For interactive features with image fields, include a relevant thumbnail in both the received and reply bubbles. Check that titles, instructions, and selected answers make sense in each view. Review quick-reply summary text after selection. Verify rich links, location previews, and the alternative used when an interaction is unavailable.

Human service and asynchronous replies. Check the handoff notice, typing indicators, operator introduction, and use of the existing conversation history. Return after a pause and verify that the service can continue with current information. Remove prompts that pressure the customer to reply immediately or imply the channel is closed to further questions.

Wording and data. Use the product name Apple Messages for Business. Check spelling, long translated labels, and confirmation before a language switch. Ask for personal information when the task needs it, and check that privacy and terms links open the correct pages. Keep SMS-specific wording out of this experience.

Outcome and evidence. Match the customer confirmation against the actual booking, order, or case. Check that the documents describe the same behavior shown in the recording. If you had to explain a missing step verbally while reviewing the file, improve the experience or record the step before submitting.

Package and submit the evidence in Bird

Open Apple Messages > Businesses, select the business, and open Approval requirements.

Download the current forms and finish the Readiness review and Use cases PDFs. Make each use case identifiable by name in both the document and recording.
Export the Service demonstration as MP4. Open that exported file and check that it plays, the text is readable, and the complete ending is present. Follow the upload limits displayed by Bird.
Include a short scene index in the use-case document. For example, “Store appointment, 00:00; human handoff, 02:15; unavailable time, 03:40.” Replace these example times with the actual timestamps from your recording.
Upload the PDFs and MP4 to their matching requirements. Check the selected business and uploaded files before submitting.
Submit the completed requirements and use Submission history to follow the result. Keep the person responsible for the experience available to act on feedback.

Do not set a public launch date from the upload alone. Review feedback can require changes and another recording. Approval and the later Go Online review are separate stages of onboarding.

Respond to feedback and resubmit

Turn each review comment into a specific correction in the message content, service behavior, or supporting document. If feedback is unclear, resolve it with Bird before changing the experience. Include the service team and whoever owns the affected integration.

Rehearse the entire experience on the device, including flows that were not changed, then record the updated version. Prepare a change summary that pairs each review item with the correction and where it appears in the new recording. For example: “Handoff introduction: the receiving operator now introduces themselves and acknowledges the selected store; shown at 02:20.”

When the business status is Rejected, replace the affected evidence in Approval requirements and select Resubmit for approval. If feedback arrives while the status is Submitted or In review, contact Bird to return the submission for changes; the upload and submission controls are unavailable in those states. Ensure the uploaded documents and video describe the same final version, with the review items addressed. Continue with launch preparation once the review is approved.