# Overview Octoo is a scheduling application for language service providers. The Octoo application is a robust system for managing requests for different types of service providers (e.g., interpreters, CART, etc). Octoo provides tools to **partners** (e.g., an interpreting agency), **providers** (e.g., a sign language interpreter), and **customers** (e.g., a hospital), to make requests, find qualified providers, and process billing all from a single application. {% hint style="info" %} **The Octoo application is currently in closed beta** * For demo requests, contact * For technical support, contact {% endhint %} ## Basic workflow A *partner* uses Octoo to onboard both *providers* and *customers*. During the onboarding process, the partner would establish agreements and terms with both parties. A *customer* then makes a new request for services, and the Octoo application will curate a list of considered providers to broadcast the request. Providers respond to the request with their interest (or decline the opportunity) and are assigned to the service by the partner or customer. After the service is complete, provider invoicing and customer billing is generated automatically based on the agreements. # Terminology {% hint style="info" %} Below is some of the terminology we use here at **Octoo**. {% endhint %} * **User** - a *user* account reflects an individual with an email address and password (or Google Account) that can login and access the application. One user account can serve different purposes: they can be a *provider*, or a *team member* or *owner* of a customer, or a *consumer* of services. Regardless, one user has a single login via an email address. * **Partner** — a *partner* is the organization that is responsible for the filling a *customer*'*s* request with qualified *providers* and managing the *agreements* outlining how payment for these services will be provided. **Linguabee** is an example of a partner that is leveraging the Octoo system to manage thousands of requests every month across the United States. Partners subscribe to the Octoo platform in order to utilize its features to provide services. Please contact our care team if you are interested in joining Octoo as a partner. * **Customer** — a *customer* is a business, organization, or individual who is requesting and paying for services provided. A *customer* can work with different partners and maintain their own application settings and presences in Octoo. It is free for customers to use the Octoo platform; customers only pay for the services provided based on the agreement they have with various partners. A *customer* can be a large organization or an individual. At a minimum they must define one *owner* but can have multiple *team members* (different *users*) with varied permissions and degrees of access. * **Provider** — a *provider* is someone who is provides a service (e.g., sign language interpreting, spoken language interpreting, CART, or transcription services). Providers can work with different partners as well all on the same platform. It is free for providers to use the Octoo platform; providers are paid for services rendered based on the agreement they have with various partners. A single user can have multiple providers (e.g., a user could register as both a Deaf interpreter and a service support provider). * **Agreement** — an [*agreement*](/general/agreements) describes the rates and terms that a *customer* will pay for services and a *provider* will earn from services provided. * **Request** — a [*request*](/general/requests) encapsulates the all the information for a particular event that requires services. It will have one (or more) scheduled date and time and specify one or more service providers needed for that request. * **Broadcast** — a typical request will be [*broadcast*](/general/broadcasts) to considered providers. The Octoo application takes into account multiple criteria for who to contact for a specific request. It considers the customer and requester's personal preferences, the qualifications needed for the request, the provider's availability for the specific date/time, the distance of the provider, the provider's feedback rating and responsiveness on the platform. Once the considered provider list is created and sorted we will reach out to providers individually to see if they are available and interested. * **Opportunity** — we track a provider relationship to a job via their [*opportunity*](/general/opportunities)*.* After a provider is notified of a new opportunity, they can either *decline* opportunity or *express an interest*. If interested, the customer or partner be notified and can *assign* or *decline the provider.* # Support {% hint style="info" %} Email `support@octoo.com` for technical help with the Octoo *application* (i.e., the website itself). Please contact your partners directly for assistance with requests. {% endhint %} When there is a problem, we want to get it fixed as quickly as possible. Below are some tips for [general troubleshooting](#general-troubleshooting) as well as practical guidelines for [opening a support ticket](#asking-for-help) to get the answers needed fast. ## General troubleshooting There are a few things you can try if the application is behaving unexpectedly. These suggestions may help in some situations but not be effective in others. * **Refresh** — sometimes a simple reload of the page will get the application unstuck. * On most browsers you can use `CMD+R` (Mac) or `CTRL+R` (Windows/Linux) to perform a page refresh. * Using a mouse you can also click the :arrows\_counterclockwise: button. * **"Hard" refresh (force reload) —** when a basic refresh (above) does the trick you can next try a *hard refresh*. A *hard refresh* re-fetches all page components (even those that were cached for performance). It's a slower operation but can help in some instances. * Keyboard short cuts for a hard refresh vary across browsers and operating systems. Often on a Windows/Linux you can use `CTRL+F5` and on a Mac `CMD+SHIFT+R`. * You can also hold down `CTRL` (PC) or `SHIFT` (Mac) and select the :arrows\_counterclockwise: icon at the same time in most browsers. * **Logout and login** — if performing either refresh isn't fixing the issue it can sometimes be resolved by logging out and back in again. * You can logout from inside the drop down menu in the top-right of the application * Or by visiting: directly in your browser. * **Clear browser cache** — if a hard refresh isn't working, sometimes completely clearing the browser cache is required. * Steps to perform this vary from operating system and browser. * In Google Chrome, for example, you can go to `Settings > Privacy and security > Clear browsing data` and select the appropriate options. Or you can open your browser's developer tools (usually `F12` or `CTRL+SHIFT+I`), then right-click the refresh button and select "Empty Cache and Hard Reload". It's always helpful to have tried these steps before opening a support ticket as it is often the first question you will receive from our help staff. Depending on your problem it may resolve it. ## Asking for help There are a few key points to include when opening a support ticket to help get the problem resolved as quickly as possible: * Clear and descriptive summary * Detailed steps to reproduce the problem, expected behavior, what actually happened * Screenshots or videos (if unable to describe easily) * Exact error messages (screen shot or copy paste text) * Steps to attempted to remedy (e.g., refreshed page, logged in or out, tried a different browser) But taking a few extra moments to craft a fully formed question with valuable debugging information can actually get you an answer quicker. ## Example support request Here is an example support request that doesn't cut the mustard: ``` Help! It won't let me create a new consumer! ``` Our support team, in all likelihood, will not be able to help with this limited information and there are a few follow-up questions the support team will ask: * **what is the page/url?** (e.g., new request page, customer settings page, etc) * **what action is being done?** (e.g., buttons clicked, data entered, etc) * are there any **error messages?** * has the page been refreshed? what else has been tried? When we have to follow-up with these questions it will end up taking more of your time and the solution will be delayed. Instead, users can all include more information initially: ``` Help! It won't let me create a consumer. * https:://app.octoo.com/requests/xx-xx * Clicked on Details -> add new consumer * Entered name "Patient 0", email left blank * Clicked "OK" and got the following error message: "There is no Patient 0" Usually this operation works! I tried a hard refresh as well as logging in and logging out. ``` With this information, the support team can immediately start trying to reproduce and address the error. ## Other tips: * Provide short bulleted list of steps needed to reproduce problem * Include any error messages (screen shot or copy paste) * If "nothing happens" (e.g., no error messages or unresponsiveness) we will ask: 1) did you refresh page? 2) did you log in or out? 3) what browser are you using (and did you try other browsers)? None of this has to be pretty or overly detailed—our team needs the basics for reproducing exactly what is happening. # Reference Codes Octoo uses reference codes to uniquely identify records within the site. A *reference code* is a unique identifier for a record in Octoo. It is used to quickly find items such as requests, invoices, jobs, and agreements. Reference codes are alphanumeric and prefixed with a letter that indicates the type of record. For example, `RQ12345` is a request. * `RQ` - Request * `AP` - AP Invoice * `AR` - AR Invoice * `PF` - Proforma Invoice * `JB` - Job * `AG` - Agreement * `SV` - Service Most email communications from Octoo will include the reference code in the subject line or body of the message. This makes it easy to find the related record in the system by searching (below). ## Search by reference code Either type of paste the reference code in the search box at the top of the page to quickly find the record. The search box is available on most pages in Octoo.

Empty search field

After entering the reference code, Octoo will display a match (if one exists). This search is not case sensitive so you can do either `rqabc12` or `RQABC12` and the result would be the same. If a match is found, click on the link to view the record.

Record match displayed

