When only a person knows, the agent calls them
A customer asks something only your team can answer. The agent finds who owns it, phones them, answers their questions, reads the reply back word for word, and sends it.
Some questions don't have an answer in any system. Is the part in? Can she keep the loaner another day? Will Chris match the quote he gave on Saturday? An agent that guesses at these does damage. An agent that only files a task leaves the customer waiting until someone happens to open it.
IDP does a third thing. The agent works out who owns the question, makes sure that person hears about it, and if they haven't picked it up, it calls them. It asks what to tell the customer, answers their questions about the request while they're on the phone, reads the reply back word for word, and sends it once they say yes.
Who owns the question
Every request that lands in Needs a person now has an owner when one can be found. If the customer names someone ("Can Chris call me back?"), that person owns it. If they name a department ("someone in service"), the team does. If two people share the name they used, IDP doesn't guess: Needs a person shows the request with the reason, such as "2 people are named Luis", so a manager can assign it.
Anyone can take a request with Take it, or assign it to a person or a team. Whoever owns it is shown on the task, along with everything that happened to it: who was told, how, who took it and what was said.
Owner first, then everyone
With Owner first on for a store, the owner is alerted alone: in the app, by push, by text and by email, whichever they've set up. Everyone else on the alert list hears about it only if the owner doesn't take it within the wait you choose. That wait counts your store's hours, so a request that arrives at 8:55 PM doesn't page the whole team at 9:25 PM.
If an alert can't reach the owner at all, for example because their phone hasn't agreed to alert texts, the rest of the team is told right away, with the reason.
The call
When the wait runs out and the owner is one person, the agent can phone them before the backup goes out. It calls from your store's number, in the store agent's own voice, and introduces itself the way your customers know it: "Hi, it's Mandy from Your Store. Is this Chris?"
Then it gets to the point in two short sentences and asks once: what should I tell them? After that your teammate leads. The agent answers what they ask in a sentence or two and doesn't pad the call. If they go quiet, it checks in once, softly. It never hangs up on silence, and it ends the call when they say they're done.
The agent only calls people who have agreed to agent calls. It won't call inside their quiet hours, it calls each person at most once per request, and a store's calls to its own staff are capped each hour. If the call reaches voicemail, the agent hangs up without leaving a message, and the alert goes to the rest of the team as it would have.
Lookups while your teammate is on the line
Your teammate rarely has the whole story in their head. So while they're on the call, the agent can look things up, read-only, and only for this customer and this store:
- The conversation so far: what the customer said, in their own words, and what the agent replied.
- The customer's details: how they reached you, how long they've been a customer, what they're interested in and recent notes.
- Appointments: upcoming and recent visits, including the ones the store booked itself.
- The task so far: who was told and when, and when everyone else will be told if nobody takes it.
- Store hours for any day your teammate names, said the way they say it: "next Thursday", "tomorrow morning", "the 29th".
- Open times from your booking system, so "What do we have tomorrow?" gets a real answer.
A lookup that can't answer says so plainly ("I can't check open times right now") and the call goes on.
Read back, then sent
When your teammate gives the answer, short or rough is fine. The agent writes it as a message to the customer, in its own voice, and reads it back word for word: "Here's the text: 'Good news, Dana: your part is in. We can see you tomorrow at 8:00 or 10:30 AM. Which works?' Shall I send it?"
Nothing is sent until they say yes. If they change it, the agent writes it again and reads the new version. If the message can't be sent, for example because the customer has opted out of texts, the agent says so on the call and asks whether your teammate will handle it themselves.
When it's sent, the task records that it was answered on a call, by whom, and the request closes with the answer. If your teammate would rather call the customer back themselves, they can say so, and the agent records that they've taken it, with when they'll do it if they say.
Or answer by text
Not every answer needs a call. Every alert to the owner ends with a reply number: "Reply 3 to take it, or 3 and what to tell Dana."
A bare "3" takes the request. "3 it's in, offer tomorrow 8 or 10:30" plans an answer: the agent writes it up and texts back the exact message for approval, "Reply Y to send, N to drop it." Y sends it and closes the request. If someone owns several requests at once, each has its own number, and a reply without one gets a short list to choose from.
What you set up
- Owner first and the backup wait, per store, in alert routing.
- Agent calls, per person, in People and teams. A person needs a name and a phone number, and they record their own agreement to be called.
- Quiet hours per person, or the store's own.
Everything else comes from what's already there: your people and teams, your agents' voices and your store's booking system.
Why it matters
The cost of a question only a person can answer isn't the answer. It's the time it waits. Owner first makes sure the right person hears about it. The call makes sure they hear about it in a way that's hard to miss, with everything they need to answer on the spot, and the read-back makes sure what reaches the customer is exactly what they approved.
Questions about this? The agent on this page runs on IDP. Ask it anything here, or how it would work at your store.