Manage promised callback windows

Separate a preference from a confirmed commitment

A customer preference for the morning differs from a promise that a named person will call between 10:00 and 11:00. Record preferred window, confirmed window, owner and confirmation time separately. Include a short purpose, such as clarifying scope or answering a specific question. This prevents a generic callback task from being assigned to someone who cannot help. If the time is still tentative, keep it visibly unconfirmed rather than allowing a date field to imply a promise.

Record how and where the customer may be contacted

Keep the case reference, approved contact route, timezone, voicemail preference, requested window and confirmed window. In CB-083, a customer may explicitly prefer not to be called at work. Make that instruction visible to the person placing the call. Avoid copying phone numbers into every notification or URL when the authorised register can provide them. If contact details change, identify the currently approved number instead of leaving several competing values in free-text notes.

Keep callback windows separate from call attempts

One promised window may lead to several attempts: no answer, busy line and finally a conversation. Record each attempt with its time, caller, outcome and next action without overwriting the original commitment. An unanswered call is not automatically a completed task. Decide whether another attempt, an email or a new agreed window is needed. When the customer requests a different time, preserve the earlier promise and explain the change instead of silently moving the deadline.

Build a queue that supports absence coverage

Order today’s confirmed callbacks by window start, with separate queues for unassigned, missed and rescheduled calls. Coverage should go to someone with the information and authority to handle the purpose, not just anyone with spare time. Include the previous question and unresolved points in the handover. Otherwise the customer has to repeat the entire enquiry and the team may count an unhelpful call as meeting its promise.

Resolve crossed messages before calling again

Before another attempt, check whether the customer replied by email or spoke to another colleague. Cancel a resolved callback with a reason instead of deleting it. If the number appears wrong, confirm through an approved channel rather than guessing an alternative. Keep internal reminder retries separate from customer-facing call attempts. A reminder can safely be repeated more often than a customer should be contacted, so one retry policy should not govern both activities.

Test date and timezone boundaries

Check same-day and next-day requests, an overseas contact, out-of-hours preferences, a changed commitment and a failed attempt needing another call. Compare the displayed time with the words the caller would actually say to the customer. Verify that a missed window remains visible and a resolved task does not reappear the following day. Fictional numbers and contacts let the team check the workflow without accidentally placing real calls.

CB-083: a preferred window cannot be met

For CB-083, the customer prefers the morning but the owner is away until 11:00. Do not register the preference as a confirmed appointment. Agree an available window, then assign its owner. A no-answer attempt at 11:30 is not necessarily completion; check voicemail and follow-up preferences. If the customer resolves the issue by email, cancel the call with that reason. Distinguishing preference, promise, attempt and resolution gives a covering colleague the information needed to act consistently.

Choose a tool and budget around the actual workload

A calendar and shared note can work for one person handling a few callbacks. A register becomes more valuable when several people provide coverage. Before adding automatic calendar creation, ensure an unconfirmed preference cannot become a firm appointment. Compare seats and notification volume together with the time wasted on crossed or repeated calls. The useful improvement is a dependable promise and handover, not simply putting more events on everyone’s calendar.

• Build an Airtable enquiry tracker: intake, owners and follow-up states
• Define business days and time zones for automation
• Create Google Calendar bookings with Make: event IDs, changes and cancellations