Building access and setup
Allow time for parking, building access, security checks and setup in addition to the drive.
GEOWISE MCP & API
Location-aware
scheduling for
AI agents
GeoWise checks travel time and staff availability before your agent offers an appointment.
Use the REST booking flow or request MCP access for your agent. Confirm enabled tools and scheduling policies during onboarding.
Current foundation: service zones, staff availability and booking APIs. Sections marked proposed describe the next stage of the engine.
✓ Your product controls the conversation and customer experience.
Can this booking fit?The worker has visits booked at 9am and noon.
Sample scheduleCustomer address
Drag the green pin or choose an address above
10:0010:3011:3012:00
10m
New visit · 60m
15m
B
Travel New visit Booked visit
✓Fits the route
+5 minadded driving
11:45arrival at next visit
15 minbefore next visit
This example uses fixed travel times and runs without the API.
THE INFRASTRUCTURE LAYER
Fits your existing
booking flow
Your agent supplies a service and customer location. GeoWise’s booking API provides coverage, quotes and time slots for the configured business.
Your product
Handles the conversation, customer
identity and booking experience.
GeoWise scheduling engine
Checks coverage and availability,
then handles the booking workflow.
Your operational systems
Supply staff, shifts, service details,
existing bookings and field updates.
UNDER THE HOOD
What gets checked
before offering a time
An appointment is available only when the work, the travel and the rest of the schedule fit together.
THE DECISIONCURRENT FOUNDATION & PROPOSED EXTENSIONSWHAT YOUR AGENT GETS
01 Coverage
Current: service-zone coverage for a coordinate. Proposed: address-confidence checks integrated into each scheduling decision.
Coverage result and zone02 Eligibility
Current: staff assignments and availability. Proposed: joint eligibility checks for skills, equipment, crews and continuity.
Staff returned with available slots03 Availability
Current: service, location and configured schedule feed the slot lookup. The demo illustrates travel before and after a new visit.
Available slots for the request04 Route fit
Proposed: rank feasible options by added driving, idle time, overtime, customer preference and capacity for later demand.
Proposed: route-aware ranking05 Pricing
Current: service price, duration and currency. Proposed: configurable location fees, call-out rules and scheduling incentives.
Service quote with an expiry06 Change
Current: booking lookup, rescheduling and cancellation operations. Proposed: automatic recovery after overruns or staff absences.
Booking changes; proposed recovery options✓ The full decision model is a product direction. Confirm the checks and policies enabled for your operation before making customer promises.
SCHEDULING MODES
Scheduling policies
Explore three scheduling policies. These local examples show the intended customer promise; policy availability and configuration are confirmed during onboarding.
BACK-TO-BACK WITHIN SERVICE ZONESBack-to-back visits
Back-to-back visits
within each zone
Offer the next appointment close to work already booked in that zone. Each team follows a chain of nearby visits, with travel time reserved between them.
CUSTOMER PROMISE“We can be with you at 10:08.”
Choose the travel limit, gap between visits and when to offer appointments outside the preferred cluster.
A team’s scheduleIllustrative schedule
09:0011:0013:0015:0017:00
Each visit takes 60 minutes. Times and travel are illustrative; select a zone to follow its team.
COVERAGE & CAPACITY · PROPOSED ADAPTATION
Service zones based on
workload and travel
Start with configured service zones and staff assignments. The proposed adaptive engine would compare boundary changes by travel, workload and available skills.
1
Define coverage
Define service-zone boundaries. Demand-based proposals are part of the adaptive direction.
2
Assign staff & workdays
Connect crews, skills, shifts and the areas they cover.
3
Set scheduling & pricing rules
Choose modes, durations, buffers and protected commitments.
4
Connect your existing schedule
Agree how existing bookings and field updates enter the schedule, and which system owns changes.
Service area plan3 teams
Team A
52%
Team B
86%
Team C
63%
Team B is at 86% capacity while Team A is at 52%.
Sample utilisation · proposed boundary change, not measured results
BUILT FOR YOUR STACK
Connect through
MCP or API
The REST API includes slots, holds and bookings. For MCP, confirm the enabled tool list and authentication during onboarding. The explorer shows the workflow; it sends no requests.
ILLUSTRATIVE RESPONSE EXCERPT Feasible options
Business-scoped credentialsExpiring holdsBooking recordsVerify retries and conflicts before launch
BUILD VS. INTEGRATE
What you take on
when you build it
A route solver helps order the visits you already have. Taking new bookings also means reserving capacity, handling conflicting requests and keeping existing appointments feasible as the schedule changes.
THE FIRST IMPLEMENTATIONWHAT YOU KEEP RESPONSIBILITY FOR
Check a calendar
Travel in both directions, service duration, breaks and every affected appointment.
Suggest an appointment
Route impact, specialist availability and competing uses of the remaining capacity.
Accept the booking
Concurrent requests, expiring reservations, safe retries and recovery from failed writes.
Re-optimise the day
Protecting customer promises and making each permitted change explicit.
Support another business
Independent permissions, data, operating rules, service areas and integrations.
Start with GeoWise’s scheduling and booking foundation. Agree the supported policies, capacity ownership and failure handling so your team can focus on the receptionist and customer experience.
Evaluate the enginePROPOSED · BEYOND THE FIRST BOOKING
Use actual travel
and service times
The next-stage engine would learn from completed visits: travel, access delays and service time by address, service and team. These are proposed capabilities, with no release commitment.
Capacity for later requests
Consider likely demand before consuming a scarce specialist or the last useful window in an area.
Travel and service buffers
Use observed travel and service variability to set buffers appropriate to each kind of visit.
Delays and staff absences
After an overrun or absence, compare reassignments and time changes by their effect on customers.
Recurring and shared visits
Preserve recurring relationships, coordinate multiple workers and account for the weeks ahead.
Scheduling priorities
Choose how much weight to give travel, punctuality, continuity, workload and margin when ranking feasible options.
METHODS & EVALUATION
How the scheduling
model works
These notes explain the availability checks, zone planning and evaluation method, including what to measure when comparing GeoWise with your own implementation.
INFRASTRUCTURE PRICING
Pricing per
scheduled booking
Explore an illustrative per-booking model, then confirm the commercial terms for your integration.
✓ Configured availability checks✓ Hold and booking workflow✓ Business-scoped setup✓ MCP/API access agreed at onboarding
Set up your account ILLUSTRATIVE USAGE ESTIMATEGet started Illustrative USD estimate before tax, not a binding quote. Confirm MCP/API pricing, included usage and volume terms during onboarding.
$0.80/ scheduled booking
Discuss volume terms for platforms and larger operations.
At this illustrative rate$800 / month
Can this sit behind our existing AI receptionist?+
Yes, through an agreed integration. Your receptionist gathers the service and location and presents returned options. Confirm your account’s MCP tools or REST access during onboarding; your product keeps its conversation and brand.
Do we need to move our CRM or use your booking interface?+
You can keep your customer experience. Agree how operational records are synchronised and which system owns booking writes. A recommendation-only arrangement needs your own reservation and conflict handling.
What if no appointment fits?+
Handle empty results and errors explicitly, then ask for another day or check coverage. Wider windows, alternative-team ranking and waiting lists belong to the proposed decision model; do not assume they are enabled.
Does it need live GPS?+
The scheduling example uses booked locations and fixed durations, without GPS. Live tracking and field updates require a separately configured integration; verify their availability and freshness for your account.
Can one integration serve multiple businesses?+
API credentials are scoped to a business. Each business needs its own configured staff, services and zones. Agree account provisioning and usage reporting before rolling out a multi-business integration.
How are simultaneous requests handled?+
The API provides expiring holds and checks hold status during booking. Before launch, test overlapping requests, retry behaviour and writes from other systems. A hold alone is not a claim of end-to-end conflict protection.
Add location-aware scheduling
to your product
Create your account, then confirm API access and the scheduling policies your integration needs.