Why was SchedRequest created?
SchedRequest was created because a venture-capital managing partner had a recurring scheduling problem that auto-booking tools like Calendly do not handle well. Auto-booking means a requester chooses from pre-published open slots and the meeting lands on the calendar automatically. That is convenient when every open slot is equally acceptable. It breaks down when the meeting requires judgment: who is asking, why they want the time, which internal person should attend, whether a conflict should be overridden, and whether the organization should meet at all.
Who is SchedRequest for?
SchedRequest is for request-first scheduling: situations where people should suggest times, but the organization keeps control. Examples include venture firms, founder advisors, executive teams, accelerators, admissions programs, partner organizations, high-context sales teams, professional-service firms, nonprofits, family offices, clubs, and households coordinating meetings with one or more family members.
How does it work?
A requester uses a public or controlled URL, provides context, chooses who they want to meet with, proposes several workable times, and suggests a meeting method or place. SchedRequest protects connected calendars while collecting those options. A processor then reviews the request, compares all proposed options against calendar context, and confirms one, asks for more options, or declines. Nothing is booked until confirmation.
How is it different from Calendly or other auto-booking products?
Calendly-style tools are excellent when the rule is “if the slot is open, book it.” SchedRequest is for “suggest times and let us decide.” It preserves privacy, supports multiple people and roles, captures context and urgency, and gives the organization a decision view before calendar invitations are created.
Should an organization use its own scheduling URL?
An organization may choose to redirect a familiar URL on its own website, such as example.com/scheduling, to its assigned SchedRequest URL. That is usually the cheapest and easiest branded doorway: it lets the organization share its own domain while keeping SchedRequest as the canonical scheduling app. A branded subdomain such as schedule.example.com can be a cleaner fully branded option later. A path-preserving reverse proxy is possible, but it is not the default recommendation because it adds OAuth, cookie, security-header, and support complexity.
What should a new organization owner understand first?
There are four separate concepts: the SchedRequest login account, the organization role, the notification sender/reply-to identity, and the Google Calendar organizer/write target. They can overlap, but SchedRequest does not assume one email must do all four jobs.
Can a shared or group email be the owner/admin login?
Yes. A group email can be used as the organization owner/admin identity when that matches the organization’s workflow. That does not mean the group email must be a full Google Calendar user or the owner of every confirmed event.
Who owns the confirmed Google Calendar event?
The event is created on the connected Google calendar selected by the organization default or by the processor at final confirmation. That may be a dedicated scheduling calendar, a shared calendar visible through a connected account, or the primary invited person’s calendar.
How do notification emails work?
SchedRequest sends branded transactional emails separately from the Google Calendar invitation. Each organization can set a display name, reply-to address, internal notification recipients, and, after email-domain verification, an organization From address.
What workflows and roles are built in?
SchedRequest uses Owners, Admins, Processors, Members, and Requesters. Owners/admins configure the organization, request pages, branding, members, roles, and calendar behavior. Members connect calendars and can be included in meetings. Processors review incoming requests. Requesters do not need an account; they simply submit a request and proposed times.
Why do I need to connect Google Calendar?
Calendar connection lets SchedRequest protect unavailable time, help processors make good decisions, and create confirmed calendar events only after approval. Requesters should not see private event details. Internally, an organization can decide whether owner/admin processors see calendar labels for decision-making or whether processors should see only Busy/private blocks.
Can requesters overlay their own calendar?
Yes. A requester-side calendar overlay should be optional: the requester can connect a calendar just for this request so they avoid suggesting times that conflict for them, while the organization still decides what gets confirmed. The safest implementation is a free/busy overlay with explicit consent, no private event titles, and no account required unless the requester chooses to save the connection or create an organization later.
What calendar platforms are supported?
SchedRequest currently starts with Google Calendar because it is widely used by startups, teams, and individuals, and its APIs are strong for availability and event creation. Microsoft Outlook Calendar is the next priority. Apple Calendar and other calendar ecosystems can follow after Google and Microsoft are stable.
Can this work for married couples or families?
Yes. A couple or family can be modeled as an organization with members, calendars, request groups, and public URLs. A couple could offer “meet with John,” “meet with Susan,” or “meet with both of us” while keeping personal calendar details private. Over time, family-specific copy, household roles, child/minor controls, and consumer-oriented setup would make this even smoother.
What is the software stack?
SchedRequest is a modern web application built with Next.js and TypeScript, designed for Vercel deployment, Google OAuth/Calendar integration, transactional email, and durable multi-organization SaaS data storage. The requester-facing experience stays simple while the internal workflow can support real organizational control.
Does SchedRequest expose private calendar details?
The requester-facing flow should only show requester-safe availability. Internal processor views can optionally show more context when the organization wants owner/admin decision-makers to see it. That visibility is configurable.
Can a requester edit or add more times later?
SchedRequest supports the request-first pattern of secure return links. A processor can ask for more options, and the requester can return to the same request to add times without needing a full account.