Make scheduling with assigned setup specialist experience native

[anmurali]

We currently link out to Calendly for all schedule demo or schedule a call links/ buttons. There are a few opportunities here:

1. We have an off brand, not so beautiful UI experience
2. We don't have insight into the next available date/ time each lead sees, and so if appropriate, aren't able to provide the opportunity to the lead to pick an earlier time on some other available setup specialist's calendar
3. We can't customize the experience itself as it relates to prerequisites we might want a lead to finish before we allow them to schedule. E.g (not exhaustive list)
   a. A lead of size 1-10 - we might ask them to connect their accounting ledger before scheduling a call
   b. A lead of size 11-50, which is a wide range, we could ask incremental qualifying questions to determine if we also want to require some pre-work in the account before allowing them to schedule
4. We have to keep all Guides/ sales team calendly links public, which means, anyone can and does schedule calls on their calendar and block time that should go to otherwise legit leads.

Let's make a beautiful in-app scheduling flow, which utilizes the Calendly APIs. Then once we're done with that, we can follow on by making all calendly links private, and then add logic like the ones listed in #2 and #3 as follow ons.

On clicking Schedule demo, we would open an in-app modal that allows the user to pick a date and then the time. As an example, this is what the Calendly one looks like, on click:

Then any schedule links in any email or Concierge or Guides messages would all direct the user to this in-app modal

[melvin-bot]

Triggered auto assignment to @shawnborton (Design), see these Stack Overflow questions for more details.

[anmurali]

Once we have some mockups, I can open this up to Contributors.

[shawnborton]

cc @Expensify/design for viz. I will get started on this one tomorrow, and my first thought is to do something very similar to what we already have via Calendly.

[shawnborton]

Here is what I have so far... a "wide modal" when you first go to book:

With a simple confirmation step afterwards:

For mobile, not sure if we want to drastically change the layout here (like break the first step into two steps) or just do something stacked like this?

@anmurali before I keep exploring, what happens after you confirm a meeting? Do you get a message in the room where you booked? An email? Something else?

cc @Expensify/design for feedback. Figma is here!

[parasharrajat]

I don't think we need a confirmation screen for this, the first step should be good enough where user selects a date and time and then hit confirm.

[shawnborton]

That's fair, we could in theory make the times just look like a list with checkboxes, and then a big green confirm button on the bottom of the page. That might feel like a lot to squeeze on one screen though.

[parasharrajat]

But it will save extra step in the process. We already have two steps where first user clicks schedule a demo button and then this modal where they select data and time.

Because, selected date and time can be shown as primary(green), it should be sufficient to for user confirmation. Anyways, they will have to hit a submit button or something at the end of this modal.

Yeah, if we want to move to confirmation on the selection on date and time automatically then no submit button but that is a new pattern IMO, having a confirm button is easy and familiar pattern.

[shawnborton]

Yeah, I personally don't think having the confirm page is a bad thing though, and it's pretty consistent with most flows in the app. Let's see what others think though.

[dannymcclain]

Looking good!

I don't mind the confirmation page at all. It doesn't feel like an extra step to me, just an opportunity to double-check everything. One thing though is that you wouldn't really be able to edit the Date, Time, and Timezone independently in separate push rows would you? I almost think on the confirmation page those should be read only push rows and then have one edit or change button somewhere there that basically just takes you back to the previous screen. (Or maybe the top left caret is enough?)

As far as mobile goes, I'd probably just do what you're doing and stack the times below the calendar and let the screen scroll. 👍

For the Timezone push row in your first mock, are you imagining it opening "above" the modal?

[shawnborton]

One thing though is that you wouldn't really be able to edit the Date, Time, and Timezone independently in separate push rows would you?

Nope, I was being tricky and just assumed that either of those push rows would navigate you back to the previous page. And now that I think of it, it seems pointless to have a timezone push row on the confirmation page.

Maybe a more simple approach might be to only change out the content of the modal after you press the time button, something like this?

CleanShot.2025-02-18.at.21.19.47.mp4

Though I could see where that doesn't quite follow other patterns we use across the app. So maybe we do want the modal to seem like it's sliding the content in/out like the onboarding modals do?

[dubielzyk-expensify]

I like the prototype you're showing at the end. Couple of questions:

1. You've made some updates to the date picker (which I do low-key dig). Will they be making their way to the regular date picker? Feels like we should have one UI for calendars here and not multiple?
2. I don't mind the modal, but it feels like we usually always do RHP on these kinda flows. I've mocked one up in our more standard pattern in Figma, but I'd be keen to hear why we stray from RHP here and if so, what's rule when we do it?

[shawnborton]

Will they be making their way to the regular date picker? Feels like we should have one UI for calendars here and not multiple?

Ah that's actually a super great point, I forgot we had an existing calendar I could use 🤦 I say let's not plan on making any calendar changes here that are one-off, so let's use what we currently have.

but I'd be keen to hear why we stray from RHP here and if so, what's rule when we do it?

