17

I have a reservation web form. There is a field named "time". It's a select option like:

# Select a time: 

<select>
    <option>09:00 AM</option>
    <option>10:00 AM</option>
    <option>12:00 PM</option>
    <option>02:00 PM</option>
    <option>04:00 PM</option>
</select>

The user must select one of those times to specify at which time we have to call him/her for finalizing his/her request.

Now, I need to add a short label under that field to mention this possibility:

Probably we call you 30 mins sooner or later than the time you selected

How can I say that sentence much shorter?

88

It sounds to me like what you really want is for the user to select a one hour time slot instead of a fixed time.

This makes it much clearer that you cannot commit to a specific time and the user must be prepared for an estimated time given a one-hour timeframe.

<select>
    <option>09:00 AM - 10:00 AM</option>
    <option>10:00 AM - 11:00 AM</option>
    <option>12:00 PM - 01:00 PM</option>
    <option>02:00 PM - 03:00 PM</option>
    <option>04:00 PM - 05:00 PM</option>
</select>

I would suggest you include a message above the select control that states something like:

Unfortunately, we cannot offer an exact time to call, and will call within a one-hour window. Select your preferred time slot from the options below.

If you are looking to reduce "text clutter" on your page, then you probably don't even need this at all. Having the time ranges in the options should be sufficient for the user to understand it is not a fixed time.


A note on implementation. You can still technically only need to store a single time in your database, which would be the middle time. For example, if the user selects 9am-10am, you can just store 9:30am.

My suggested change is more about how the user perceives the options, rather than about what data you actually need to capture.

7
  • 42
    You're right, but I'd store the start time not the central time. Online shopping round here is 1 hour slots, and they're always referenced by the start time - i.e. when you need to be ready - by both customers and staff; the common reference is helpful
    – Chris H
    Jul 7 at 21:28
  • 10
    You could also consider overlapping slots: 9:00-10:00, 9:30-10:30 etc.
    – TripeHound
    Jul 8 at 10:11
  • 1
    @ChrisH: Indeed, I would do the same. I just didn't want the OP to feel my answer wasn't suitable because they can't change the DB or can't change the agreed process (half hour either side), or whatever.
    – musefan
    Jul 8 at 10:25
  • 1
    His windows would actually be from 8:30 to 9:30, 9:30 to 10:30, etc. Not 9:00 to 10:00, 10:00 to 11:00...
    – Kevin
    Jul 8 at 14:17
  • 1
    It’s not clear that @Kevin’s edit fits with @ musefan’s original intent in this answer. If actual timeslots offered are outside OP’s control and must be exactly as described in the question, then yes, slots like 8:30–9:30 correspond to that. But if OP is involved in choosing the timeslots, then slots like 9:00–10:00 are usually easier for both customers and internal scheduling, and I guess @ musefan chose them deliberately with that in mind.
    – PLL
    Jul 9 at 14:51
12

I like the answer of @musefan, that was my first thought too. But there might be another solution:

  • 09:00 AM (+/- 30 minutes)
  • 10:00 AM (+/- 30 minutes)
  • 11:00 AM (+/- 30 minutes)

etc. you get the point

Therfore the selection might be a little easier since the user has to concentrate only on one specific time. At the same time you communicate that the chosen time is actually a time slot not an exact time.

8
  • 20
    I think the two proposals communicate slightly different things. Your proposal suggests that the given time is the likely time, with an error tolerance of 30 minutes. I would expect a not insignificant number of users to be overly optimistic, expecting a call close to the given time (and thus they might make plans for the outer ranges of the timeslot). musefans proposal on the other hand suggests that the call might very well come at any time during the slot.
    – tim
    Jul 8 at 10:46
  • 1
    Your proposal seems to be closer to what OP had in mind, but which one to choose imho depends on 1) how close to the given time the calls are usually made and 2) how bad it is if the user cannot be reached.
    – tim
    Jul 8 at 10:46
  • 21
    Call me pessimistic about people, but this seems overly technical for most average people. A plus and minus sign that close together is just too much math - peoples' brains seem to shut down when that happens.
    – J...
    Jul 8 at 12:16
  • 7
    @J... We could give them a graph of a standard distribution of when they're most likely to be called
    – Cruncher
    Jul 8 at 17:07
  • 3
    I agree with the frame-challenges here, but wanted to point out that the "+/- 30 minutes" text here is probably a good answer for OP's actual request for short text under the selector. Personally, I'd go with "We will call within 30 minutes of your selected time", but that's not much shorter than what OP's already got.
    – A C
    Jul 8 at 20:59
0

The middle time is not the important time. they need to be ready at the start of their time window and need to be prepared to wait for up-to an hour to be served.

I would list the starts of the windows:

8:30 930 etc..

And above it say, select your appoinment time, your appointment may start upto an hour later than the time you select, be prepared to wait.

-2

"Someone will reach out to you up to 30 minutes before or after your scheduled time."

2
  • 2
    If the user is entering a time to be CALLED, the idiom "reach out to you" may also cause confusion. "An agent will call you as much as 30 minutes before or after ___" confirming the time chosen is MUCH clearer. Clearest: "You will be called between ___ and ___" Jul 9 at 2:07
  • Fair point. How about, "Prepare to receive a call between" (T-30) "and" (T+30) ? Jul 9 at 2:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.