Skip to main content

Set the Reason For Visit, Visit Type, odometer, and Promise Time

Four fields describe the visit itself, separate from the work on it: the Reason For Visit (why the customer came), the Visit Type (how the vehicle arrived and whether the customer is waiting), the odometer reading, and the Promise Time (when you committed the vehicle will be ready). This page is the reference for each one: where it lives, what reads it, and what happens when it is wrong or empty. For the check-in moment itself, see Check in a vehicle and record visit details.

All four start on the appointment when there is one and carry onto the Repair Order at check-in. Editing them needs update permission on the record they sit on: calendar events for an appointment, repair orders or estimates for a document. See Assign Shop Roles, shop access, and User Permissions.

Reason For Visit​

A Reason For Visit is the problem the customer reported, in their own words: "grinding noise when braking", "check engine light is on". It is free text. A visit can have several, each entered as its own row, and each can record which Customer Contact reported it. It is not a category or a dropdown, and it is distinct from Technician findings, which are what your staff observed.

You add Reasons For Visit in four places: the appointment form, the create Estimate screen, the create Repair Order screen, and the Estimate tab of an open document. Appointment reasons copy onto the Repair Order at check-in, so capture what the customer actually said on the phone; the advisor at the counter should not have to ask again.

Reasons For Visit do real work downstream:

  • On an Estimate or Repair Order, each one anchors a Concern Group, the problem area you link Services to.
  • Any Service linked to a Reason For Visit shows under Customer requested on the Estimate tab and the Customer Portal. Services without one fall to Recommended, which is a weaker position when the customer decides what to approve. The portal also shows the reason's text under the Service as evidence for why the work is proposed.
  • A Reason For Visit is a required authorization fact by default. A customer cannot submit a portal authorization while the document has none; the confirm dialog asks them to type it in right there. The odometer can be required the same way but is optional by default. Staff-recorded authorizations run no such check, so the gap can remain on a counter-approved document until someone fills it in. There is no settings page to change either requirement yet.

On a Repair Order, adding, editing, reordering, or deleting a Reason For Visit is recorded in the RO's Activity log with the text quoted, for example Added Reason For Visit "grinding noise when braking". Changes to reasons on an appointment or an estimate are not logged.

Visit Type​

The Visit Type is the intake mode for the visit. There are exactly three:

  • Drop off (key icon): the customer leaves the vehicle.
  • Waiter (coffee cup icon): the customer stays at the shop. Waiters outrank everything else in most shops' triage, so this is the value worth keeping accurate.
  • Tow in (tow truck icon): the vehicle arrived on a truck, which usually means it does not run.

Walk-in is not a Visit Type. A walk-in is a visit with no prior appointment; a walk-in customer still drops off or waits. See Manage online bookings, walk-ins, and no-shows.

You pick the Visit Type on the appointment form, on the create Repair Order screen, and later in the Visit Details card on an Estimate or Repair Order. It may remain Not recorded until the shop knows whether the customer will drop off, wait, or have the vehicle towed in.

What reads it: the Workflow board shows the Visit Type icon beside the customer's name on each card, so a scan of the board tells you who is sitting in the lobby. The Calendar has a visit type filter, the appointment details and the Visit Details card show it, and a change on a Repair Order is logged in Activity. That is the full list - no report groups by Visit Type, no automation triggers on it, and the customer never sees it.

If it is wrong or missing, nothing breaks; the board icon is absent and the Visit Details card shows "Not recorded". The cost is human: a waiter that is not marked as one gets triaged like a drop-off.

Odometer​

A Repair Order carries an odometer-in reading, an odometer-out reading, and an odometer status. An Estimate carries a single reading, since the vehicle may not be at the shop. Readings display in your shop's distance unit (miles or kilometers) and accept one decimal place.

Odometer in is usually captured at check-in: the create Repair Order screen has an odometer field, and an estimate's reading becomes the Repair Order's odometer in when the estimate converts. After that, the odometer button in the document header (the gauge icon showing odometer in, or Set odometer) opens the Edit odometer dialog with both readings and an Odometer does not work checkbox. Odometer out must be greater than or equal to odometer in unless the odometer is marked inoperable. The database also knows "replaced" and "exceeds mechanical limits" statuses, but no screen sets them yet.

A converted or closed Estimate can no longer take a reading, so it stops offering the Set odometer button. A reading captured earlier still shows; an Estimate with no reading lists the odometer as Not recorded on the Overview tab, alongside VIN and plate.

The reading follows the vehicle, not just the document:

  • The Invoice prints odometer in and odometer out on separate lines. A missing reading is labeled Not recorded, which matters for resale-value documentation and for any warranty claim that hinges on mileage.
  • The vehicle history panel on a Repair Order lists each past visit with its reading, so the readings across visits form the vehicle's mileage history.
  • BayEngine estimates the vehicle's current odometer from that history. Vehicle cards on the customer page show it with a tilde ("~82,450 mi"): the estimate projects forward from the last invoiced reading using the vehicle's own driving rate, or a 12,000-miles-per-year default when there is only one reading. A vehicle currently in the shop shows its real reading instead, without the tilde.

A bad reading therefore pollutes more than one document: it prints on the invoice, skews the estimated odometer, and misdates the mileage history. Fix mistakes in Edit odometer; the correction is logged in Activity with both values, for example "Updated mileage in from 82,000 to 82,450".

Nothing yet turns odometer readings into maintenance recommendations. The estimation model was built with OEM service intervals in mind, but no comparison against them exists today.

Promise Time​

The Promise Time is the ready-for-pickup time you committed to the customer. It is not the appointment's scheduled time: the appointment's start and end are when the vehicle arrives and how long the calendar block lasts, while the Promise Time is when the customer expects the keys back. Setting one never moves the other.

You can set it on the appointment form or in the Visit Details card on an Estimate or Repair Order. Click the compact value in the card to open Edit promise time, then save the change. After one is set on a Repair Order, you can also click the Due time in the Repair Order header to open the same dialog and change or clear it. It is optional in both places, and the create Repair Order screen skips it entirely. For a walk-in you commit after you have looked at the vehicle, from the Visit Details card. The picker lists half-hour times, marks when the shop closes, and suggests one hour before closing; you can type any time and pick a different day for multi-day jobs.

Once set, the Promise Time shows up wherever someone decides what to work on next:

  • The Repair Order header and Visit Details card show it as "Today, 5:00 PM" style text, turning amber within two hours of the commitment and red once it has passed.
  • Workflow board cards show it beside a clock icon (time only when it is today, date and time otherwise). The board does not color it.
  • The Workflow board shows each Repair Order's Promise Time so staff can prioritize sourcing and ordering on its Parts tab.
  • The Customer Portal tells the customer "Estimated ready by" with this time, and the Inbox's Repair Order panel shows it during conversations.

Nothing alerts you when a Promise Time approaches or passes: no notification, no text to the customer, no board sorting. The amber and red text on the Repair Order is the only built-in pressure, so the board's promise times are only as useful as your habit of scanning them.

Changing it later is fine and common; parts arrive late. Click the header's Due time or update it in the Visit Details card, then tell the customer. Every change is logged in Activity ("Updated promised time to Jul 24, 2026, 5:00 PM", "Cleared promised time"), so you can always reconstruct what was promised and when the commitment moved. What BayEngine will not do is stop you from promising a time you cannot hit.