My thinking was that it was important to be able to pick a date and see times at the same time. At least that feels much more efficient to me than needing to split that across two steps. I don't feel too strongly though and I'm happy to do something stepped in the RHP for the sake of consistency. But I do feel like it maybe doesn't provide the smoothest booking experience?

[shawnborton]

If we use the idea I had above but with our existing calendar, we get this:

[dannymcclain]

Personally I think we should just roll your calendar updates into this issue and send it. Though if we super duper need to keep the year separate from the month, here are a couple riffs:

Regarding the modal vs. RHP, I can't believe I'm saying this since I'm a System Stickler™, but I agree with Shawn's points here:

My thinking was that it was important to be able to pick a date and see times at the same time. At least that feels much more efficient to me than needing to split that across two steps. I don't feel too strongly though and I'm happy to do something stepped in the RHP for the sake of consistency. But I do feel like it maybe doesn't provide the smoothest booking experience?

I much prefer the modal, and his prototype video above feels really nice to me. Having said that, if we're super set on keeping it in the RHP we could maybe do something like this where we keep it one screen and just let it scroll if it gets too big? Riffage below...

Use select-y elements instead of buttons for time selection:

Replace the footer button with time slot buttons

Just a few ideas! I still think Shawn's modal idea is my preferred solution. Figma for the tweakerz.

[shawnborton]

Personally I think we should just roll your calendar updates into #52621 and send it.

I think I would punt any calendar changes into a different issue entirely, just so we aren't adding too much scope here.

Actually I think I quite like the simple RHP solution you are showing? Maybe with less intro text it's not as bad:

[dannymcclain]

I think I would punt any calendar changes into a different issue entirely, just so we aren't adding too much scope here.

FINE 😂

Actually I think I quite like the simple RHP solution you are showing? Maybe with less intro text it's not as bad:

Yeah this isn't bad at all! I like your tweaks as well. Wonder what The Judge™ will think.

[anmurali]

@anmurali before I keep exploring, what happens after you confirm a meeting? Do you get a message in the room where you booked? An email? Something else?

It is pretty disjointed today. They don't get any messages as confirmation from us - chat or email. They do get a confirmation email and reminders from Calendly directly. I actually didn't think of this at all, so thank you for reminding me. When we use the APIs, I think we should control these messages. We should post the confirmation and any reminders to #admins.

I love the mockups #56910 (comment)

[shawnborton]

We should post the confirmation and any reminders to #admins.

I like this. Who do you think this message would come from? Would it be from Concierge, sent to everyone in the room?

What kind of information does the message have? As in, what do we use for the meeting link, etc?

I agree though, I am feeling pretty good about the most recent round of mocks - they seem to fit our current patterns the most and will scale very well to mobile.

[anmurali]

Who do you think this message would come from? What kind of information does the message have? As in, what do we use for the meeting link, etc?

The calendly confirmation page looks like this

1. The message should come from the assigned setup specialist. A confirmation that the call is scheduled and they're looking forward to the discussion. cc @jamesdeanexpensify )
2. We should use custom subj line so an email is sent immediately as well
3. Doesn't have to look like the Calendly one visually but it would make sense to include all these details
4. Bonus points if the 3:30pm - 4:00pm, Friday, February 28, 2025 was a link that opened up their calendar and allowed them to add it with one click.

[jamesdeanexpensify]

Expensify meeting scheduled
Thanks for scheduling a call with me! I'm really looking forward to our discussion at [time + date like @anmurali laid out above]. Let me know if you have any questions in the meantime.

Talk soon!

[jamesdeanexpensify]

something like that?

[dubielzyk-expensify]

I actually really like this RHP solution you've all got here. This feels right to me. Again, I don't mind the modal but I also kinda feel like a simple RHP allows us to get this out quicker than having to worry about modals and breakpoints. Would also be good to start noodling on some rules of when it's appropriate vs not. I don't think we should be against them and I'll leave it to y'all if you think it's better here. My vote is still probably for the RHP given the entry point also is from a chat

[anmurali]

Yep, I think the RHP is our pick.

@parasharrajat do you want to implement the FE here?

[parasharrajat]

Yes @anmurali

[shawnborton]

When you schedule with Calendly, you get an automatic email that has a calendar invite. Can we do something similar?

Otherwise I'm not sure that users are going to take that extra manual step to add it to their own calendar? Not sure really...

[shawnborton]

Otherwise it looks like we have something like this for our follow up message in the #admins room at least:

[shawnborton]

Full flow:

[dannymcclain]

Looking good! Just to confirm: we want to leave the Schedule demo button there even after the user schedules a demo in case they want to schedule another one or something, right?

[shawnborton]

Oh that's a good shout... I don't know how I feel there, I could see leaving it in case you wanted to schedule another one?

Another thing that came to mind... @anmurali Calendly makes it easy to cancel or reschedule bookings. What are you thinking for that functionality?