Skip to main content

​
Overview

The score engine is part of the optional teams, dispatch and missions module, used by operational verticals that send people to the field. When an event needs a response team, wede ranks your teams from the best match to the weakest. Each ranked team gets a score between 0 and 1, where a higher score means a better match. The top team is marked recommended: true. The ranking runs on the wede API. Your dispatchers see it in the dashboard, and sessions with the dispatch:assign permission can request it through the API.

​
What the ranking considers

For every candidate team, wede weighs:
  • Proximity: how close the team is to the event and how soon it can arrive.
  • Equipment: how much of the equipment the event requires the team has in operational condition.
  • Capability: whether the team covers the event’s vertical and event type.
  • Member availability: the share of the team’s members who are available right now.
  • Zone boundary: whether the event falls inside the boundary of the team’s zone. A team whose zone boundary does not contain the event ranks lower than a comparable team whose boundary does. It is not excluded, so it can still be dispatched when it is the best available option. Teams whose zone has no boundary are not affected.
The weighting between these factors is part of wede’s own technology and is not configurable.

​
Which teams are candidates

Only free teams are ranked. A team whose status is not available (for example a team already on a mission) is never a candidate, so a team that has accepted a mission is never sent to a second event. A team without members is never a candidate either: nobody would receive the mission. Teams left out are listed in excluded, each with team_id, team_name and a reason (no_members, no_coverage). Only events whose type sends a field team enter dispatch (requires_teams in your catalog). For such an event, the candidates are the teams of the event’s vertical that cover its type: a team covers specific types, or a whole category and so every type in it. A team that covers nothing for that type is excluded with no_coverage. The equipment and qualifications the type calls for (required_equipment) count in the score and are reported per team as missing_equipment; they never exclude a team, and an operator can always dispatch one, with a warning. A team does not need a live position to be ranked. wede uses the most recent position reported by the team’s members and, when there is none, the centre of the team’s zone. A team with no position at all is still ranked, but it is treated as the least favourable position, so it ranks below comparable teams whose position is known.

​
Ranking by event type

When a dispatcher requests a ranking for an event type from your catalog (POST /v1/teams/dispatch/action with action_id, lat, lng and optionally priority and event_id), wede returns the free teams in groups under tiers: Each group is sorted by score, and each team carries tier and missing_equipment. Use t1 first and t2 when no team covering the type itself is suitable. t3 is always empty and is kept for older clients. action_id is the id of the event type in your catalog. You can also request a ranking for an event with POST /v1/teams/dispatch/score, passing lat, lng and event_id: the response is { scored, count, excluded, required_equipment, by_coverage: true, event_type }, with scored sorted by score (tier 1 before tier 2), recommended: true on the first team, and tier and missing_equipment on each. Without event_id (or for an event whose type is not in your catalog) the same endpoint ranks every free team of your organisation for a location, with the optional vertical, event_type, priority and required_equipment.
Both ranking endpoints need a user session with the dispatch:assign permission (company_admin, operational_supervisor, corporate_client). API keys receive 403 forbidden.

​
Automatic dispatch

  • dispatch_mode: off (no field teams: events are delivered and nothing is dispatched), manual (wede ranks the teams and a person dispatches) or auto (wede dispatches the top team of group t1, or of t2 when no team covers the type itself). true and false are still accepted and read as auto and manual.
  • dispatch_threshold: the score (0 to 1) that marks ideal conditions. Default 0.70. The threshold never stops a dispatch: the best free team is dispatched all the same and a mission below the threshold is marked below_threshold, so a dispatcher can review it. The dashboard offers three levels: 0.80 (strict, flags more missions), 0.70 (standard) and 0.55 (permissive, flags only the clearly unfavourable cases). Any value from 0 to 1 can be set through the API.
An automatic dispatch creates the mission, records it in the audit log and sends a team.dispatched webhook with auto: true, tier and below_threshold. The ranking response reports what happened in auto_dispatch_mode, auto_dispatched, mission_id, requires_manual and threshold. Automatic dispatch also runs when an event arrives and every minute for events still waiting.

​
Automatic substitution

If a dispatched team does not acknowledge its mission in time, wede replaces it with another team. The event is never left waiting on a team that is not responding.
  • reinforcement_timeout_min: minutes to wait for the team to acknowledge. Default 10. Set it to 0 to turn substitution off.
wede checks every minute. When a mission is still CREATED or SENT after the timeout:
  1. The mission is set to FAILED with "feedback": { "reason": "no_acknowledgement" }, the team becomes available again, and you receive mission.status_updated.
  2. wede ranks the free teams that have not been called for this event yet and dispatches the top one. This creates a new mission and sends a team.dispatched webhook with substitution: true, mission_id, replaced_team_id and replaced_mission_id.
  3. If no free team is found, no new mission is created and the event returns to the dispatch queue, which you read with GET /v1/events?undispatched=true.

​
Changing the settings

Update the three settings with PATCH /v1/tenant/dispatch-settings:
The response returns the stored values: { dispatch_mode, dispatch_threshold, reinforcement_timeout_min }, with dispatch_mode as off, manual or auto and dispatch_threshold as a number. A dispatch_mode outside those values, a dispatch_threshold outside 0 to 1, or a reinforcement_timeout_min that is not a non-negative integer, returns 400 validation_error. Only users with the company_admin or company_tech role (and wede or country administrators) can change these settings. Every change is written to the audit log.

​
Offline dispatch requests

Field devices can queue dispatch requests while they are offline. When a device reconnects and syncs, wede ranks and dispatches those requests with exactly the same logic as live requests. The ranking itself always runs on wede, not on the device.