Skip to main content

Communicate with multiple people on a Customer

A household account has two names and two phones; a fleet account has a manager, drivers, and someone in accounting. BayEngine routes messages to the right person with two pickers: the Send dialog chooses whether a document goes to the customer themself or to an Additional person, and the Inbox composer chooses which phone number or email address a message goes to. Both choices are made per send. This page covers that routing and how the shared thread behaves when several people are on one account. The basic mechanics of sending are in Send text and email messages, and setting up the people and their numbers is in Manage customer communication details, Additional people, labels, and credit settings.

One thread per customer, not one per person​

A shop has exactly one Conversation with each customer. Every text, email, call summary, and web chat with anyone on the account lands in that single thread, whichever person and whichever number was involved. When the fleet manager emails and a driver texts, both appear in the same timeline in the order they happened.

Underneath, each message records the exact phone number or email address (the Contact Point) it went to or came from, and the thread header shows a chip for each number and address that has taken part. The message bubbles themselves are labeled with channel, time, and delivery status only; they do not name the person or number. On an account where two drivers text in, their messages interleave and the bubbles look alike, so identifying who said what means reading the header chips and the content. That is the main reason to keep truly separate parties on separate customer records: one customer means one thread.

Two boundary cases worth knowing. A text from a number that isn't on any customer yet opens its own unresolved thread; linking it to the customer moves that history into the customer's thread and keeps the number as a customer-level Contact Point. And a customer who visits two shops in your organization has a separate thread at each shop.

Choose the number for texts and calls​

When a customer has more than one SMS-capable phone number, the Inbox composer grows a Send to picker listing each number with its person's name in parentheses, such as "(612) 555-0134 (Maria Ortiz)". Customer-level numbers not attached to a person show the number alone. The picker defaults to the number the conversation's latest text went to or came from, so replying to whoever just texted needs no thought; change it when you want to reach someone else on the account. The same pick decides which number an outbound call dials.

Email works the same way: with more than one email address on the account, an address picker appears, defaulting to the address on the latest email in the thread.

Consent is checked per person. If a driver replies STOP from any of their numbers, texting every number owned by that driver is blocked; the Customer and other Additional people are unaffected. Numbers must be marked SMS capable on their Contact Point to appear in the picker at all. See Resolve message-delivery and consent problems.

Choose the person for a document Send​

The Send dialog behind every paper-airplane button (estimate recommendations, inspection results, invoice) picks a person, not a number. It defaults to the customer themself, using their primary phone and email - the first number and address on the Customer Info card. When the account has Additional people, a Send to select appears with the customer preselected; picking a person swaps the Email and Text rows to that person's own details for this send only. The customer's preferred channel comes preselected without blocking the other; a recipient with no email simply has Email disabled, with the reason in a tooltip.

So on a fleet account you send the estimate to the fleet manager and, days later, the invoice to the billing contact by opening each Send and picking the person. Three limits to know:

  • The choice is per Send and is not remembered. Nothing on the visit stores "this visit's contact", so every Send starts from the customer again.
  • The dialog offers one number and one email per recipient: the customer's primaries, or an Additional person's own primary number and address. A customer with two phone numbers can only receive document Sends on the primary one - edit the Phone field in Edit customer to change it. The Inbox picker is the place that sees every number.
  • Text document Sends are recorded in the Customer's Conversation with their delivery state. An emailed approval request reaches the customer but does not appear in the Inbox thread; the Repair Order's Activity log is where "approval request sent" and "invoice sent" show up. See Send Estimates, Inspections, and Invoices.

Every Send of the same visit hands out the same portal link. There is no per-person link, login, or view: sending the estimate to the fleet manager and the invoice to the billing contact gives both people the identical page, with the inspection report, prices, and invoice all on it. Anyone holding the link can approve work, so who you Send to is the access decision. The greeting is account-level too. A personal customer's portal says "Hi Sarah" using the customer's first name; a business customer's portal greets with the company name, whoever opens it.

Who actually approved is captured at signing. The authorization dialog requires a name, prefilled with the customer's name, and that typed name is what lands on the Authorization Evidence and the invoice's authorization narrative. Coach fleet contacts to replace the prefill with their own name; if they leave it, the record falls back to the account's name, and the recorded contact detail defaults to the customer's primary phone and email. Staff-recorded phone approvals can capture the caller's actual number. See Use the Customer Portal for approvals, status, documents, and payment and Record authorizations, declines, and deferred work.

A fleet visit, person by person​

Putting it together for the common case: a driver drops off, the fleet manager approves, and accounting pays.

  1. At check-in, record what the driver reported as Reasons For Visit. If it matters who said it, put the name in the reason text ("Driver Sam: grinding when braking"). The API can tie a Reason For Visit to the reporting contact, but no screen sets that today, so the text is the reliable place. See Set the Reason For Visit, Visit Type, odometer, and Promise Time.
  2. When the estimate is ready, Send it and pick the fleet manager. They open the portal, select services, and type their name at signing, which puts them on the authorization record.
  3. Mid-job questions go through the Inbox with the recipient picker on the manager's number; a parts ETA for the driver goes to the driver's number. Same thread, different numbers.
  4. After finalizing, Send the invoice and pick the billing contact. Email is usually right here; the message carries a View invoice link into the same portal.
  5. The driver picking up can use any copy of the link to see "Ready for pickup"; the link doesn't care who holds it.

What this flow does not have today: a stored per-visit contact, a portal that shows different people different things, per-person spending limits, or any approval gate that says only the manager may authorize. If the shop needs the manager's sign-off, the control is procedural: Send to the manager and check the name on the authorization record.

Keep the account tidy so routing stays obvious​

Routing is only as good as the people list. Give each Additional person their own entry carrying their own numbers; a customer cannot hold the same number twice, so a shared household phone is one Contact Point and the thread cannot tell the two spouses apart on it. Fill in the relationship (Spouse, Driver, Billing) so the Send picker reads like an org chart - the customer themself is always the default recipient, so there is no primary person role to assign. Keep the primary phone and email on the number and address the customer actually answers, since those are what every default send uses. And be careful deleting people: the person's Contact Points and their identity in the thread go with them.