### Incorrect code or permission If you enter a reference code that cannot be found you see a message indicating the query didn't match any results. This could be because the code is incorrect or the record was destroyed.
NOTE: Sometimes the record you are searching for may have been removed or you may no longer have permission to view it. When this happens, Octoo will display a message indicating the reason after you locate the record.
### Partner Search Note that partner accounts have additional search features. You can read about them in the [Partners -> Search](/partners/search) section. # Agreements Agreements are a key component of the Octoo application where a partner can describe the rates and terms for their customers and providers. An **agreement** is a collection of rates and terms that define what a *customer* will be charged and a *provider* will bill for services provided. An **agreement** can be attached to *services*, *opportunities*, *schedules*, or *reservations*. When a *customer* makes a new request, the Octoo application will attempt to auto-bind the customer's *in effect* agreement to the services (and schedules) of the request. The same is true for when a provider *expresses interest* in a service: an in-effect agreement should be automatically attached. Reservations also use agreements. If a particular request requires unique rates or terms, a partner can modify that request's *one-off* agreement. These new rates/terms will only apply to that request. A *one-off* agreement can be labeled and re-used if it is needed. The customer service (or provider job) always gets its rates and terms from the attached agreement. ### Features * Zone based * Minimum in minutes * Floor in minutes * Mileage rate types (e.g., "Federal") * Auto-binding vs one-off * Pay schedules (e.g., office hours and after hours) * Base service rates * Add-on rates (e.g., holiday, legal) * Time-based policies (e.g., cancellation or short notice) * Slip policies (e.g., mileage, tolls, parking, travel, prep) ### A zone is a collection of compatible agreements A *zone* is a service area defined by a partner that contains a collection of providers and customers with compatible rates and terms. When services are added to a request, Octoo automatically searches for a compatible zone via the partner's *zone lookup*. This is a table that describes which zones apply to which locations and modalities (e.g, in-person or remote). The lookup is defined at a state, county, or city level. A default zone will be applied if there isn't a specific match. An **agreement** will be bound to a service/opportunity based on a matching *zone*. For example: if Customer A and Provider B have agreements in "Zone: NYC" we would expect both agreements to be (mostly) compatible in terms of slip, cancellation, short notice, and other policies and features of the agreements. That is: Provider B should be able to work for Customer A. If Customer C has an agreement in "Zone Washington State" we wouldn’t consider Provider B because the rates/terms are too different between the two zones (e.g., appearance fees, minimums, booking charges, etc are different in Washington than the Bay Area). So that’s generally the concept of a zone: *collection of compatible rates/terms between customers and providers.* ### Auto-binding vs one-off An **auto-bindable** agreement is the one that our system will automatically attach to new services/opportunities in the same **zone** and for the appropriate provider types. An *auto-bindable* agreement has an *in effect* date and only one can exist for a particular *zone*. If a partner attempts to create overlaping or conflicting auto-bindable agreements the system will raise an error. A **one-off** (manually assigned) agreement is on that a partner administrator can manually assign to a service/opportunity as needed (we call it **one-off** but it is re-usable). For example, Customer A allows providers to charge prep time—but only for certain requests. We would create a second agreement (called: "Customer A w/Prep Time") and make the required changes to this agreement to reflect prep time. This second agreement would **not** be *auto-bindable*. As needed, admins could swap the travel time agreement into a service. A customer or provider can only have **one** auto-bindable agreement for a given criteria. This way our system always knows which one to bind based on the date of the service. ### Minimum **floor** in minutes This is a little counter intuitive but it works in the same as the `minimum_in_minutes` only by setting a floor. For example, if the `minimum_floor_in_minutes = 60` (most common) this means the provider will not have any service slips for a job that is less than one hour long. It makes sense to be used in conjunction with another slip policy (e.g., in the case a 1.5 hour appearance fee charge). So if a provider works for only 30 minutes they would not bill any service slips (they would just get the "appearance fee" slip, from the example above). If they worked for 1.5 hours then would bill for 0.5 hours of service slips. ### Base Service Rate The **base service rate** is the primary rate charged for the services provided. Most **partners** will utilize only one **base service rate**; however, you can specific more than one (e.g., "regular" and "recurring"). Regardless, on **base service rate** must be set as the *default* rate. ### Add-On Rate An add-on rate "adds" to the base service rate. You can stack them. Services and opportunities have add-on rates *applied* to them based on criteria (e.g., holidays or corresponding with certain qualifications). An add-on rate can be waived (service-level or opportunity-level). If a provider agreement or customer agreement *does not support* the add-on rate it will *still be applied*. So a "holiday" will always appear tagged on the service/opportunity a "holiday add-on rate" even if there is no change to what the customer/provider is being charged. ### Time-based Policy A time-based policy is applied via one of three different methods: flat rate, pay schedule, or percentage. 1. **FLAT RATE**: a new slip is added to the **proforma** invoice for the flat rate amount. If a flat rate policy is *waived* a second slip will be added to reverse the charge. When a cancellation policy is flat rate *no additional service slips are added* (the flat rate takes the place of the service slips). A short notice flat rate is added *in adddition* to the regular service slips. 2. **PERCENTAGE**: \[CANCELLATION ONLY] applies a *discount* to each service slip on the proforma invoice. This discount reflects the percentage of the policy. If the policy is 100% no discount is applied and each service slip is charged in full. If the cancellation policy is set to be 50% then the service slips would be discounted by 50%. NOTE: we currently do *not* support short notice percentage based policies. 3. **RATE TABLE (Add-On)**: \[SHORT NOTICY ONLY] the rate table is consulted for this policy and is treated like an "add-on" rate increasing the serivce slip total. NOTE: we currently do not support cancellation rate table based policies. When a service/opportunity is created or cancelled time-based policies are automatically applied. They can also be waived. Unlike an add-on rate, a time-based policy is *not* applied unless the agreement calls for it. ### Pay Schedule Each account defines their own **pay schedule** (and there can be more than one). For example, perhaps an account has one "default" pay schedule that includes "weekday, "weeknight", and "weekend" rates. They may have a second **pay schedule** that only defines "office hours" and "after hours" rates. ### Slip Policies A **slip policy** defines how certain **slips** on the **proforma** invoices will be handles. Both provider agreements and customer agreements define their own slip policies and they can be contigent on one another. The following **slip types** can have policies: mileage, parking, tolls, travel time, prep time, booking charges, appearance fees. The policy can also have a *term* that restricts its usage. A policy can have a *minimum*, a *maximum*, a *floor*, and a *fixed* amount. For example, here are some possible combinations: * "Mileage - unrestricted" * "Mileage - maximum of 100 miles" (cannot bill over 100) * "Mileage - floor of 40 miles" (starts billing only after reaching 40 miles) * "Booking charge - $30 flat rate" A **slip policy** can also be *contingent* on the other party's policy. For example, the provider's agreement may have a "Mileage policy - contingent on customer". This means that if the customer supports paying for the mileage the provider can bill for it. However, if the customer does not, the provider cannot. If a **slip policy** is *not* contingent that means the provider/customer will always have it applied to their invoices. #### One-way billing A **slip policy** can have *one-way billing*. This means that the policy will *not* be shared between customer and provider. For example, a customer may have an internal policy that does not allow mileage to be included on their invoices. The one-way billing feature allow partners to circumvent it by paying providers the milage directly (one-way) without billing the customer. # Triggered Policies Octoo supports four different ways to count the time between a request and a cancellation or short notice event. Triggered policies in our API measure the time between when a policy is triggered and when a job starts. The system supports four different time type measurements, each serving different business needs. Understanding how these time types work is crucial for setting up appropriate notification and escalation policies. {% hint style="info" %} The "trigger" time for short notice policies is determined by the request's **Requested At** timestamp. See [Requested At Timestamp](/general/requests/requested-timestamp) for details on how this value is set and how it can be backdated by admins. {% endhint %} **Assuming the following business hours for all time calculations below:** * Monday through Friday: 8:00 AM - 5:00 PM * Weekends: Closed (Saturday & Sunday) * Holidays: Closed (when observed) Each partner can set their own business hours, but the default is as above. ## 1. Calendar Hours Definition: Measures the actual elapsed time in hours/minutes between trigger and job start, regardless of business hours, weekends, or holidays. How it works: * Counts every minute continuously * Returns the total number of minutes between trigger and start time * Rounds up to the nearest minute Examples: | Scenario | Triggered At | Job Starts At | Calendar Hours Result | | ------------------ | --------------------------- | ---------------------------------- | ------------------------ | | Same day | Friday 2:00 PM | Friday 4:00 PM | 120 minutes (2 hours) | | Over weekend | Friday 2:00 PM | Monday 2:00 PM | 4,320 minutes (72 hours) | | Over holiday | Thursday 2:00 PM (July 1st) | Monday 2:00 PM (July 5th, holiday) | 5,760 minutes (96 hours) | | Late night trigger | Thursday 10:00 PM | Friday 2:00 PM | 960 minutes (16 hours) | ## 2. Calendar Days Definition: Counts the number of complete calendar days between trigger and job start. How it works: * Only counts full days that fall completely between the trigger and start dates * Does not count the trigger day or start day themselves * Returns 0 if triggered and started on the same day Examples: | Scenario | Triggered At | Job Starts At | Calendar Days Result | | -------------- | ----------------- | -------------- | -------------------------- | | Same day | Friday 9:00 AM | Friday 5:00 PM | 0 days | | Next day | Thursday 2:00 PM | Friday 2:00 PM | 0 days | | Two days later | Wednesday 2:00 PM | Friday 2:00 PM | 1 day (Thursday) | | Over weekend | Friday 2:00 PM | Monday 2:00 PM | 2 days (Saturday & Sunday) | | Week span | Saturday 2:00 PM | Monday 2:00 PM | 1 day (Sunday) | ## 3. Business Hours Definition: Measures working hours between trigger and job start, only counting time during business hours. How it works: * Only counts minutes during business hours (8 AM - 5 PM, Monday-Friday) * If triggered on the same day as the job starts, returns 0 * If triggered outside business hours, calculation starts from the next business hour * If job starts outside business hours, calculation ends at the last business hour * Returns total business minutes (displayed as hours in policies) Important Business Hour Rules: * Business day starts at 8:00 AM sharp * Business day ends at 5:00 PM sharp * Triggers before 8:00 AM are treated as starting at 8:00 AM * Triggers after 5:00 PM are treated as starting the next business day at 8:00 AM Examples: | Scenario | Triggered At | Job Starts At | Business Hours Result | | --------------------- | ----------------- | -------------- | ------------------------ | | Same business day | Friday 10:00 AM | Friday 2:00 PM | 0 minutes | | Next business day | Thursday 2:00 PM | Friday 2:00 PM | 1,440 minutes (24 hours) | | After hours trigger | Thursday 10:00 PM | Friday 2:00 PM | 0 minutes | | Weekend trigger | Saturday 2:00 PM | Monday 2:00 PM | 0 minutes | | Early morning trigger | Wednesday 2:00 AM | Friday 2:00 PM | 4,320 minutes (72 hours) | | Cross weekend | Friday 2:00 PM | Monday 2:00 PM | 1,440 minutes (24 hours) | | Before business hours | Thursday 2:00 AM | Friday 2:00 PM | 2,880 minutes (48 hours) | ## 4. Business Days Definition: Counts the number of complete business days between trigger and job start. How it works: * Only counts full business days (8 AM - 5 PM periods) * A trigger before 8:00 AM counts that day as a full business day * A trigger after 8:00 AM does not count that day as a full business day * Does not count weekends or holidays * Returns 0 if triggered and started on the same day Examples: | Scenario | Triggered At | Job Starts At | Business Days Result | | ------------------------- | ----------------- | ------------------------ | -------------------- | | Same day | Friday 10:00 AM | Friday 5:00 PM | 0 days | | Early trigger, same week | Wednesday 2:00 AM | Friday 2:00 PM | 2 days (Wed & Thu) | | Normal trigger, same week | Wednesday 9:00 AM | Friday 2:00 PM | 1 day (Thursday) | | Over weekend | Friday 2:00 PM | Monday 2:00 PM | 0 days | | Early Friday trigger | Friday 7:00 AM | Monday 2:00 PM | 1 day (Friday) | | Weekend trigger | Saturday 2:00 PM | Monday 2:00 PM | 0 days | | Holiday Monday | Thursday 2:00 PM | Monday 2:00 PM (holiday) | 1 day (Friday) | | Multiple days | Monday 9:00 AM | Wednesday 2:00 PM | 1 day (Tuesday) | ## Special Considerations **Holidays** * Holidays are treated as non-business days * Calendar time types continue counting through holidays * Business time types skip holidays entirely **Weekend Handling** * Calendar Types: Count weekends normally * Business Types: Skip weekends completely ## Edge Cases 1. Same-Day Triggers: Business hours/days always return 0 if the trigger and start are on the same calendar day 2. After-Hours Adjustments: * Triggers after 5:00 PM are treated as starting the next business day at 8:00 AM * Triggers before 8:00 AM may count that day as a full business day (for business\_days type) 3. Cross-Weekend Policies: * Friday 2:00 PM trigger for Monday 2:00 PM start: * Calendar: 72 hours * Business: 24 hours (only counts Friday 2-5 PM and Monday 8 AM-2 PM) 4. 48-Hour Threshold: * Many business hour calculations use a 48-hour business time threshold * This equals 2 full business days or 6 full 8-hour business periods # Broadcasts At the heart of Octoo is a unique broadcast system for contacting qualified providers for requests. After a [*new request*](https://github.com/octoopi/docs-public/blob/main/general/customers/requests.md) is made the Octoo application begins curating a list of **considered providers** for this request. Partners manage this initial list of considered providers themselves; however, the application will automatically rank, sort, and *filter* these providers based on multiple criteria. These criteria include the requester's preferred lists for the requests, the preferred or required qualifications, both the provider and customer shared history, the relative distance (for on-site requests), the provider's expressed availability and conflicts with existing jobs, among other considerations. All of this information is used to identify the most appropriate provider (who is available) for the request and to contact them first. Of course, partners have full control over the generated list and can make overriding decisions based on the myriad information points available to them (all filter information is visible). ## Contacting providers Generally speaking, the broadcast system does not send out large email blasts to everyone at the same time for the same request. The goal of the platform is to reduce the number of unneeded emails that are sent to providers in order to improve provider experience and engagement. We aim to contact the right provider at the right time for the right job and have them confirmed as quickly as possible. Depending on how far the request is in the future, the platform will create one or more cycles that contact providers in intervals seeking their response. A provider will either decline the opportunity or express an interest and the system will move on to the next person (or group of people). ## Responding to provider interest After a provider has expressed interest the partner (or customer) will be notified and need to respond by either *assigning* the provider the job or *declining* their interest. Partners are able to determine *who* will be responsible for making these decisions (either the partner themselves or the customer/requester) and how the decision will be made (either manually, automatically, or a hybrid approach). By default, the partner will be responsible for responding to provider interest however it can be changed to the customer/requester as well as allowing for automatic responses from the platform. # Opportunities A customer's request is considered a new opportunity for a provider. The provider can express interest or decline the opportunity. {% hint style="info" %} Over time, the concept of tracking provider interest and assignment to requests has changed. We used to refer to this process as *bidding* and you may still see that word used from time to time. Originally, Octoo served as a way of connecting customers and providers directly (without a third-party partner). A customer would make a request and a provider could submit an actual "bid" (i.e., estimated costs) for the request. Now, most customers work with a partner to secure their services for requests and a partner can offer a provider the *opportunity* to take the job. {% endhint %} When a new opportunity is available, a provider can either *decline* it or express interest in it. If they are interested the partner (or customer) will assign them to the job. We track this opportunity through various possible *states.* * **DECLINED** — the provider is not interested in the opportunity (ends [broadcast](/general/broadcasts) attempts). * **PENDING** — the provider **is** interested in the opportunity and is waiting for a response from the customer or partner. * **CONTINGENT** — the provider has been assigned to the job is still waiting on other team members to be assigned before their services are confirmed. * **ASSIGNED** — the provider is assigned and the job is confirmed. * **CANCELLED** — the provider's assignment (assigned/contingent) has been released and the services are no longer needed. In some instances, based on provider/customer agreement's cancellation policies, a *cancelled* opportunity will be considered `CANCELLED_BILLABLE` indicating that even though the service was not performed the provider will still bill for some (or all) of the cost. * **NO SHOW** — this is to track when an *assigned* provider never appeared for the requested services. This does not happen very often. * **REPLACEMENT SOUGHT** — sometimes a provider or customer would like to replace an *assigned* provider *if possible*. The provider assigned is still considered to be *assigned* to the request (and if no replacement is found they will still perform the work). Unlike other states, this one is masked from some parties depending on the context. For example, if a provider is seeking a replacement the customer will not be informed unless a replacement is found. Vise versa, a customer seeking replacement will not alert the provider until the replacement is found. The admin for the account would also be able to see a replacement is being sought and who is seeking it. *** # Invoicing The Octoo invoicing system allows providers to earn and customers to pay their bills effortlessly. There are three different types of invoices: a **proforma** invoice, an **Account Receivable (AR)** invoice, and an **Accounts Payable (AP)** invoice. * **PROFORMA** — a **proforma** describes the total earned/billed for a specific service that a provider rendered. A **proforma** is attached to an **AP** and/or **AR** invoice for payment and contains one or more **slips** (line items) for services. * **AR** — an **AR** invoice is what customers are billed for services they have been provided. An **AR** invoice will contain one or more **proformas** as well as inidividual **slips**. * **AP** — an **AP** invoice is what providers submit to the *partner* for payment for services they have provided. An **AP** invoice will contain one or more **proformas** as well as individual **slips**. * **Slip** — a **slip** is a line item that goes on an invoice. {% hint style="info" %} In our legacy application a **proforma** was called a *service invoice*. {% endhint %} ### Proforma invoice The *proforma* invoice is what is generated for some kind of billable service. It can be attached to a `Bid` or a `Schedule` or a `Assignment` or a `Reservation`. It contains the *slips* that indicate who is earning or paying for what when it is finally attached to either an AP or AR invoice (or both). A *proforma* invoice is generated automatically by the API either: 1. When a job's outcome is finally published. 2. When a reservation shift is finished and all other *proforma* invoices related to the shift are submitted (this happens via a worker). 3. When a schedule/request is in the past (also via a worker). ### AR invoices Customers are sent **AR** invoices (bills). These bills contain one or more **proforma** invoices for services rendered as well as additional slips (if needed). **AR** invoices can be generated based on the customer's preferred schedule (after each service, every day, weekly, monthly, etc). Customers can also leverage **expense codes** (e.g., "purchase orders" or "authorization codes") that are entered during the new request process and brought over to the invoice. We also support uploading required financial documents during the new request process which will also be attached to invoices. #### Child AR Invoices Generally, AR/AP invoices only have *proforma* child invoices. However, there is one other special use case that allows for an AR invoice to *also* have a child AR invoice. A child AR invoice is created to "share" payments for the same proforma invoices with another customer. For example, let's say there is an AR invoice (#1) for Customer A that is for $2,000 total but there is an agreement that Customer B will split the payment. 1. API will generate the original AR Invoice (#1) that belongs to Customer A. All the *proforma* invoices on this AR alos belong to Customer A. Total due is $2,000. 2. An admin manually creates a new AR Invoice (#2) with no PFs attached and applies a `general` slip for the amount the second customer has agreed to share ($1,000). Invoice #2 would have different billing information than Invoice #1 (and could even have a difference customer). It only has one slip and no *proforma* invoices. 3. Admin then *manually attaches* Invoice #2 (child) to Invoice #1 (parent/original). 4. This act decreases the Invoice #1's `#outstanding_balance_units` by the amount that Invoice #2 is contributing (in this case $1,000). ### AP invoices After a provider has completed their services and confirmed them an AP invoice can be generated and will be paid by the partner in the agreed timeframe. ### Slips Most slips you see will be on **proforma** invoices (although they can go directly on AR/AP invoices as well and do sometimes). Each slip represents a line item charge for certain items: services rendered, mileage, tolls, prep time, booking fees, etc. Each **slip** is defined by its **slip type** (e.g., `service` or `mileage` or `reimbursement`). Some slips *require* a [pay schedule rate](/general/agreements#payschedule) (e.g., "weekday", "weeknight", etc) while others do not. A **pay schedule** informs the user about where the rate information is coming from. For example, a `service` slip with a **pay schedule** rate of "weekday" would inform the user they are being charged their weekday rate for that service. A slip has a `quantity` as well as a `rate` that tracks what is charged to a customer and billed by a provider. More information about billing is in the [agreements](/general/agreements) section. ### Time-based policies A proforma invoice is impacted by time-based policies that are applied to the service (provider and customer). See the agreement's [time-based policy](/general/agreements#time-based-policy) section for more information on how these are applied. ### # Requests A customer makes a request with a partner to secure qualified service providers. {% hint style="info" %} 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. {% endhint %} 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"). ## Creating a request 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. ![](https://1289211425-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSDEsicvUEa7h3PVCLlQC%2Fuploads%2F4k6llP5DjejOIk7dqgbX%2Fimage.png?alt=media\&token=fefdf8d8-4a1e-464f-accc-838ae1e8e74f) ### Basic request information 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. ### Adding dates/times and providers 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). #### Basic example for a single date/time and provider 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) #### More complex example 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) ### Additional required details 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](/customers/settings#lists) for more details) ## Submitting a request Once all the required attributes of the request are present and the rest of the settings are satisfactory the request can be submitted. When a request is submitted, the **Requested At** timestamp is set to the current time. This timestamp is used to calculate short notice policies and provider acknowledgement deadlines. Admins can also manually set this timestamp to an earlier time when entering requests that were received via email or phone. {% hint style="info" %} See [Requested At Timestamp](/general/requests/requested-timestamp) for details on how this timestamp affects policy calculations and acknowledgement deadlines. {% endhint %} ![](https://1289211425-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSDEsicvUEa7h3PVCLlQC%2Fuploads%2F8WzzbG6xfJkg7ECvUI2d%2Fimage.png?alt=media\&token=086215be-c8cc-4121-9ff9-434e3c093756) # Requested Timestamps Understanding the "Requested At" timestamp and how it affects triggered policies and acknowledgement deadlines. The **Requested At** timestamp is a critical value that determines when a request is considered to have been officially submitted. This timestamp drives two important calculations: 1. **Short Notice Policy** - Whether the request qualifies for short notice fees 2. **Acknowledgement Due At** - The deadline for partner to communicate with the customer about the request's status ## How Requested At Works ### Standard Workflow (Customer or Auto-Approved Requests) When a customer creates and submits a request (or when an partner creates a request that is automatically approved) the **Requested At** timestamp is set to the moment of submission or approval. ``` Request Created (Draft) → Submitted/Approved → Requested At = Now ``` **Example:** * Partner creates a draft request on Monday at 9:00 AM * Partner submits the request on Monday at 2:00 PM * **Requested At** is set to Monday 2:00 PM * All policy calculations use Monday 2:00 PM as the reference point ### Partner Backdating Workflow Partners sometimes receive requests via email, phone, or other channels before they can enter them into the system. In these cases, an partner can manually set the **Requested At** to reflect when the request was actually received. ``` Email Received (Friday 3pm) → Admin Creates Request (Monday 9am) → Requested At = Friday 3pm ``` **Example:** * Customer emails a request on Friday at 3:00 PM * Admin enters the request into the system on Monday at 9:00 AM * Admin sets **Requested At** to Friday 3:00 PM * All policy calculations use Friday 3:00 PM as the reference point {% hint style="info" %} When an admin manually sets the **Requested At** timestamp, that value is preserved throughout the request lifecycle. The system will not overwrite it when the request is submitted or approved. {% endhint %} ## Impact on Short Notice Policy Short notice policies determine whether additional fees apply based on how much lead time exists between the request and the scheduled service. The **Requested At** timestamp is the starting point for this calculation. **See:** [Triggered Policies](/general/agreements/triggered-policies) for details on time calculation methods. ### Example: 48 Business Hours Short Notice Policy | Scenario | Requested At | Service Starts | Lead Time | Short Notice? | | ------------------- | -------------- | ----------------- | ------------------- | ------------- | | Normal request | Monday 9:00 AM | Wednesday 2:00 PM | \~53 business hours | No | | Last-minute request | Monday 9:00 AM | Monday 4:00 PM | \~7 business hours | Yes | | Backdated request | Friday 3:00 PM | Monday 10:00 AM | \~11 business hours | Yes | In the backdated example, even though the admin entered the request on Monday, the short notice policy correctly applies because the **Requested At** reflects Friday 3:00 PM (the actual time the customer made the request). ## Impact on Acknowledgement Due At The **Acknowledgement Due At** is calculated based on the **Requested At** timestamp and determines when partners must acknowledge the request. ### Calculation Logic The acknowledgement deadline is calculated as: 1. Start with the **Requested At** timestamp 2. Add the configured lead time (e.g., 48 hours) 3. Round up to the next cutoff time (e.g., 4:00 PM) 4. If the result exceeds the service start time, use half the remaining lead time instead **Example with 48-hour lead time and 4:00 PM cutoff:** | Requested At | Service Starts | Initial Calculation | Final Acknowledgement Due | | -------------- | ---------------- | --------------------------------- | ------------------------- | | Monday 9:00 AM | Friday 2:00 PM | Wednesday 4:00 PM | Wednesday 4:00 PM | | Monday 9:00 AM | Tuesday 10:00 AM | Wednesday 4:00 PM (exceeds start) | Monday 9:30 PM\* | | Friday 3:00 PM | Monday 10:00 AM | Sunday 4:00 PM (exceeds start) | Saturday 12:30 AM\* | \*When the calculated deadline exceeds the service start time, the system uses half the available lead time instead. {% hint style="warning" %} If an admin backdates the **Requested At** timestamp, the acknowledgement deadline will also be calculated from that earlier time. This may result in acknowledgement deadlines that have already passed. {% endhint %} ## Technical Details For each service on a request, the system stores: * **Requested At** - When the request was officially submitted (drives policy calculations) * **Acknowledgement Due At** - Calculated deadline for provider acknowledgement * **Created At** - When the record was created in the database (for auditing) When a request is submitted or approved: * If **Requested At** was manually modified by an admin, it is preserved * If **Requested At** was not modified, it is updated to the submission/approval time * **Acknowledgement Due At** is recalculated based on the final **Requested At** value # User Accounts There are different types of accounts within Octoo, each of which can have different statuses at a given time. * **User** — This is the connection between a person's email/login and Octoo. It allows them to sign in to the application and access the site. If a user's account is **blocked**, they will not be permitted to sign in and will not receive any notifications or emails. * **Person** — This represents an individual and is associated with a name and email address. A person is usually connected with a **User**, but this is not required. A person may **suspend** their account on Octoo, which will stop all notifications and emails, but they will still be able to sign in to the application. A person can be associated with a provider and a customer (as a team member). * **Provider** — A provider account is associated with a partner, who can manage the provider's status. A provider can be **in progress**, **active**, or **inactive**. If a provider is flagged as **inactive**, they can still access the site and view their past job history, but they will not be able to express interest in new jobs or receive notifications of upcoming opportunities. This status is maintained by the partner, and a provider can have relationships with different partners. * **Customer** — A customer account is associated with a partner, who can manage the customer's status. A customer can be **active** or **inactive**. If a customer is flagged as **inactive**, their team members can still access the site and view their request and billing history, but they will not be able to create new requests. This status is maintained by the partner, and a user can be a team member on multiple customer accounts, each with different statuses at the same time. # Settings Providers have their own settings to manage their account and relationships with partners. Find provider-specific settings by clicking on the user icon in the upper right-hand corner of the site and choosing: *Account Settings*. Or visit: . Specific settings are available for each **partner** an account is linked with: these include [agreements](/general/agreements), [qualifications](/partners/qualifications), payment information, and [topic preferences](/providers/topic-preferences).
### Payment From the [user profile page](https://app.octoo.com/profile), follow the **payments** link and follow the links and instructions to setup a bank account.
### On-site Locations As a provider, there are two different types of locations our system relies on for on-site requests: **departure locations** and **job radius**. As a provider you need to have one of each defined. If you need to change an address, add the new location first before removing the old one. You can update these by visiting: . A **departure location** establishes the place you are departing from for on-site requests. It is used when calculating your estimated mileage to and from requests. At least one departure location is required for providers. You can define more than one if you have multiple residences and our application will rely on the closed location to the request when calculating estimated mileage. A **job radius** defines the area you would like to be notified about on-site requests. You can expand or narrow the radius of this area (and create different areas if a single circle doesn't encompass where you would like to travel to). If you are receiving jobs from locations that you do not want to travel to simply adjust this area of your preferences.
### Availability You can communicate your availability with the Octoo platform in two different ways: by defining either ongoing **weekly availability** or via specific **away** periods. Read more in the [availability section](#availability). ### Notifications Some types of **notifications** you can choose to opt-out of if you no longer wish to recieve emails. You can change those settings in this section. # Availability Providers can define their availability to partners. {% hint style="info" %} Availability is now managed from the calendar. See [Availability](/providers/calendar/availability) for the current documentation. {% endhint %} # Calendar Use Octoo's calendar to view upcoming and past jobs or subscribe to the calendar feed on your mobile phone or computer. ## In Octoo The calendar is available at [app.octoo.com/calendar](https://app.octoo.com/calendar). It displays a provider's jobs and opportunities in one place for a complete view of their schedule. Partners can also view a provider's calendar from the provider's profile.
Calendar week view showing jobs and opportunities with color-coded events and sidebar filters

