Navaura Claims Intake — full walkthrough · 5:42 Fictional scenario. Actual application captures and Nia response, edited for length. Narrator and caller voices are AI-generated. Intake review does not determine coverage, liability or payment. 0:00 — The complete workflow A claim starts with a story. Turning that story into a useful record takes clear questions, accurate details, and a next step people can follow. This is Navaura Claims Intake. In this extended walkthrough, we’ll follow one fictional personal auto claim from the first conversation through review and service team acceptance. 0:19 — Start with the right claim Start by choosing the type of claim. Here, we select personal auto. The workspace brings the request details and Nia, the intake assistant, into one view. As the conversation progresses, the saved record stays visible. The person handling intake can see what has been captured and what still needs attention. 0:38 — An actual voice exchange The reporter can begin in their own words. Nia follows up to turn that account into specific claim details. Here is an actual exchange from this demonstration, with pauses shortened. Listen to how Nia handles the word today. Reporter: I backed into a parked car today. There is a dent in my rear bumper. Nia: I’ll use October 18, 2026 for today. Is that the correct loss date, or do you want to use a different date? Reporter: Yes. Nia: Thanks, got it. What is the insured person’s name? 1:14 — Confirm the loss date Nia proposes a calendar date and asks the reporter to confirm it. Once confirmed, that date becomes part of the saved request, and the conversation moves on. This small exchange makes the meaning of today explicit, so the reviewer has a specific loss date to work with. 1:32 — Keep reported details visible Next, the intake captures the people and policy information. Avery Morgan is the insured person and driver in this fictional example. Jordan Taylor is the reporter. The policy number, carrier, and policy dates are recorded as reported details. The workspace labels them as manually entered; this demonstration does not perform a carrier policy lookup. 1:55 — Confirm the loss location For the loss location, Nia presents an address match for confirmation. The person handling intake selects the matching address before it is saved. That leaves the request with a precise location, including the city, state, and postal code. The conversation and the structured record remain together while the details are confirmed. 2:16 — Switch to text and correct The conversation can continue in text when that is more convenient. Here, the reporter corrects the loss time from 2:30 to 2:45 in the afternoon. The correction is saved to the same request. We can see the updated time in the claim details before the request moves forward. 2:36 — Handle unknown details The remaining questions capture the vehicle and circumstances of the loss. In this example, the vehicle is drivable, and no injuries, police involvement, or airbag deployment are reported. The vehicle identification number is unknown. Because that field is optional here, intake can continue, with the missing VIN left for follow-up. 2:57 — Add supporting evidence Supporting evidence stays with the request. We add a clearly labeled sample photo showing the reported bumper damage. The file finishes its upload and safety check, and the original remains available from the claim. The image also appears in the generated PDF, giving the reviewer visual context alongside the reported facts. 3:15 — Check the complete request Before sending, the review screen brings the captured details together. This is the opportunity to check the loss description, people, policy information, vehicle, and supporting file as a complete request. All required details are present in this example. The optional VIN remains unknown, so that gap can be carried into the reviewer's follow-up note. 3:36 — Submission email and PDF Sending the request starts the review workflow and automatically emails the submitted PDF. Here is the actual notification from this demonstration, with the document attached and a link back to the authenticated workspace. The email clearly says the request is awaiting review. The recipient can open the packet directly from the message. 4:00 — Keep people in control The reviewer can examine the reported details and supporting material, request more information, or approve the intake for the next step. Here, the reviewer records a note that the fictional details and photo were reviewed, and that the service team should follow up on the missing VIN. This approval is an intake review, not a coverage or payment decision. 4:23 — Approval email and packet After approval, a second email delivers the approved PDF. This is a separate snapshot of the reviewed request. Inside the packet are the reported details, the corrected loss time, and the reviewer's note about the missing VIN. Supporting file information and the sample photo are included, so the receiving team has the intake and its follow-up context together. 4:51 — Make the handoff explicit The approved request is delivered to the internal service team mailbox. A service team member then accepts it, and that acceptance is recorded. This makes the transition visible in the request: the intake was reviewed, the packet was handed over, and the next team acknowledged receipt. 5:10 — Follow the activity history The activity history connects those steps. It records answer updates, the supporting file, submission, review, handoff, and acceptance. A team member can return to the request and understand how it reached its current state. The original report, the correction, and the reviewer's follow-up context stay connected to one claim. 5:29 — Your workflow, next From conversation to structured intake, from human review to a clear handoff. Navaura brings the work together. Visit navauratech.com to request a walkthrough of your own workflow.