📅Requests
A customer makes a request with a partner to secure qualified service providers.
Last updated
A customer makes a request with a partner to secure qualified service providers.
Last updated
A request is a powerful tool to track a customer's needs and the providers who can meet those needs. Usually a partner will manage the request process on behalf of a customer; but in some cases customers may make their own requests.
A customer makes a request through their partner in order to have a qualified provider perform the services they are requesting. A request can be as simple as wanting a single provider just once (e.g., "Follow-up appointment next Monday") or as complicated as a multi-date and time event requiring multiple providers (e.g., "Physics 101 Fall Semester 2022").
You can create a new request by selecting the "Create" drop down in the upper right-hand corner of the site. This will open a create request template. On the right side of the page you can find a checklist or requirements needed before you can submit your request. After you have customized the request and added all the required information it can be submitted.
To begin creating a request the following information is needed:
Location: for on-site requests the full address is required; for remote requests only the city and state of origin
Title: name of the event (e.g., "Physical Therapy Appt", "Staff meeting", etc)
Topic: a topic is used by our system to help find the most qualified provider(s) for the request
Summary: short summary is shared with considered providers to help identify the most qualified one
Private summary (optional): short summary that only providers assigned to the request can read; this can be used to share sensitive information with only the those people who need it
Check-in instructions (optional): what the provider must go through to check-in when the request is underway (e.g., if they need to report to a particular person or location or fill out any specific paperwork)
After this information has been submitted you will created a draft request. There will still be a few more pieces of information required (varies depending on partner and customer). The checklist on the upper right will guide you.
A request is made up one or more schedules and each schedule has one or more services. A schedule defines the start and end time for this part of the request as well as the location. Each schedule's services specify the types or provider and modality (as well as tracking the agreements that will impact billing).
While many requests only have a single date and time, the Octoo platform supports recurring requests (as well as requests with nonsensical scheduling) and requests that require different types of providers and modalities (on-site vs remote).
Let's examine a basic request for the "50th Birthday Party" as an example. This request will take place on a single date and time and needs two interpreters. In our application, the hierarchy of this request would look like this:
[REQ#1] "50th B-Day Party"
[SCHED#1] Monday, December 5th from 5p to 8p @ Betty's house
[SVC#1] Two hearing language interpreters (on-site)
Now let's look at "Phsyics 101 w/lab". This request is a recurring request with two classes every week plus one lab (which is at a different time and location!). Also, the request needs not only two interpreters but also a CART provider (but only for the classes). The two hearing interpreters will be in-person but the CART provider will be remote.
In our application, this would be represented like:
[REQ#1] "Phsyics 101 w/Lab"
[SCHED#1] Monday, December 5th from 2p to 5p @ Bldg B RM 301
[SVC#1] Two sign language interpreters (on-site)
[SVC#2] One CART provider (remote)
[SCHED#2] Wednesday, December 7th from 8p to 12p @ ACME Labs RM 888
[SVC#3] Two sign language interpreters (on-site)
[SCHED#3] Monday, December 9th from 2p to 5p @ Bldg B RM 301
[SVC#4] Two sign language interpreters (on-site)
[SVC#5] One CART provider (remote)
In addition to the schedule and service details a request also can to specify additional details:
Consumer(s) (required): one or more consumers who will be using the service providers (if it's a public event that's fine, just list the consumer as "General public")
On-site contact(s) (required): this is the person the provider should contact during the particular schedule; sometimes it's the same as the person making the request but it doesn't have to be
Qualifications (optional): applying a qualification impacts the order in which providers are considered (with those meeting the qualifications considered first); if a qualification is marked as required then only those providers possessing that qualification will be considered
Lists: a list is a collection of providers and can be applied to a request in four different ways (see the section on lists for more details)
Once all the required attributes of the request are present and the rest of the settings are satisfactory the request can be submitted.