The calendar in week view with the sidebar expanded, showing job and opportunity filters with a color legend.

### Views Switch between three views using the buttons in the top-right corner of the calendar: * **Day** — Shows a single day with hourly time slots. Use the arrow buttons to move to the previous or next day. * **Week** — Shows a full week (Sunday through Saturday) with hourly time slots. This is the default view. * **Month** — Shows a traditional monthly calendar with events listed on each day. Use the **today** button to jump back to the current date, or the **refresh** button to reload the calendar with the latest data. ### Events Jobs and opportunities appear as color-coded blocks on the calendar. The color legend is shown in the sidebar next to each filter: * **Green** — Assigned jobs that have been awarded to the provider. * **Yellow-green** — Contingent jobs where the provider is provisionally assigned but not yet confirmed. * **Orange** — Pending jobs that are awaiting confirmation. * **Pink** — Opportunities that are available for the provider to accept or decline. * **Gray** — Availability blocks showing times the provider has marked as unavailable. Each event displays the time range and the request name. Click on any event to see a detail popup with: * **Job status** — Whether the job is Awarded, Contingent, or Pending, with a link to the job record. * **Customer** — The customer organization for the request. * **Date and time** — The scheduled time in the selected timezone, with a link to the service. * **Request** — The request name, service type (e.g., Workplace - Meeting - Small group), and a link to the request. * **Location** — Whether the job is remote or on-site, and the city. * **Team members** — Other providers assigned to the same service, including their role and language pair. ### Sidebar filters Expand the sidebar using the menu icon to access filters and settings: #### Jobs filters Toggle which [Jobs](/providers/jobs) types appear on the calendar: * **Assigned** — Jobs that have been awarded to the provider. * **Contingent** — Jobs where the provider is provisionally assigned but not yet confirmed. * **Pending** — Jobs that are awaiting confirmation. Use **Deselect all** to hide all jobs at once, then toggle on only the types needed. #### Opportunities filters * [Opportunities](/providers/opportunities) — Show or hide available opportunities on the calendar. * **Hide declined opportunities** — When enabled, opportunities the provider has already declined will not appear. #### Settings Select a **Timezone** to display all calendar events in a preferred timezone. This is useful for providers who work across multiple time zones. ## Subscribe on a phone or computer Providers can subscribe to their Octoo calendar on their phone, tablet, or computer to integrate their schedule directly with their preferred calendar device. See [Subscribe](/providers/calendar/subscribe)for more information. # Subscribe Providers can subscribe to an iCalendar feed of their active jobs to integrate their schedule on Octoo with their calendar application of choice (computers or mobile phones). Providers can utilize an iCalendar feed to display their active jobs from Octoo on their computer or mobile phone using a calendar application of choice. This feature allows providers to easily integrate their jobs alongside their personal or other calendar events, making it easier to manage their time and commitments. ## About the iCalendar Feed To start, generate a secure token for the iCal feed from within Octoo: . The calendar URL is protected by a secure and unique token; the secure token will be included in the URL for the iCal feed, which will look like this: ``` https://api.octoo.com/v2/calendar/YOUR_SECURE_TOKEN/jobs.ics ``` If a device is lost or compromised, the provider can generate a new token to invalidate the old one, ensuring that their job schedule remains secure. {% hint style="danger" %} WARNING: The token is sensitive information and should be treated like a password. If someone gains access to a provider's token, they can view the provider's job schedule. Always keep the token secure and do not share it with anyone. {% endhint %} ### Token expiration Secure tokens have an expiration date (six months from the date of creation). After this date has passed, the token will no longer be valid, and a new token will need to be generated to continue accessing the iCal feed. An alert and warnings will appear within the calendar feed itself as a reminder to generate a new token before the expiration date. A new token can be generated at any time, and the old token will be invalidated immediately. This allows providers to maintain control over their calendar feed and ensure that it remains secure. ### Jobs included in the feed The `calendar/jobs.ics` feed includes all active jobs for the provider. It includes jobs looking back the past six months and includes all jobs in the future. The calendar feed is updated any time the provider's job status changes in the API (however, actual fetching/refresh is managed by the calendar client). It will include: * All active jobs (assigned, contingent, pending, and seeking replacement) * Title and topic and location of the job * Remote connection information (if applicable) * Team member information (if applicable) * Note that cancelled jobs are currently not included in the feed #### Creating multiple feeds with different filters Power users who want greater control over how their feeds work and look on their device can generate multiple URLs with different subsets of job information. For example, a provider may want one calendar that is green for awarded jobs and a blue calendar for the pending or contingent ones. Or perhaps they want to separate onsite from remote jobs.
## How to subscribe to the feed To subscribe to the iCalendar feed, use the secure token URL provided by Octoo. Each calendar application has its own method of subscribing to an iCalendar feed. The secure URL can be copied or one of the quick action buttons can be used.
{% hint style="info" %} NOTE: The calendar feed is read-only and only updated approximately once per hour. A timestamp from the last update is included in the body of the event. See FAQs for additional information. {% endhint %}
iOS Calendar App See the iOS [help document](https://support.apple.com/guide/iphone/use-multiple-calendars-iph3d1110d4/ios) for detailed information. * **Method One:** Open the Calendar app, tap on "Calendars" at the bottom, then tap "Add Calendar" and select "Add Subscribed Calendar". Paste the secure token URL provided by Octoo. * **Method Two:** Navigate to `Settings > Calendar > Calendar Accounts > Add Account > Other > Add Subscribed Calendar`, then paste the secure token URL provided by Octoo.
MacOS Calendar App See the MacOS [help document](https://support.apple.com/guide/calendar/subscribe-to-calendars-icl1022/15.0/mac/15.0) for detailed information. * Open the Calendar app, go to `File > New Calendar Subscription`. * Paste the secure token URL provided by Octoo into the `Calendar URL` field. * For the `Location`, select `iCloud` to sync with iCloud and all devices or `On My Mac` to keep it local. * Update `Auto-refresh` to `Every hour` or at a higher interval if desired (less than an hour is not recommended).
Google Calendar {% hint style="danger" %} Google typically updates subscribed calendar feeds every 8-9 hours (occasionally longer) and does not provide any mechanism for increasing the refresh rate. If more frequent updates are needed, consider using a different calendar application. {% endhint %} See the Google Calendar [help document](https://support.google.com/calendar/answer/37100?hl=en) for detailed information. * Open Google Calendar * Click on the `+` icon next to **Other calendars** * Select **From URL**, and paste the secure token URL provided by Octoo. * **Do not check** the box marked *make this calendar public*

Screen shot from Google Calendar

{% hint style="success" %} Google Calendar will report that the feed is 🔓 PUBLIC when viewing the event. This just means that anyone who has the feed URL can see the event details. Do not share this URL with anyone else. {% endhint %}
Microsoft Outlook See the Microsoft Outlook [help document](https://support.microsoft.com/en-us/office/import-calendars-into-outlook-8e8364e1-400e-4c0f-a573-fe76b5a2d379) for detailed information. * Open Outlook, go to `File > Account Settings > Internet Calendars` and click "New". * Paste the secure token URL provided by Octoo.
## Frequently Asked Questions (FAQ) Below are some common questions and answers about the iCal feed subscription feature:
Why aren't all past jobs included in the feed? The feed is limited to the past six months of jobs to keep the feed size manageable. A subscription feed is not paginated (that is, it loads all jobs at once), so including every past job can result in a very large feed that will continue to grow over time. For older jobs (going back to the beginning of time or before that), providers can always log into Octoo and view their job history there.
Why aren't job changes reflected immediately on the calendar? When a change is made in Octoo, the cache for the iCal feed is immediately updated in the API. However, each calendar application will refresh the feed at its own interval. This means that changes made in Octoo may not immediately appear in the calendar application. The iCal protocol is designed for periodic updates, not real-time updates, and doesn't allow for a "push" mechanism to notify calendar applications of changes.
Why aren't consumer names shown? Out of an abundance of caution, consumer names are not included in the iCal feed. This is to protect consumer privacy and ensure that sensitive information is not inadvertently shared through the calendar subscription. The feed will include job titles, topics, and locations, but not personal information about consumers. The link in the event description leads to the job brief where the consumer name and additional details can be found.
If I subscribe to this feed, will it overwrite my current calendar events? No, subscribing to the iCal feed will not overwrite existing calendar events. The iCal feed is read-only and will only add an entirely new event calendar to the app. It can usually be assigned a color and toggled on and off as needed. It will not interfere with existing calendar events or appointments and can be hidden at any time. Because it is read-only, the events cannot be edited or changed.
Can I copy the event to my own calendar? Yes, events can be copied to a personal calendar. Most calendar applications allow duplicating or copying events from a subscribed calendar to a personal calendar. This way, changes can be made to the event without affecting the original iCal feed. However, keep in mind that any changes made to the copied event will not be reflected in the original iCal feed.
Will I get a notification when an update occurs? No, notifications are not sent when an update occurs in the iCal feed. The iCal protocol does not support push notifications for updates. Providers will continue to receive updates via email or in-app notifications for job changes, but the iCal feed itself will not trigger any notifications.
Do I have to manually refresh the feed? No, manual refreshing is not required but is possible. Most calendar applications will automatically refresh the iCal feed at regular intervals (usually every hour). However, to see the latest updates immediately, the calendar can be manually refreshed in the application. The exact method for doing this will depend on the calendar application being used.
# Availability Manage availability directly from the calendar to control when providers receive opportunity broadcasts. Octoo's calendar-based availability system lets providers manage their availability directly from the [Calendar](/providers/calendar). Partners can also view and manage a provider's availability from the provider's profile. This replaced the legacy [Availability](/providers/availability) features of **Away** and **Weekly Availability**. ## How availability works Octoo uses availability information to contact providers at the right time with the right opportunities. When a new request comes in, the system checks each provider's availability before sending broadcast notifications: * **Not available** — The provider will not be emailed for any [Opportunities](/providers/opportunities) that overlap with the blocked time. However, these opportunities will still appear in the provider's **still available** list, so the provider can still express interest if their plans change. * **Remote only** — The provider will not be emailed for on-site jobs during the blocked time but will still receive email broadcasts for remote opportunities. Setting availability only affects automated email broadcasts. Partners can still manually assign a provider to a job during blocked times, and providers can still browse and express interest in opportunities from the [Opportunities](/providers/opportunities) page. ## How it looks on the calendar Both Away periods and Weekly Availability blockers appear as **"Not Available"** events on the calendar. Weekly blockers show as recurring time-based events, while Away periods show as all-day events.
Calendar week view showing availability blocks: Tuesday and Thursday 12-8pm weekly blockers and an all-day away on Saturday

The calendar showing migrated availability: weekly blockers on Tuesday and Thursday (12pm–8pm) and an all-day Away period on Saturday.

Availability events can be toggled on or off using the **Availability** filter in the sidebar. ## Adding availability There are two ways to add availability from the calendar: ### Using the button Click the **add availability** button in the top-right corner of the calendar to open the Create Availability modal.
Create Availability modal with fields for type, date, time, recurrence, and optional details

The Create Availability modal lets the provider set the type, date, time range, and recurrence pattern.

The modal includes the following fields: * **Availability Type** — Choose between **Not available** (the provider cannot work during this time) or **Remote only** (the provider is available but only for remote jobs). * **Event Duration** — Set the date, start time, and end time. Check **All day** to block off an entire day. Use **Change timezone** to enter times in a different timezone. * **Recurrence** — Set the event to repeat on a schedule: * Does not repeat (one-time event) * Daily * Weekly on a specific day * Monthly on a specific date * Every weekday (Monday to Friday) * Custom (for more advanced patterns) * **Add more details** — Optionally add a note about why the provider is unavailable. Click **Save** to add the availability event to the calendar. ### Dragging on the calendar Availability can also be added by clicking and dragging directly on the calendar grid to select a time range. This opens the Create Availability modal with the date and time pre-filled based on the selection.
Animated gif showing the drag-and-drop functionality on the calendar
## Legacy settings {% hint style="warning" %} The following settings were deprecated on March 24, 2026 and have been migrated to the calendar. {% endhint %} The legacy availability settings were previously configured from the provider's profile under **Settings > Availability**: ### Away (legacy) Away periods allowed a provider to block off specific date ranges when they were completely unavailable.
Legacy Away settings showing an away period for March 21-22

The legacy Away settings page under Settings > Availability > Away.

### Weekly Availability (legacy) Weekly blockers allowed a provider to define recurring times each week when they were not available (e.g., every Tuesday and Thursday from 12pm to 8pm).
Legacy Weekly Availability settings showing blockers on Tuesdays and Thursdays from 12pm to 8pm

The legacy Weekly Availability settings page under Settings > Availability > Weekly.

# Jobs After a provider is assigned to an opportunity it becomes one of their jobs. After a provider has expressed interest in an opportunity they are assigned to the job at the customer or partner's discretion. When a provider is assigned they will receive a job confirmation email with details including team members' names. Providers can view their upcoming jobs (and job history) at: [https://app.octoo.com/jobs](https://app.octoo.com/opportunities). ## Job statuses Each job has a status that reflects where it stands in the assignment process. | Status | Description | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Pending** | The provider has expressed interest in the opportunity but has not yet been assigned. | | **Awarded** | The provider has been assigned to the job and is confirmed to provide services. | | **Contingent** | The provider has been assigned but the assignment is contingent on finding additional team members. | | **Replacement sought** | The provider is currently assigned but has requested to be replaced. Their partner is working on finding a replacement. | | **Cancelled** | The provider has been removed from a job they were previously assigned to. | | **Declined** | The provider declined the opportunity and is not interested in providing services. | ## Viewing upcoming jobs Providers can navigate to their upcoming jobs from the dashboard or by visiting the [/jobs](https://app.octoo.com/jobs) section. When navigating from the dashboard, filters will be initialized to show all upcoming jobs.

Use filters to review all job history

To see only this week's jobs, providers can navigate to "My jobs this week". ## Removing from a job If a provider can no longer provide services for a job they have been assigned, they will need to initialize the job cancellation workflow. The provider should find the job through the [/jobs](https://app.octoo.com/jobs) section and select the three dots to the right to expose the contextual menu and choose "Cancel job". From there, the provider will need to answer a few questions and their cancellation request will be submitted to their partner. The partner will begin working on processing the cancellation and notifying the requester and team of the provider's absence.
Screen shot of the modal window asking for a cancellation reason and message to the requester
# Opportunities A provider can decline or express interest in opportunities. {% hint style="info" %} This page is specific to how providers interact with *opportunities*; there is also a [general overview](/general/opportunities) of this concept. {% endhint %} Once a provider's account is active with a partner they should start receiving new opportunities by email. Providers can either *decline* an opportunity or *express a interest*. If an interest is expressed, the partner and/or requestor will be notified immediately and either *assign* or *decline* your offer. Providers can view their opportunities at: . ### How are providers selected for new opportunities? The [broadcast system](/general/broadcasts) at Octoo is unique and powerful: it generally sends out one email at a time to providers in an ordered list based different criteria and filters. Sometimes large email blasts are needed for last minute requests, however, the goal of Octoo is to send as few emails as possible and reach the right provider for the job the first time. No one likes getting too many emails—that's why we aim to contact providers when they are available, qualified, a good fit, and the consumer will be excited to have them. ### Why did my colleague get an email about a job and I didn't? Because we do not send out blast emails to everyone, there are a number of different reasons why you may not have received an email about a job and someone else did. Our broadcast lists are ranked and sorted based on a number of factors including: customer/consumer preferences, qualifications, history with the customer, distance to the job, availability, provider's distance preferences, how often providers respond to our emails, and more. When a new request is made, a list of considered providers is generated and we start contacting the person on the top of the list. Depending on how far in the future the request is, we will wait minutes or hours for this provider to respond. If they decline the request (or enough time passes) then we move on to the next provider. This continues until the job is filled or we reach the end of the list. Providers cannot see these requests *until* their position in the list is reached. This is why you may not yet see a job that your colleague received an email about based on your position in the list. This system is designed to center the consumer's needs and preferences while also respecting the provider's time and availability. ### How do I view the terms of a new opportunity Beginning in March of 2023, providers can view individualized terms for your opportunities both in your broadcast emails and on the application itself. These terms are calculated using the anticipated (or actual) agreement for the specific job combined with the terms allowed by the customer who has made the request. While on the application in your [opportunities](https://app.octoo.com/opportunities) section of the site, you can click on "view terms" to see your anticipated terms before expressing an interest. ![](https://1289211425-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSDEsicvUEa7h3PVCLlQC%2Fuploads%2FLyjJvYlTawaIdCTZaGJ9%2Fimage.png?alt=media\&token=81f8d953-5671-455c-9341-bade832ca1a6) ![](https://1289211425-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSDEsicvUEa7h3PVCLlQC%2Fuploads%2F5wqfAAYsSejfLh7uxzAG%2Fimage.png?alt=media\&token=75f2092d-e067-4eb2-a080-85f88523890c) You will also see terms in other places: when you express interest, on your job brief, as well as on the request page. Terms will also be included in your broadcast and confirmation emails. ### What is the difference between "new" and "still available" opportunities? There are three tabs in the opportunities section: new, still available, and browse. ![](https://1289211425-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSDEsicvUEa7h3PVCLlQC%2Fuploads%2FpwIQc2XbzjkTU53mNIo6%2Fimage.png?alt=media\&token=9bcafd83-75f8-434e-9c75-4bcc2d19c341) **New Opportunities** — This section includes opportunities you haven't responded to yet and reflects the active opportunities your partner is still waiting for your response on. If you decline a *new* opportunity it will move to the *still available* section (unless someone else has filled the job) and you will stop receiving email notifications about it. If you express an interest, the *new* opportunity will remain visible here until the customer or partner responds. **Still Available Opportunities** — This section contains all the opportunities you have previously declined as well as those you have instructed the system you wish to ignore. For example, jobs outside of your [preferred mile radius](/providers/settings#on-site-locations) or during a period that conflicts with [your availability](/providers/settings#availability) or another job you have already taken. Your partner doesn't expect you to respond to these because the system has indicated your preference for you. But, if you are willing to travel farther than your mile radius or your availablitiy has changed you can express an interest. **Browse opportunities** — This section allows you to use custom filters to narrow down your existing *new* and *still available* opportunities in a single place. ### Why should I decline an opportunity instead of just ignoring it? When you *decline* an opportunity, we immediately move on to the next provider on our broadcast list and we will **also** stop emailing you about this particular request. Don't worry: you will still be notified of any new opportunities that come up! When you decline an opportunity it only applies to the specific one in the email. And you can change your mind: declined opportunities are always visible on the application. Just login to see. If you don't take any action from our emails, our system will wait a bit before it continues contacting the next person on the list. The amount of time varies based on the request. If you haven't responded, we may contact you a second or third time about the same request to see if you are interested or even text you if necessary. We also capture your reason for declining (e.g., that you are "not available" or "not a good fit"). All of this information is aggregated and used by our platform to make decisions about when to contact you next time so we don't bother you about requests you aren't interested in. The Octoo platform values *responsive* providers—that is, people actively responding to requests. The more *responsive* you are the more likely we will reach out to you in the future. By responding promptly to each request by either declining or expressing interest you are more likely to be contacted in the future. ### If I say I am unavailable for one job will I still stop being notified of all jobs at that time? Not currently. If you decline an opportunity and indicate your are "not available" it will not have an impact on other job notifications overlapping this same time period as the job you declined.. Your reason for declining is recorded and shared with your partner; however, this information is not used to restrict future broadcasts. S, if you said you are "not available" for a job from 2p-4p on Friday you may still receive notifications for new jobs 2p-4p on Friday (or 1p-5p or 3:30p-4p). ### I said I was interested: now what? Depending on the request settings either the requester/customer themselves or the partner will respond to your interest. There are some situations when you will be notified immediately after expressing an interest but most of the times there will be a delay before someone responds. If your interest is still *pending* this means the partner or customer has not responded yet. If you change your mind, you can always *withdraw* your interest before being assigned. # Payment Providers are paid after services are completed and confirmed. After a job is completed and services have been performed, providers need to take a few actions to receive timely payment. 1. **Review and close** the job by confirming start/end times and any incidentals 2. **Confirm proforma invoices** generated after first step one 3. **Convert and attach proformas to an invoice** 4. **Receive payment** {% hint style="info" %} If Information about adding or changing a bank account is in the [settings section](/providers/payment). {% endhint %} ## 1. Review and close After the job is finished providers need to *review and close* the job by confirming the actual start and end times of the services provided as well as any allowed incidentals (such as mileage). Providers will be notified by email automatically after the job's scheduled end time with a reminder to take this action. The email will also contain details about the expected timeframe for completing this task and requirements for any incidental billing. Providers can also initiate this process at any time from the web application in the **Review and Close** tab at .

Visit https://app.octoo.com/jobs to see jobs that need to be reviewed

If the provider does not review the job within the time period set by the job's partner (as indicated in the email) the job will be automatically confirmed *as-is*. {% hint style="success" %} If the job was cancelled (and billable) this step may be completed automatically and the provider can move on to [confirming the proforma invoice](#confirm-proforma-invoices). {% endhint %} ### Changing start and end times When the job is being reviewed providers can report any changes to the start and end time they actually worked and report any incidentals that were accrued. For example:

Example job confirmation screen

Once everything looks correct, the **Next** button will confirm the job and generate a proforma invoice. ### Audits Occasionally, the partner may choose to audit a provider's time periods or incidentals. If this happens the provider will be notified immediately after submission that the confirmation is being held while auditing takes place. A partner team member will resolve the audit and generate the *proforma* invoice. ## 2. Confirm proforma invoices Immediately after a job is confirmed (Step 1), and in the event that no audits were triggered, the provider will be able to immediately review the generated *proforma* invoice. A *proforma* invoice represents the actual billable quantities and rates based on the job confirmation and the agreement with the partner and customer. If all the details were entered correctly and the expected agreement is in effect, all the numbers should add up correctly. After reviewing the totals, the provider can *confirm* them.
If there are any problems or questions about the amounts on the *proforma* invoice the provider will need to reach out to their partner to have it fixed *before* confirming. ## 3. Convert and attach After a *proforma* invoice has been confirmed (either by the provider or automatically) it is eligible to be attached to an invoice. During the confirmation process a provider can continue on to view the recently created and confirmed *proforma* invoices or see all eligible *proforma* invoices in the **Unbilled** tab on the page. This page allows a provider to combine multiple *proformas* into a single invoice if they choose.

In this example the provider has 11 proformas ready to be billed

Select the proformas to bill by using the checkboxes next to each item and choose "Convert to invoice" along the top bar.

11 proformas ready to be converted

## 4. Receive payment After an invoice has been created by attaching unbilled *proformas* it will appear in the **Billed** section of . # Topic Preferences Providers can define their topic preferences to silence notificaitons for topics they are not interested in. Every request in Octoo is assigned a **Topic**. Topics help providers not only understand the request context but allow them to filter out [opportunities](/providers/opportunities) that are not of interest to them. Providers can define their **topic preferences** to silence notifications for topics they would rather not be emailed about. Each provider can set different preferences for each **partner** they work with. Preferences can be updated in a person's profile in the Topic Preferences section for your partner: ## Settings There are three settings a provider can choose from: * **YES** - The provider will receive opportunities by email for this topic. * **NO** - The provider will not receive opportunities by emails for this topic (but can still see the opportunity in the app). * **PREFERRED** - The provider will only receive opportunities by email for this topic if the customer has selected them specifically for the request. These settings only affect whether or not emails will be sent for certain topics. A provider can view all opportunities (regardless of their topic preference) opportunities section:
# Overview A **customer** is an entity on Octoo that is requesting and paying for services. Any user on the Octoo platform can establish a **customer** in order to request services. A **customer** does not have to be a *business* or an *organization*: an individual can be a **customer** too. Once a **customer** has a **partner** they can can begin requesting services. ## Basics * **OWNER —** A **customer** must have one (and only one) **owner**. This is the Octoo **user** who is ultimately responsible for managing the **customer** account. Ownership can be transferred; however, a **customer** must always have one **owner** at a time. * [**BILLING**](/customers/billing) — A **customer** must also define one **billing** person. This can be the same person as the **owner** or someone else entirely. The **billing** person is the default contact person for bills received and the person a **partner** will contact if they have questions about the bill. * **TEAM MEMBERS** — A **customer** can invite other people to join their customer account as a **team member.** Each **team member** can be assigned different **roles** that specify what the member can and can't do (permissions). You can add or remove members at any time. You can edit your team members by visiting: . # Billing Customers are billed by partners for services rendered. While the Octoo platform, itself, is free for customers to use, customers *are* responsible for paying their partners for the services rendered. Payment can be made by check or credit card. A customer must have a default billing contact that will be associated with all invoices. ## Expense codes {% hint style="info" %} An **expense code** is a way for customers to tag, group, or track requests and invoices. {% endhint %} An **expense code** is a customer-specific identifier assigned to a request and then invoice. It can represent any concept the customer wishes to track; common **expense codes** are "purchase order" or "cost center" or "authorization code". Once an expense code has been added to an **request** or **service** it will be automatically transferred to the related **proforma** or **invoice** during the billing process. By default, new customers will not have any **expense codes** defined. ### Creating a new expense code label {% hint style="warning" %} The ability to add/remove an expense code label for a customer is permission-based; if you do not see these options speak to your account lead about having permissions updated. {% endhint %} Customers can define an **expense code label** (e.g., "purchase order") by going to `Settings -> General -> Expense Codes`. When a customer account is managed by the partner directly, a partner can modify a customer's expense code by navigating to the customer's profile and browsing the settings page. ### Adding to a request Expense codes can be added to requests in the `Details` section. A request can have more than one expense code.

Example expense codes at the request level

### Adding to a service Most customers apply expense codes at the request-level; however, you can also add a separate expense code for every service in a request by selecting `Edit expense code` from the contextual menu next to the service details. You can see the code appended to the end of the service line or if you expand the service details using the `[i]`.
#### Automatically applying expense codes If the customer wishes to have the same code(s) applied to every new request, they can set up this feature in their customer settings in the billing section: ### Invoicing An expense code attached to a request will transfer to its related **invoice.** By default, each **invoice** will be *grouped* by the specific code so that all billed services for the code appear on the same invoice together. For example, if the customer was billed for all services rendered in November, those requests with the "ABC123" authorization code code would be grouped on a single invoice. This can result in one customer receiving multiple invoices for the same period based on the codes provided. ### Apply expense code to each proforma Thought less common, customers can apply the expense code to each proforma invoice (rather than grouping by AR invoice). When this is enabled each line item on the AR invoice will reflect a different expense code from the related **proforma**. This is useful when you are tracking something like a "Request #" that must be present on every date or service. ### Require expense codes for request submission Customers may choose to require that an expense code be present before a request can be submitted. This ensures that the correct billing information is always attached to the related proformas or invoices. Please speak with your partner about enabling this requirement on your customer account. # Consumers A consumer is the person (or people) who require services in a request. Every request must have at least one consumer — this is the person (or people) who will utilize the services of the request. Usually, each individual consumer would be listed separately as a request can have more than one; however, a consumer can be listed as a group of people (e.g., "general public"). All consumers are saved in the customer's account settings area and their names and details can be updated: ### Visibility By default, consumer names are *only* visible to confirmed providers. Providers being considered for a request will not be able to see the consumer names until they have been confirmed. Consumer information is also visible to the partner facilitating the request and the team members belonging to the customer account. {% hint style="info" %} If a customer account requires additional visibility restrictions (or would like to enable consumer names to be visible even to considered providers) this setting can be updated on a per customer basis. {% endhint %} ### Identifiers In addition to a name and an email address, a consumer can have additional *identifiers* (such as a medical record number). This information is optional. ### Contacting by email When a consumer is added an email address may also be recorded. Additionally, there is a checkbox to indicate whether or not it is okay for the request partner to contact the consumer as needed. {% hint style="info" %} If a customer account has a consumers they would like **automatically** notified by email about any request-related activity (e.g., requests made, providers assigned, etc) please contact the account partner to turn this feature on. This is still a beta feature and available upon request. {% endhint %} # Lists A list is a collection of providers that can be applied to new requests affecting how providers and broadcast and assigned. A **list** is a collection of providers you select that can then be *applied* to your requests (**preferred**, **restricted**, **last resort**, or **do not consider**). Lists can be applied automatically to new requests or manually on an as-needed basis. ### Creating a list When you **create a new list** you give it a name and add providers to it. For example, list such as: "my favorite people", "providers over six feet tall", "good for medical requests", or "uses too much perfume". {% hint style="info" %} A list can either belong to either a requester (person) or a customer. A requester's personal lists can only be modified by that person (it belongs to them); however, a customer's list can be modified by any personnel with the correct permissions *and* by an partner who is granted permission to manage the customer. {% endhint %} #### Personal lists As a requester you can manage your own personal lists and set **request defaults** for all your requests. These belong to you and can only be applied to the requests you have created. To modify your own personal lists as a requester, visit: . #### Customer lists A customer can also have lists that are available for use by all the team members. If a list is applied as a **request default** then all new requests for that customer will be assigned those lists (regardless of which person made the request). Not all team members can manage a customer's lists; they must have the correct permissions. To manage your customer lists, visit: . ### Applying a list Once the list exists, you can either *manually* apply it to a request in the draft stage or have it *automatically* applied as a **request default**. #### How lists impact broadcast and provider selection A list can be applied to a request in four different ways all which effect the [broadcast](/general/broadcasts) ordering. 1. **Preferred** — when applied as *preferred* these providers will be elevated to the top in our broadcast ordering. We will still contact other providers but these will get first dibs. 2. **Restricted** — when applied as *restricted* then **only** these providers will be broadcast. This will significantly reduce the ability for your partner to fill the request (depending on the list size). Other providers not on a *restricted* list will not be contacted. 3. **Last resort** — when applied as a *last resort* this will work in the opposite way as *preferred:* these providers will be moved to the bottom of our broadcast order and contacted last. 4. **Do not consider** — when applied as *do not consider* we will not contact or allow any of the providers on this list to be broadcast or see your requests effectively blocking them. #### Adding to a request When you are creating a new request you can manage which lists have been applied. Remember that your **default lists** (both customer-level and personal-level) are applied automatically; but you can always make changes before submitting the request. Click on the **details** tab on the request page and scroll down to add or remove lists.

An example of a preferred list already added

### # Settings There are specific settings for customers and personnel. A customer (or requestor) there are some settings you can adjust to your liking. ### Individual Notifications To modify your notification preferences for certain types of email contact visit: . If you uncheck those notifications you will no longer receive them by email. This is particularly useful if you no longer want to be notified when other *team members* make requests.

Example delivery notification settings page for a customer personnel

### Request Presets As a customer/requestor you can utilize the [applied list](/customers/lists) feature to ensure the providers you are looking for are considered first (or only considered) for your requests. To modify your own personal lists as a requester, visit: . Note that there are also applied lists at the *customer-level* (i.e., for all requests made under that customer). You can manage those settings at: . # Team Members A customer can have one or more team members. A customer can have additional team members beside the owner. Each team member can be assigned their own roles and permissions. A role is a collection of permissions that people assigned the role possess. Access you team members here: ### Inviting new team members Owners, as well as other team members with elevated permissions, can invite additional team members to join the organization and manager their assigned roles at By clicking on + Add Member on the top right of the team members section you can add a new member by email and assign them their roles. ### Joining multiple organizations One user can be a team member on multiple organizations with the same user account. When this happens, the user can switch between organizations by utilizing the context switcher in the top left portion of the screen. Click on the current active organization to switch to another one. ![](https://1289211425-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSDEsicvUEa7h3PVCLlQC%2Fuploads%2FOyKJ7kRw0FuoCiDQP26R%2Fimage.png?alt=media\&token=69320ef0-b7f3-41ef-b182-6f9eb72ab0c5) # Overview A partner subscribes to the Octoo scheduling platform to facilitate the scheduling, dispatch and billing of providers for their customers and providers. {% hint style="info" %} The **Octoo** scheduling system is still in a beta release phase and is not accepting new partners at this time. If you would like to be contacted when we open up the platform please email us at {% endhint %} # Qualifications A qualification is a way for a partner to identify providers with specific skills or attributes needed for certain requests and customers. Each partner has their own way of qualifying a subset of their providers for certain requests. The Octoo platform gives partners the flexibility to define their own qualification and parameters for meeting a qualification. When requests are made, the partner's custom defined qualifications can be applied to requests as needed and the broadcast order will be prioritized to target qualified providers first. Qualifications can also be *required* for certain requests ensuring that only providers that meet the criteria are selected. ### What is a qualification? A qualification can literally be *anything* the partner wishes to define! They can be based on something concretely recognized or an abstract concept. Here are some examples: * "Nationally Certified" * "NSA Security Clearance" * "Good with octopuses" ### Qualifications can require documentation **Qualifications** integrate with our **documentation** system and, as such, you can specify that a certain qualification depend on specific documentation to be in effect. For example, if you had a qualification named "HIPPA certification" it could be dependent on the provider possessing a document indicating that certification. Since the documentation system tracks expiration dates, if that provider's document were to expire their qualification would also lapse (until the documentation was updated). ### Qualifications can be designated for specific provider types or zones Not all qualifications make sense for every type of provider or zone. Octoo allows you to specify whether the **qualification** should be applied to all providers and zones or only a subset. For example, if you had a qualification that was "ProTactile" (for sign language interpreters working with DeafBlind consumers) it wouldn't make sense to apply it to a CART provider. Or, if you had a qualification that was "Approved by Illinois Chamber of Commerce" it wouldn't make sense to offer that qualification on requests in Albequeque. ### Providers have qualifications applied to them When a provider onboards with a partner, the partner can then apply their qualifications to the provider as they see fit. Adding the qualification to the provider is like giving them a little badge or special status. Now they will be eligible to be prioritized for broadcasts and for requests restricted to their specific qualifications. ### Customers can have qualifications set as new request defaults Some customers may require certain qualifications for all requests by deafult. A partner can assign those qualifications to the customer under their partner-based request settings. # Notes Notes are important tool partners can utilize to keep track of important information and share it with other members of their team. Partners have the ability to attach **notes** to various records on the Octoo platform. For example, a **note** can be added to a request, invoice, agreement, customer, provider, or cancellation (just to name a few). Each supported record can have more than one note. Along with a message, the author and timestamp is also recorded. Once a note has been created you can also **clone** or **archive** the note. **Notes** have a few special features: * **Pin**: if you *pin* a note that note will stay at the top of the list of notes for a given record. This is useful for records with a lot of notes. * **Share**: you can choose to have a note shared with other related records. For example, if you wrote a note on a *request* you can have that note shared with all the *invoices* related to that request. This way you only have to write the note once and have it appear multiple places. * **Tag**: you can use *tags* in your note by prefixing them with a `#` hash. For example, `#i-love-octoo`. * **Mention**: you can *mention* another user or customer via their *handle*. For example, using `@octoo` would create a clickable connection to us! * **Reference Code**: you can also indicate a specific *reference code* by prefixing it with the `^` symbol. For example, if you included `^RQABC123` it would insert a link to that request. ### Examples
# Search Partners have access to a global search for items related to their partner account. The search bar visible at the top of a partner account allows a user to search for people, providers, customers by name or email address. Search by reference code (e.g., `RQABC123`) is also supported and will take you directly to the item requested. You can also use more refined searches for *transactions*, *expense codes*, and *notes*.
### Reference code Either type of copy paste the reference code in the search box. This search is not case sensitive so you can do either `rqabc123` or `RQABC123` and the result would be the same.
### Name or email address Begin typing the name you wish to search for in the search box. After a pause in typing, the top ten results will be returned. Continue typing more of the name to narrow down the search.
### Transaction reference number If you are looking for a specific invoice transaction by reference number (e.g., the check number or vendor reference) preface your search with the words `txn:` return those results. Here are some examples: ``` txn:1234 # transactions matching `1234` txn:(check 4567) # use parenthesis to capture any spaces in the reference number FooBar txn:123 # transactions matching `123` where person/customer also matches `FooBar` ```
### Expense code Search for requests and invoices by expense code by using the `ec:` prefix in your search. Here are some examples: ``` ec:1234 # expensec does matching `1234` ec:(po 4567) # use parenthesis to capture any spaces in the code FooBar ec:123 # expense codes matching `123` where customer also matches `FooBar` ```
### Internal note Search for requests, schedules, services, invoices, and agreements by note comment by using the `note:` prefix in your search. Unlike an expense code or transaction search you cannot narrow down search results at this time. Here are some examples: ``` note:foobar # any note with the phrase "foobar" note:(foo bar) # use parenthesis to capture a space in the note ```
# Zones Partners can separate their service request and agreements into zones. A zone is a collection of considered providers and requests that share similar terms. Zones are the logical boundaries via geographic areas that Octoo uses to define service areas. They are the building block for determining which agreement (and therefore which rates and terms) apply to a specific service on a request. In Octoo, a specific location (like Main Street in Seattle, WA) belongs to a **zone** (e.g., "Pacific Northwest" or "Seattle Metro"). When a service is created, the system automatically determines the correct zone, which then determines which agreements can be applied, which then dictates the billing and payment rules. ## Partners define their own zones Each partner account in Octoo can define their own logical zones depending on business neeeds. Along with the zone, they also will define the *zone lookup* that will be used to automatically assign the zone to a service request. This allows partners to have different zones for different customers, locations, or modalities. ## Automated Zone Assignment When a request is created, Octoo uses a *zone lookup* to automatically assign the correct zone to the service. This ensures that the requester doesn't have to manually select a zone for every single request. The system looks for a matching zone in the following order of priority, from most specific to least specific: 1. **Customer-Specific & Location-Specific**: Is there a special zone defined specifically for this Customer in this City/County? 2. **Location-Specific**: Is there a general zone defined for this City/County? 3. **Customer-Specific & State-Wide**: Is there a special zone defined for this Customer in this State? 4. **State-Wide**: Is there a general zone defined for this State? 5. **Default/Nationwide**: If no specific geographic matches are found, the system applies the Account's default (often "Nationwide") zone. This hierarchy allows for granular control. For example, you can have a general "California" zone with standard rates, but a specific "San Francisco" zone with higher rates, and even a unique "Client X - LA" zone that only applies when that specific customer requests services in Los Angeles. ## Zones & Agreements Zones are the *key* that unlocks the correct service agreement. An agreement in Octoo is always tied to a specific zone and modality (i.e., on-site or remote). Once the zone is assigned to a service, Octoo finds the active **Customer Agreement** and **Provider Agreement** that match that zone. These agreements define: * **Rates:** The hourly rate, minimum duration, and billable increments. * **Travel:** Mileage rates and travel time policies. * **Terms:** Cancellation policies (e.g., 24-hour notice) and short notice premiums. ## Manually Changing a Service's Zone While the automatic zone lookup works for 99% of cases, there are scenarios where a partner is required to override the system logic. Partners can manually update the zone on a service to force the system to use a different set of agreements. ### Common Use Cases 1. **Travel Assignments:** A consumer and interpreter travel together from their home state (e.g., Texas) to a conference in Alaska. By default, the request location (Alaska) might trigger a "Nationwide" or "Alaska" zone. However, you want to pay the interpreter their local "Texas" rates. You can manually change the service zone to "Texas" to ensure local agreements apply. 2. **Shared Account Transfers:** You are creating a soft request on a shared account, but the automatic lookup doesn't match the zone required by the partner who will eventually take over the request. You can set the zone manually to ensure a smooth transfer. ### How to Change a Zone You can update the zone by using the three dots menu on the service detail. This action will: 1. Unbind the current agreements. 2. Search for agreements matching the *new* zone and apply them to the service if found. 3. Raise errors if there are assigned providers already present on the services. ### ⚠️ Important Caveat **You cannot update a zone on a service that already has active bids or assigned providers.** Because changing the zone fundamentally changes the contract (rates, cancellation terms, etc.), it cannot be done once a provider has been engaged. If you need to change the zone for a request that already has bids: 1. **Clone** the service (or request). 2. Change the zone on the new, empty service. 3. Re-assign the providers. # Privacy Policy Privacy Policy for the Octoo scheduling platform. Linguabee LLC ("us", "we", or "our") operates the website (hereinafter referred to as the "Service"). This page informs you of our policies regarding the collection, use and disclosure of personal data when you use our Service and the choices you have associated with that data. We use your data to provide and improve the Service. By using the Service, you agree to the collection and use of information in accordance with this policy. Unless otherwise defined in this Privacy Policy, the terms used in this Privacy Policy have the same meanings as in our Terms and Conditions, accessible from ### Definitions * **Service**\ Service is the website operated by Linguabee LLC * **Personal Data**\ Personal Data means data about a living individual who can be identified from those data (or from those and other information either in our possession or likely to come into our possession). * **Usage Data**\ Usage Data is data collected automatically either generated by the use of the Service or from the Service infrastructure itself (for example, the duration of a page visit). * **Cookies**\ Cookies are small files stored on your device (computer or mobile device). * **Data Controller**\ Data Controller means the natural or legal person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal information are, or are to be, processed. For the purpose of this Privacy Policy, we are a Data Controller of your Personal Data. * **Data Processors (or Service Providers)**\ Data Processor (or Service Provider) means any natural or legal person who processes the data on behalf of the Data Controller.\ We may use the services of various Service Providers in order to process your data more effectively. * **Data Subject (or User)**\ Data Subject is any living individual who is using our Service and is the subject of Personal Data. ### Information Collection and Use We collect several different types of information for various purposes to provide and improve our Service to you. #### Types of Data Collected **Personal Data** While using our Service, we may ask you to provide us with certain personally identifiable information that can be used to contact or identify you ("Personal Data"). Personally identifiable information may include, but is not limited to: * Email address * First name and last name * Phone number * Address, State, Province, ZIP/Postal code, City * Cookies and Usage Data We may use your Personal Data to contact you with newsletters, marketing or promotional materials and other information that may be of interest to you. You may opt out of receiving any, or all, of these communications from us by following the unsubscribe link or the instructions provided in any email we send. **Usage Data** We may also collect information on how the Service is accessed and used ("Usage Data"). This Usage Data may include information such as your computer's Internet Protocol address (e.g. IP address), browser type, browser version, the pages of our Service that you visit, the time and date of your visit, the time spent on those pages, unique device identifiers and other diagnostic data. **Location Data** We may use and store information about your location if you give us permission to do so ("Location Data"). We use this data to provide features of our Service, to improve and customise our Service. You can enable or disable location services when you use our Service at any time by way of your device settings. **Tracking & Cookies Data** We use cookies and similar tracking technologies to track the activity on our Service and we hold certain information. Cookies are files with a small amount of data which may include an anonymous unique identifier. Cookies are sent to your browser from a website and stored on your device. Other tracking technologies are also used such as beacons, tags and scripts to collect and track information and to improve and analyse our Service. You can instruct your browser to refuse all cookies or to indicate when a cookie is being sent. However, if you do not accept cookies, you may not be able to use some portions of our Service. Examples of Cookies we use: * **Session Cookies.** We use Session Cookies to operate our Service. * **Preference Cookies.** We use Preference Cookies to remember your preferences and various settings. * **Security Cookies.** We use Security Cookies for security purposes. ### Use of Data Linguabee LLC uses the collected data for various purposes: * To provide and maintain our Service * To notify you about changes to our Service * To allow you to participate in interactive features of our Service when you choose to do so * To provide customer support * To gather analysis or valuable information so that we can improve our Service * To monitor the usage of our Service * To detect, prevent and address technical issues * To provide you with news, special offers and general information about other goods, services and events which we offer that are similar to those that you have already purchased or enquired about unless you have opted not to receive such information ### Legal Basis for Processing Personal Data under the General Data Protection Regulation (GDPR) If you are from the European Economic Area (EEA), Linguabee LLC's legal basis for collecting and using the personal information described in this Privacy Policy depends on the Personal Data we collect and the specific context in which we collect it. Linguabee LLC may process your Personal Data because: * We need to perform a contract with you * You have given us permission to do so * The processing is in our legitimate interests and it is not overridden by your rights * For payment processing purposes * To comply with the law ### Retention of Data Linguabee LLC will retain your Personal Data only for as long as is necessary for the purposes set out in this Privacy Policy. We will retain and use your Personal Data to the extent necessary to comply with our legal obligations (for example, if we are required to retain your data to comply with applicable laws), resolve disputes and enforce our legal agreements and policies. Linguabee LLC will also retain Usage Data for internal analysis purposes. Usage Data is generally retained for a shorter period of time, except when this data is used to strengthen the security or to improve the functionality of our Service, or we are legally obligated to retain this data for longer periods. ### Transfer of Data Your information, including Personal Data, may be transferred to — and maintained on — computers located outside of your state, province, country or other governmental jurisdiction where the data protection laws may differ from those of your jurisdiction. If you are located outside United States and choose to provide information to us, please note that we transfer the data, including Personal Data, to United States and process it there. Your consent to this Privacy Policy followed by your submission of such information represents your agreement to that transfer. Linguabee LLC will take all the steps reasonably necessary to ensure that your data is treated securely and in accordance with this Privacy Policy and no transfer of your Personal Data will take place to an organisation or a country unless there are adequate controls in place including the security of your data and other personal information. ### Disclosure of Data #### Business Transaction If Linguabee LLC is involved in a merger, acquisition or asset sale, your Personal Data may be transferred. We will provide notice before your Personal Data is transferred and becomes subject to a different Privacy Policy. #### Disclosure for Law Enforcement Under certain circumstances, Linguabee LLC may be required to disclose your Personal Data if required to do so by law or in response to valid requests by public authorities (e.g. a court or a government agency). #### Legal Requirements Linguabee LLC may disclose your Personal Data in the good faith belief that such action is necessary to: * To comply with a legal obligation * To protect and defend the rights or property of Linguabee LLC * To prevent or investigate possible wrongdoing in connection with the Service * To protect the personal safety of users of the Service or the public * To protect against legal liability ### Security of Data The security of your data is important to us but remember that no method of transmission over the Internet or method of electronic storage is 100% secure. While we strive to use commercially acceptable means to protect your Personal Data, we cannot guarantee its absolute security. ### Our Policy on "Do Not Track" Signals under the California Online Protection Act (CalOPPA) We do not support Do Not Track ("DNT"). Do Not Track is a preference you can set in your web browser to inform websites that you do not want to be tracked. You can enable or disable Do Not Track by visiting the Preferences or Settings page of your web browser. ### Your Data Protection Rights under the General Data Protection Regulation (GDPR) If you are a resident of the European Economic Area (EEA), you have certain data protection rights. Linguabee LLC aims to take reasonable steps to allow you to correct, amend, delete or limit the use of your Personal Data. If you wish to be informed about what Personal Data we hold about you and if you want it to be removed from our systems, please contact us. In certain circumstances, you have the following data protection rights: * **The right to access, update or delete the information we have on you.** Whenever made possible, you can access, update or request deletion of your Personal Data directly within your account settings section. If you are unable to perform these actions yourself, please contact us to assist you. * **The right of rectification.** You have the right to have your information rectified if that information is inaccurate or incomplete. * **The right to object.** You have the right to object to our processing of your Personal Data. * **The right of restriction.** You have the right to request that we restrict the processing of your personal information. * **The right to data portability.** You have the right to be provided with a copy of the information we have on you in a structured, machine-readable and commonly used format. * **The right to withdraw consent.** You also have the right to withdraw your consent at any time where Linguabee LLC relied on your consent to process your personal information. Please note that we may ask you to verify your identity before responding to such requests. You have the right to complain to a Data Protection Authority about our collection and use of your Personal Data. For more information, please contact your local data protection authority in the European Economic Area (EEA). ### Service Providers We may employ third party companies and individuals to facilitate our Service ("Service Providers"), provide the Service on our behalf, perform Service-related services or assist us in analysing how our Service is used. These third parties have access to your Personal Data only to perform these tasks on our behalf and are obligated not to disclose or use it for any other purpose. #### Analytics We may use third-party Service Providers to monitor and analyse the use of our Service. * **Google Analytics**\ Google Analytics is a web analytics service offered by Google that tracks and reports website traffic. Google uses the data collected to track and monitor the use of our Service. This data is shared with other Google services. Google may use the collected data to contextualise and personalise the ads of its own advertising network. You can opt-out of having made your activity on the Service available to Google Analytics by installing the Google Analytics opt-out browser add-on. The add-on prevents the Google Analytics JavaScript (ga.js, analytics.js and dc.js) from sharing information with Google Analytics about visits activity. For more information on the privacy practices of Google, please visit the Google Privacy & Terms web page: #### Payments We may provide paid products and/or services within the Service. In that case, we use third-party services for payment processing (e.g. payment processors). We will not store or collect your payment card details. That information is provided directly to our third-party payment processors whose use of your personal information is governed by their Privacy Policy. These payment processors adhere to the standards set by PCI-DSS as managed by the PCI Security Standards Council, which is a joint effort of brands like Visa, MasterCard, American Express and Discover. PCI-DSS requirements help ensure the secure handling of payment information. The payment processors we work with are: * **Stripe**\ Their Privacy Policy can be viewed at ### Links to Other Sites Our Service may contain links to other sites that are not operated by us. If you click a third party link, you will be directed to that third party's site. We strongly advise you to review the Privacy Policy of every site you visit. We have no control over and assume no responsibility for the content, privacy policies or practices of any third party sites or services. ### Children's Privacy Our Service does not address anyone under the age of 18 ("Children"). We do not knowingly collect personally identifiable information from anyone under the age of 18. If you are a parent or guardian and you are aware that your Child has provided us with Personal Data, please contact us. If we become aware that we have collected Personal Data from children without verification of parental consent, we take steps to remove that information from our servers. ### Changes to This Privacy Policy We may update our Privacy Policy from time to time. We will notify you of any changes by posting the new Privacy Policy on this page. We will let you know via email and/or a prominent notice on our Service, prior to the change becoming effective and update the "effective date" at the top of this Privacy Policy. You are advised to review this Privacy Policy periodically for any changes. Changes to this Privacy Policy are effective when they are posted on this page. ### Contact Us If you have any questions about this Privacy Policy, please contact us: * By email: # Terms & Conditions Terms and Conditions for the Octoo scheduling platform. Please read these Terms and Conditions ("Terms", "Terms and Conditions") carefully before using the website (the "Service") operated by Linguabee LLC ("us", "we", or "our"). Your access to and use of the Service is conditioned upon your acceptance of and compliance with these Terms. These Terms apply to all visitors, users and others who wish to access or use the Service. By accessing or using the Service you agree to be bound by these Terms. If you disagree with any part of the terms then you do not have permission to access the Service. ## Communications By creating an Account on our service, you agree to subscribe to newsletters, marketing or promotional materials and other information we may send. However, you may opt out of receiving any, or all, of these communications from us by following the unsubscribe link or instructions provided in any email we send. ## Purchases If you wish to purchase any product or service made available through the Service ("Purchase"), you may be asked to supply certain information relevant to your Purchase including, without limitation, your credit card number, the expiration date of your credit card, your billing address, and your shipping information. You represent and warrant that: (i) you have the legal right to use any credit card(s) or other payment method(s) in connection with any Purchase; and that (ii) the information you supply to us is true, correct and complete. The service may employ the use of third party services for the purpose of facilitating payment and the completion of Purchases. By submitting your information, you grant us the right to provide the information to these third parties subject to our Privacy Policy. We reserve the right to refuse or cancel your order at any time for reasons including but not limited to: product or service availability, errors in the description or price of the product or service, error in your order or other reasons. We reserve the right to refuse or cancel your order if fraud or an unauthorized or illegal transaction is suspected. ## Availability, Errors and Inaccuracies We are constantly updating product and service offerings on the Service. We may experience delays in updating information on the Service and in our advertising on other web sites. The information found on the Service may contain errors or inaccuracies and may not be complete or current. Products or services may be mispriced, described inaccurately, or unavailable on the Service and we cannot guarantee the accuracy or completeness of any information found on the Service. We therefore reserve the right to change or update information and to correct errors, inaccuracies, or omissions at any time without prior notice. ## Contests, Sweepstakes and Promotions Any contests, sweepstakes or other promotions (collectively, "Promotions") made available through the Service may be governed by rules that are separate from these Terms & Conditions. If you participate in any Promotions, please review the applicable rules as well as our Privacy Policy. If the rules for a Promotion conflict with these Terms and Conditions, the Promotion rules will apply. ## Content Our Service allows you to post, link, store, share and otherwise make available certain information, text, graphics, videos, or other material ("Content"). You are responsible for the Content that you post on or through the Service, including its legality, reliability, and appropriateness. By posting Content on or through the Service, You represent and warrant that: (i) the Content is yours (you own it) and/or you have the right to use it and the right to grant us the rights and license as provided in these Terms, and (ii) that the posting of your Content on or through the Service does not violate the privacy rights, publicity rights, copyrights, contract rights or any other rights of any person or entity. We reserve the right to terminate the account of anyone found to be infringing on a copyright. You retain any and all of your rights to any Content you submit, post or display on or through the Service and you are responsible for protecting those rights. We take no responsibility and assume no liability for Content you or any third party posts on or through the Service. However, by posting Content using the Service you grant us the right and license to use, modify, publicly perform, publicly display, reproduce, and distribute such Content on and through the Service. You agree that this license includes the right for us to make your Content available to other users of the Service, who may also use your Content subject to these Terms. Linguabee LLC has the right but not the obligation to monitor and edit all Content provided by users. In addition, Content found on or through this Service are the property of Linguabee LLC or used with permission. You may not distribute, modify, transmit, reuse, download, repost, copy, or use said Content, whether in whole or in part, for commercial purposes or for personal gain, without express advance written permission from us. ## Accounts When you create an account with us, you guarantee that you are above the age of 18, and that the information you provide us is accurate, complete, and current at all times. Inaccurate, incomplete, or obsolete information may result in the immediate termination of your account on the Service. You are responsible for maintaining the confidentiality of your account and password, including but not limited to the restriction of access to your computer and/or account. You agree to accept responsibility for any and all activities or actions that occur under your account and/or password, whether your password is with our Service or a third-party service. You must notify us immediately upon becoming aware of any breach of security or unauthorized use of your account. You may not use as a username the name of another person or entity or that is not lawfully available for use, a name or trademark that is subject to any rights of another person or entity other than you, without appropriate authorization. You may not use as a username any name that is offensive, vulgar or obscene. We reserve the right to refuse service, terminate accounts, remove or edit content, or cancel orders in our sole discretion. ## Copyright Policy We respect the intellectual property rights of others. It is our policy to respond to any claim that Content posted on the Service infringes on the copyright or other intellectual property rights ("Infringement") of any person or entity. If you are a copyright owner, or authorized on behalf of one, and you believe that the copyrighted work has been copied in a way that constitutes copyright infringement, please submit your claim via email to , with the subject line: "Copyright Infringement" and include in your claim a detailed description of the alleged Infringement as detailed below, under "DMCA Notice and Procedure for Copyright Infringement Claims" You may be held accountable for damages (including costs and attorneys' fees) for misrepresentation or bad-faith claims on the infringement of any Content found on and/or through the Service on your copyright. ## DMCA Notice and Procedure for Copyright Infringement Claims You may submit a notification pursuant to the Digital Millennium Copyright Act (DMCA) by providing our Copyright Agent with the following information in writing (see 17 U.S.C 512(c)(3) for further detail): * an electronic or physical signature of the person authorized to act on behalf of the owner of the copyright's interest; * a description of the copyrighted work that you claim has been infringed, including the URL (i.e., web page address) of the location where the copyrighted work exists or a copy of the copyrighted work; * identification of the URL or other specific location on the Service where the material that you claim is infringing is located; * your address, telephone number, and email address; * a statement by you that you have a good faith belief that the disputed use is not authorized by the copyright owner, its agent, or the law; * a statement by you, made under penalty of perjury, that the above information in your notice is accurate and that you are the copyright owner or authorized to act on the copyright owner's behalf. You can contact our Copyright Agent via email at ## Intellectual Property The Service and its original content (excluding Content provided by users), features and functionality are and will remain the exclusive property of Linguabee LLC and its licensors. The Service is protected by copyright, trademark, and other laws of both the United States and foreign countries. Our trademarks and trade dress may not be used in connection with any product or service without the prior written consent of Linguabee LLC. ## Links To Other Web Sites Our Service may contain links to third party web sites or services that are not owned or controlled by Linguabee LLC Linguabee LLC has no control over, and assumes no responsibility for the content, privacy policies, or practices of any third party web sites or services. We do not warrant the offerings of any of these entities/individuals or their websites. You acknowledge and agree that Linguabee LLC shall not be responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any such content, goods or services available on or through any such third party web sites or services. We strongly advise you to read the terms and conditions and privacy policies of any third party web sites or services that you visit. ## Termination We may terminate or suspend your account and bar access to the Service immediately, without prior notice or liability, under our sole discretion, for any reason whatsoever and without limitation, including but not limited to a breach of the Terms. If you wish to terminate your account, you may simply discontinue using the Service. All provisions of the Terms which by their nature should survive termination shall survive termination, including, without limitation, ownership provisions, warranty disclaimers, indemnity and limitations of liability. ## Indemnification You agree to defend, indemnify and hold harmless Linguabee LLC and its licensee and licensors, and their employees, contractors, agents, officers and directors, from and against any and all claims, damages, obligations, losses, liabilities, costs or debt, and expenses (including but not limited to attorney's fees), resulting from or arising out of a) your use and access of the Service, by you or any person using your account and password; b) a breach of these Terms, or c) Content posted on the Service. ## Limitation Of Liability In no event shall Linguabee LLC, nor its directors, employees, partners, agents, suppliers, or affiliates, be liable for any indirect, incidental, special, consequential or punitive damages, including without limitation, loss of profits, data, use, goodwill, or other intangible losses, resulting from (i) your access to or use of or inability to access or use the Service; (ii) any conduct or content of any third party on the Service; (iii) any content obtained from the Service; and (iv) unauthorized access, use or alteration of your transmissions or content, whether based on warranty, contract, tort (including negligence) or any other legal theory, whether or not we have been informed of the possibility of such damage, and even if a remedy set forth herein is found to have failed of its essential purpose. ## Disclaimer Your use of the Service is at your sole risk. The Service is provided on an "AS IS" and "AS AVAILABLE" basis. The Service is provided without warranties of any kind, whether express or implied, including, but not limited to, implied warranties of merchantability, fitness for a particular purpose, non-infringement or course of performance. Linguabee LLC its subsidiaries, affiliates, and its licensors do not warrant that a) the Service will function uninterrupted, secure or available at any particular time or location; b) any errors or defects will be corrected; c) the Service is free of viruses or other harmful components; or d) the results of using the Service will meet your requirements. ## Exclusions Some jurisdictions do not allow the exclusion of certain warranties or the exclusion or limitation of liability for consequential or incidental damages, so the limitations above may not apply to you. ## Governing Law These Terms shall be governed and construed in accordance with the laws of Colorado, United States, without regard to its conflict of law provisions. Our failure to enforce any right or provision of these Terms will not be considered a waiver of those rights. If any provision of these Terms is held to be invalid or unenforceable by a court, the remaining provisions of these Terms will remain in effect. These Terms constitute the entire agreement between us regarding our Service, and supersede and replace any prior agreements we might have had between us regarding the Service. ## Changes We reserve the right, at our sole discretion, to modify or replace these Terms at any time. If a revision is material we will provide at least 15 days notice prior to any new terms taking effect. What constitutes a material change will be determined at our sole discretion. By continuing to access or use our Service after any revisions become effective, you agree to be bound by the revised terms. If you do not agree to the new terms, you are no longer authorized to use the Service. ## Contact Us If you have any questions about these Terms, please contact us at . # Accessibility Technology Accessibility Statement for the Octoo Scheduling Application Octoo is an application designed to make scheduling and arranging accommodations simpler and more accessible for people with disabilities. We are committed to continuously improving the accessibility of our technology for our customers, consumers, providers, and employees. Please let us know if you encounter any technological barriers or would like to request assistance. ## Contact Us * E-mail: * Voice: 844-546-4822 * VP/ASL: 855-585-5859 * Text/SMS: 855-585-0801 We welcome your feedback about the accessibility of this application. We do our best to reply to all communications within two (2) business days and can provide reasonable accommodations or modifications on a case by case basis. ## Commitment Our ongoing accessibility effort works towards being in line with the Web Content Accessibility Guidelines (WCAG) version 2.1, level AA criteria. These guidelines help make technology accessible not only to users with sensory, cognitive and mobility disabilities, but ultimately to all users, regardless of ability. Our efforts are just part of a meaningful change in making all services inclusive and accessible. ## Website Testing and Remediation * We conduct automated testing of our webpages for accessibility and quality assurance, using tools such as [axe](https://www.deque.com/axe/) to check for appropriate contrast and screen reader useability * We conduct manual testing during development and release phases of new features * We continue to test and remediate our digital products in an effort to provide continuous improvement of our sites and applications.