Overview of the Requesting Process

Mazévo has a robust requesting process that can be used to manage end-user requests.

The Requesting Process

Once the system is configured to take requests, a requester will log into the system via the mobile app or on the web and enter a request for a new event, selecting the dates, times, rooms, and resources they need.  

The request is held in a special queue that event planners monitor.  The event planner opens each request, reviews the request and all of its details, and then either approves or denies it. 

If you have secondary approvals defined in the system, the event planner monitors the additional approvals before the request's final approval or denial.  While the request is undergoing the secondary approval process, the requester sees the request as pending until the event planner makes the final determination.  Once a request is approved, it becomes an event in the system, just like any other event created by an event planner.  

A requester can enter, view, and manage all of their own requests and events.  This entire process is configurable, including security which determines which rooms and the timeframes available for the request process. Requesters can also view requests and events that they are tied to as secondary or billing contacts. It is also possible to configure the system to allow a requester to view all events for their associated organizations. 

 

How Requests Interact With Statuses

In many systems, the event planners use statuses to indicate many different situations or workflows.  In simple workflows, there may be bookings in a confirmed status or a request status. However, event planners can use statuses to indicate what step in a workflow a booking is currently in, like Hold, Waiting for Deposit,  or Tentative.  It is desirable for more complex workflow scenarios to hide the workflow process from the requester but give them enough information like 'Is my event pending, booked, or denied?'.  To accomplish this simplification, Mazévo translates each event planner status into a requester status through the Web Requester Status field.

The requesting process is dependent on several statuses being defined in the system.  Each status in the system is tied to one Request Behavior. The Request Behaviors are: 

  • Pending - Used to indicate the booking is still being reviewed.
  • Booked  - Used to indicate the booking has been approved (confirmed).
  • Canceled - Used to indicate the requester has canceled the booking.
  • Denied - Used to indicate the Event Planner has denied the booking.
  • Other - Used for special statuses (i.e., conflict or information only statuses).

 

The difference between an event and a request is determined solely by the event's bookings' status.

Additional Information

  • Configuration:  The system will need to be configured to allow requests.  This configuration includes determining which rooms and resources will be available to requesters.  Detailed information on configuring the system for requests see this article.
  • Security: Requesters will need to have access to the system to enter requests.  Each requester will have a user id and password that has the Requester role and associated security policy.  See this article for more information on setting up requester security.
  • Entering Requests: With the system and user security configured, the requester will log into the system and enter new requests.  The requester can enter requests via the mobile app or via a web browser.  Requesters can enter, view, and manage all of their own requests and events.  If a requester changes an event (one that has already been approved), the event is placed back into a request status, and the review process starts over.
  • Processing Requests: Event planners have tools located on a special dashboard to view and manage the request process.   If the system is configured to use secondary approvals, there is a dashboard tool to help manage these approvals.