Help

User guide and support for SchedRequest.

Search the guide, learn how request-first scheduling works in practice, or contact SchedRequest support.

Help center

User guide + contact

This page is intentionally more manual-like than the FAQ. Use it for what to click, what to check, and how to contact SchedRequest support with a product question or issue report.

User guideStep-by-step operating instructions for requesters, processors, members, and admins.Contact SchedRequest supportAsk for help, report a problem, or send product feedback.

Help search

Search the user guide

Search by workflow, screen, role, or action.

User guide

How to use SchedRequest

Read straight through for a manual-style overview, or search above to narrow the guide.

1

Start with the right mental model

SchedRequest is not an open-slot booking page. It is a request-first workflow: requesters suggest options, then the organization decides what should actually be booked.

  • Requester: submits context, preferred attendees, suggested times, and place or meeting method.
  • Processor: reviews the request and calendar context before deciding.
  • Owner/admin: configures organization identity, users, request page, calendar behavior, and notifications.
  • Member: connects calendars and can be included in appointments.
2

Submit a scheduling request

The public request page guides an outside requester through the information the organization needs before it will commit calendar time.

  • Enter name, email, phone, company, and the meeting reason.
  • Choose who you want to meet with or which request group applies.
  • Choose urgency honestly; urgent or VIP requests still require processor approval.
  • Suggest several dated time options. Nothing is booked yet.
  • Choose a meeting method or place, then submit the request.
3

Process and confirm a request

Processors use the request queue and calendar-context decision view to make the final scheduling decision.

  • Open Requests to confirm and select a request from the queue.
  • Open calendar context to compare all proposed options against protected calendars.
  • Select an available proposed option, or enter a new processor-selected final time.
  • Use the final time/place selection screen to choose the exact final time, place or method, and organizer/write calendar.
  • Confirm only after the final choices are correct. Confirmation sends the calendar invite and requester notification.
4

Ask for more options or decline

If no proposed time works, the processor should not force an awkward booking. Use the built-in request-first fallback actions.

  • Ask for 3+ more options when the request is still worth pursuing but current options do not work.
  • Add a concrete message so the requester understands what is needed.
  • Decline the request when the meeting should not move forward.
  • Closed or waiting requests should not keep showing final-action buttons.
5

Requester return links

SchedRequest can include a secure return link so a requester can come back to the same request without creating a full account.

  • Use the return link to view request status, edit requester-owned details, add more times, or cancel when supported.
  • The return link is requester-safe: it does not expose internal processor notes or private calendar details.
  • Processors can send the return link when asking for more options.
6

Connect and protect calendars

Calendar connection lets SchedRequest protect unavailable time and create final events after approval.

  • Each real person connects their own Google Calendar account when they are a member.
  • Availability checks use free/busy protection for requesters; private event titles stay hidden externally.
  • Owners/admins can decide whether internal processors see calendar labels or only Busy/private blocks.
  • A shared or group email can own/administer the SchedRequest workspace without owning the Google Calendar that creates final appointments.
7

Set organization identity and notification defaults

Keep identity concepts separate so a setup stays clean instead of forcing one email to do every job.

  • SchedRequest login account: who signs in and administers the workspace.
  • Organization role: owner, admin, processor, or member permissions.
  • Notification identity: display name, reply-to, internal notification recipients, and verified From address when available.
  • Calendar organizer/write target: the connected calendar where final events are created.
8

Share the right scheduling link

Every organization gets a SchedRequest URL. The cleanest branded doorway is usually a simple redirect from the organization’s own website.

  • Use the assigned SchedRequest URL as the canonical app URL.
  • Optionally redirect a familiar site path like example.com/scheduling to the assigned SchedRequest URL.
  • Use a branded subdomain such as schedule.example.com later if the organization wants a cleaner fully branded entry point.
  • Avoid path-preserving reverse proxies unless there is a strong reason; they add OAuth, cookie, security-header, and support complexity.
9

Use FAQ vs. Help

The FAQ answers product questions. The Help page is more manual-like: what to click, what to check, and what each role should do next.

  • Use FAQ for conceptual questions such as how SchedRequest differs from Calendly.
  • Use Help when you need operating instructions or a step-by-step user guide.
  • Use the Help contact form or support@schedrequest.com when you want to send the SchedRequest team a question, issue report, or product feedback.

Contact

Contact SchedRequest support

Use this for support questions, product feedback, issue reports, or anything that should go to the SchedRequest team instead of becoming a scheduling request. You can also email support@schedrequest.com.