Review of eLogii, Route Optimization and Delivery Execution Vendor

By Léon Levinas-Ménard

Last updated: November 4, 2026

eLogii is cloud software for route optimization, field-service scheduling, dispatch, delivery tracking, and proof of delivery. Operated by Brisqq Ltd, it assigns jobs to drivers or technicians, produces routes, and exchanges operational data with external business systems. Its customers include distributors, delivery operators, and organizations managing recurring field visits. (1, 16)

Overall score: 5.5/10

Dimension	Score
Supply chain depth	5.2/10
Decision and optimization substance	5.4/10
Product and architecture integrity	5.6/10
Technical transparency	6.4/10
Vendor seriousness	4.8/10

eLogii has a substantive routing product, unusually informative public operating documentation, and named customer evidence of reduced planning labor. It publishes route-construction heuristics, configurable objectives, an execution API, and practical limitations. Its customer cases report changes in staffing requirements and transport expense. (2, 11, 21, 22)

Its principal technical weakness is the gap between the economic problem and the model used to select routes. The system can report tiered transport charges after planning while excluding those charges from optimization. Its cost inputs can also be repurposed as preference weights. That makes an apparently cheaper route potentially more expensive under the customer’s actual tariff. (3)

The operating model creates further responsibilities for dispatchers: maintaining constraints and exceptions, calibrating timing assumptions, preserving original ETA predictions, and checking routes after manual intervention. These are consequential parts of the product’s total cost and reliability. They also limit the stronger claims of automatically delivering the most economical, service-compliant plan.

eLogii versus Lokad

eLogii decides how known jobs should be assigned and sequenced across available field resources. Its public API exposes operational entities and optimization jobs, allowing routing to become part of a larger automated process. The driver application then supports execution and records what happened. (11, 29)

Lokad’s quantitative supply chain approach addresses the economics of decisions under uncertainty, including purchasing, inventory allocation, production, and replenishment. A decision is evaluated through its expected financial consequences across possible futures. The principle also applies to transport: the cheapest expected outcome depends on delivery failures, overtime, damage, customer commitments, and the value of scarce capacity.

The difference becomes concrete when an additional shipment would push a carrier bill into another tariff band. A route selector using only a fixed amount plus distance and time cannot faithfully price that choice. An accurate invoice estimate displayed afterward arrives too late to guide the initial decision. The economic model must participate in the search for a better action.

The two products can occupy different parts of the same operational system. eLogii supplies dispatch and field execution; Lokad supplies decision logic with a broader economic perimeter. Integration still requires an explicit division of responsibility for quantities, priorities, delivery commitments, and transport decisions.

Maintenance is part of that comparison. eLogii documents a configurable application and support services. Lokad’s managed inventory optimization assigns Supply Chain Scientists to data preparation, economic logic, monitoring, and production maintenance. Introduction to Supply Chain develops the underlying perspective. The relevant cost includes the people who keep either system’s decisions correct as operating conditions change.

The optimization mechanism and its economic limits

A documented heuristic engine

The September 2026 engine documentation identifies a fast Base engine and a more configurable Advanced engine. The latter exposes insertion methods including cheapest insertion, regret, nearest-neighbor, and variants that diversify starting solutions. Users can control search duration and initialization. (2)

These are recognizable heuristic techniques for constructing and improving feasible routes. Randomizing parts of the search explores alternative solutions; it does not create a probabilistic forecast of future traffic or service times. The useful technical question is whether the routes remain economical when the assumptions behind their estimated durations and costs prove wrong.

The Advanced engine also accepts ordered objectives. The default sequence prioritizes assigned work, then cost, fleet count, and early starts; users can replace or reorder objectives. (2) This ordering expresses a business policy. Serving one more job ahead of every cost consideration can be appropriate for a binding commitment, but expensive when the extra job has little value. A generic ordering cannot supply the missing commercial judgment.

Cost calculation is richer than cost optimization

eLogii’s cost-calculation module supports rate bands, dimensional charges, and rounding, also advertised on its analytics page. Its separate cost-based optimizer accepts fixed, time, and distance charges but excludes tiered and total tariffs, including dimensional costs. The richer charges can be calculated after a route is produced but cannot participate in selecting it. (4, 28, 3)

This is a model defect with direct financial consequences. Transport costs often change discontinuously: an additional vehicle, an overtime threshold, a minimum carrier charge, or a discounted band can alter the best decision. Improving the search within a simplified cost model cannot recover an economic factor the model excludes.

The documentation explains the exclusion by saying the final route is not yet known. Evaluating the cost of candidate decisions is precisely the purpose of optimization. The explanation describes a limitation of the implementation, not a reason that real transport economics must be simplified to fit it.

The same help article recommends assigning higher or lower driver costs to express preferences and warns that a vehicle with no configured cost is treated as free. (3) These choices require disciplined ownership. Once a monetary field carries an arbitrary preference, its numerical value no longer consistently represents an expense. A planner can improve the displayed objective while weakening the relationship with the actual transport bill.

The revenue module subtracts driver and vehicle costs from order value. (5) For a distributor, that calculation omits the purchase cost of the goods unless an appropriate contribution value is supplied elsewhere. Its result is not automatically the economic value of fulfilling an order. Revenue, transport contribution, and profit need distinct meanings if they are to guide decisions.

Constraints can be bypassed by manual intervention

The constraint model covers driver schedules, skills, vehicle capacity, time windows, zones, depots, and other operating restrictions. Its public documentation also explains how manual assignment or reordering can remove constraints and mark a route as unconstrained. The route remains in that state until a subsequent optimization can satisfy the constraints; violations can be displayed to the operator. (6)

That is a consequential operating boundary. A route that exists in the system is not necessarily feasible under the original restrictions. A dispatcher resolving one urgent problem can invalidate another commitment, such as a time window or available working time.

The Vergo account promotes optimization that always honors service levels. (23) The documented override behavior makes that assurance dependent on how the application is operated. A reliable deployment needs explicit authority for overrides, a recorded reason, and checks before revised instructions reach the field. Flexibility without such controls transfers feasibility assessment back to the dispatcher.

Uncertainty, ETA accuracy, and honest measurement

eLogii adjusts arrival estimates as routes progress. Its traffic-setting documentation distinguishes current-day live traffic from planning for a later day, and provides a manual scaling factor for estimated travel speed. (7) These mechanisms can improve responsiveness. They do not establish a calibrated joint distribution of travel times, service durations, customer absence, and new urgent work.

The distinction matters when several stops share the same source of delay. Independent time buffers may underestimate a congested corridor that affects an entire route. Leaving spare capacity everywhere can protect service at excessive cost. The required decision is how much flexibility is worth buying, where it belongs, and which commitments should receive it.

The ETA audit trail is a particular weakness. The live-update documentation says original ETAs are not automatically retained. A separate action saves planned estimates, but the timing settings explain that taking another snapshot overwrites the stored field. (8, 7)

An estimate made before dispatch and one revised shortly before arrival answer different questions. Measuring only the latest estimate can hide a poor original plan. A dependable evaluation needs timestamped predictions, their information horizon, the unchanged customer promise, actual arrival, and any intervening rescheduling. Customers can preserve this history externally; the documented defaults do not provide it automatically.

Porcelanosa’s case quotes greater than 95% accuracy in executing a route plan. The statement does not define the allowed timing error or prediction horizon. (22) It therefore cannot establish near-perfect forecasting. The customer’s reported reductions in labor and external-carrier expense provide a firmer economic basis for evaluating the deployment.

Productivity and the cost of maintaining configuration

Named deployments report substantial labor savings

Q Catering operates 26 vehicles with 30 drivers. Its case reports reducing an evening planning task from up to three hours to minutes, estimated at more than 750 hours annually, without expanding the fleet or headcount. (20) This connects automation to a specific recurring task and an identifiable operating scale.

J-Club’s merchandising operation spans more than 9,000 stores in 25 countries. Its case describes centralizing previously regional planning, freeing the equivalent of three full-time positions, and reducing annual driving by 300,000–400,000 kilometers. The labor benefit is primarily regional managers recovering time, rather than three documented dismissals. The same case projects capacity for a business three to four times larger; that remains an anticipated scalability benefit. (21)

Porcelanosa reports 50% fewer planning FTEs for the same order volume, 25% less spending on external delivery companies, and an 81% reduction in planning time. Its account also identifies the commercial importance of avoiding damage to ceramics when selecting external transport. (22) The combination of a comparable workload and monetary expenditure makes this evidence stronger than an isolated efficiency percentage.

These cases show that a specialized routing engine can remove substantial manual coordination. The next productivity question concerns the work left behind: exception handling, integration repair, changes to territories and tariffs, and validation after configuration updates.

Configurability creates a continuing engineering workload

Custom optimization can temporarily override the organization’s defaults for a particular run. (10) This makes experimentation possible, but also means identical-looking operations may use different decision policies. A configuration that works during ordinary weeks can behave differently during a seasonal peak, after a depot change, or when a major customer imposes a new service restriction.

There are concrete update semantics to manage. The general FAQ says configuration changes do not apply retroactively to existing tasks. Adding breaks after planning requires another optimization before the routes reflect them. (15) The cost manual separately says changing driver or vehicle rates after optimization requires tasks to be unassigned and reassigned for the new costs to be applied. (4)

These are maintenance costs and sources of operational inconsistency. Updating a setting is only part of the change; somebody must identify and refresh the affected operational state. The integration should record which rules and rates produced a plan, and verify that pending work uses the intended version.

Automatic reoptimization reduces some manual work, but its behavior is configurable. Active tasks are excluded by default, and users can disable automatic changes or lock routes. (9) Such controls can protect commitments already communicated to drivers or customers. They also make automation dependent on a correctly maintained operating policy.

A useful productivity account would measure routine planning hours, time spent repairing exceptions, and the effort required to deploy a policy change safely. eLogii’s customer stories provide substantial evidence for the first; public evidence for the third remains thin.

Technology history and promise-to-delivery record

Period	Public proposition	Subsequent evidence
2018 Brisqq service	A cloud delivery business with named external service providers.	This establishes an operating and technical antecedent, without identifying today’s entire eLogii deployment.
May 2020	Cloud delivery software would lower entry costs and make routing more accessible.	Current API documentation and named customer operations support an established cloud product.
February 2023	ERP and CRM integration would automate information exchange.	Customer accounts describe implemented integration and centralized planning; the API remains publicly documented.
Earlier Vergo account	AI and ML would support large-scale planning and anticipated operating-cost savings.	The current page adds a CEO-attributed 3–4× ROI claim, while retaining much of the original forward-looking text.
2025–2026	More detailed configuration, cost, ETA, and engine documentation.	Named heuristics and explicit operating limitations make the product more inspectable.
Current product expansion	Service Operations is presented as forthcoming.	The site describes a roadmap for service contracts and recurring work; availability remains a future proposition.

Brisqq’s May 2018 data-processing addendum, the May 2020 cloud article, and the February 2023 integration guide trace a consistent logistics product. (17, 25, 26)

The Vergo progression is more informative than an AI label alone: a deployment announcement now has an attributed economic outcome. (23, 24) However, the current case does not provide the ROI denominator, measurement period, or recurring integration and configuration costs. The reported return cannot be independently reconstructed.

The same case promises the most cost-effective result while the detailed manuals identify omitted tariffs and configurable approximations. That is a material tension between commercial language and implementation. The public documentation is stronger evidence of the product’s boundaries than the claim that AI ensures the best outcome.

Current product navigation marks Service Operations as coming soon. (29) Subscription and service-lifecycle ambitions should be assessed when they have deployed mechanisms and outcomes. They do not expand the demonstrated scope of the routing engine today.

Software materials and security architecture

A partially visible stack with clear external dependencies

The public record identifies components at different dates and product boundaries:

Evidence	What it establishes
Brisqq’s May 2018 data-processing addendum	Historical service providers included AWS, MongoDB, Google, and messaging or monitoring services.
A developer’s first-person Brisqq employment account	React, Redux, Socket.io, and an API built with Hapi.
Current eLogii API	JSON resources, separate production and sandbox endpoints, and MongoDB-style query syntax.
Current mapping FAQ	Multiple navigation and geocoding providers, including Google, HERE, Mapbox, and others, with provider-specific charges.
Current operating product	A planning dashboard, field application, optimization service, and external-system integrations.

The engineering account describes historical Brisqq product work. Current database topology and solver implementation are not publicly specified; MongoDB-style API syntax establishes an interface convention. (17, 18, 19)

The more demonstrable cost issue is dependency management. Address resolution, mapping, mobile connectivity, notifications, and business-system integration each introduce charges or failure modes. The FAQ explicitly identifies extra costs for one geocoding option. (15) Software ownership costs therefore extend beyond the routing subscription even when customers operate no servers.

Useful access boundaries, with customer-dependent safeguards

The user-role documentation specifies restrictions on configuration and credentials. Managers cannot access API keys and webhooks, while operators can be limited to particular teams. It also says an operator assigned to no team can view and plan operations for all teams. (13)

That default requires deliberate administration: removing a team assignment does not necessarily remove access. The distinction matters when personnel or subcontractors should see only part of an operation.

The API supports organization-level and customer-level keys, and its documentation separates production and sandbox environments. (14, 11) These are useful boundaries for integration testing. The public descriptions do not fully specify operation-by-operation privileges, credential expiry, or how a compromised organization-wide integration is contained.

Webhooks offer authentication options including HMAC and OAuth, configurable payload fields, conditions, and retries. (12) These features can reduce exposed data and support authenticated delivery. Their effectiveness depends on configuration and the receiving application’s handling of duplicated or malicious requests.

The current corporate privacy notice explicitly excludes customer-platform processing from its scope and refers readers to separate service documents. (16) Its general security statements therefore cannot substitute for the application-specific isolation and access model. The relevant question is which data and actions remain reachable after an integration or user account is compromised.

Accountability and the scope of the economic claims

The pricing page says most customers obtain a three-to-fourfold return. (27) That is a strong general commercial claim, but the page does not expose its customer cohort, cost denominator, or calculation. The named case studies provide more useful operational detail than this aggregate assertion.

For a routing deployment, accountability can be concrete. Actual transport and labor expense should be compared with the previous process on equivalent workloads, while tracking failed visits, damage, lateness, and the cost of maintaining the configuration. A result obtained by relaxing a service promise or transferring work to another department is a different result from eliminating that work.

eLogii publishes enough detail to locate several responsibilities: economic rates, constraints, overrides, data synchronization, and evaluation history. Public evidence does not establish that the vendor assumes continuing responsibility for the financial adequacy of those settings. Customer success and software support are not a substitute for an identified owner of the decision model.

Supply chain score

Each dimension averages five equally weighted criteria. The overall score averages all 25 criteria.

Supply chain depth

Criterion	Score
Economic framing	5/10
Decision end-state	7/10
Conceptual sharpness on supply chain	5/10
Freedom from obsolete doctrinal centerpieces	6/10
Robustness against KPI theater	3/10

Average: 5.2/10.

Economic framing — 5/10. Driver and vehicle costs enter route selection, and named customers report transport savings. The omitted tariff structures materially weaken that framing. A cost-aware optimizer needs the customer’s actual marginal costs, including discontinuities and the consequences of failed service. (3, 4)

Decision end-state — 7/10. The system produces assignments and routes that reach field workers through an application and integration interfaces. This is an executable decision pipeline. Human intervention remains significant when tasks cannot fit, policies change, or commitments require overrides. (9, 11)

Conceptual sharpness on supply chain — 5/10. eLogii has a clear model of routing resources and constraints. The weaker part is the transition from route feasibility to economic desirability. Fulfilled visits, travel distance, resource utilization, and profit are related but different objectives. (3, 5)

Freedom from obsolete doctrinal centerpieces — 6/10. The product directly addresses dispatch decisions without centering the workflow on aggregate sales forecasts or S&OP meetings. Its dependence on configured priorities and local objectives nevertheless leaves commercial trade-offs embedded in settings that need continued human judgment. (9, 10)

Robustness against KPI theater — 3/10. Comparable-workload labor evidence is useful, but headline ROI and ETA claims lack important measurement definitions. Failure to retain original predictions automatically makes it harder to distinguish better planning from increasingly accurate updates after the journey has begun. (27, 28, 7)

Decision and optimization substance

Criterion	Score
Probabilistic modeling depth	2/10
Distinctive optimization or ML substance	6/10
Real-world constraint handling	7/10
Decision automation and labor productivity	7/10
Resilience under real operational complexity	5/10

Average: 5.4/10.

Probabilistic modeling depth — 2/10. Dynamic ETA updates and heuristic randomness do not establish a model of joint operating uncertainty. The public record does not show how distributions of delay, service duration, absence, or urgent arrivals determine the economically appropriate reserve capacity. (2, 8)

Distinctive optimization or ML substance — 6/10. Named construction methods and configurable search expose a substantive numerical mechanism. Its commercial differentiation rests on applying these methods to operational constraints. Claims of an invariably best result exceed the published method and its economic perimeter. (2)

Real-world constraint handling — 7/10. The operating model covers a broad range of field restrictions, with explicit handling of infeasible tasks and manual overrides. These mechanisms address actual dispatch complexity. The customer’s controls must preserve feasibility when operators override the original plan. (6)

Decision automation and labor productivity — 7/10. Customer cases connect automation to recovered management time, lower planning staffing requirements, and comparable workloads. That is substantial evidence of labor savings. Recurring configuration and exception-management costs remain less well quantified. (20, 21, 22, 24)

Resilience under real operational complexity — 5/10. Alternative objective orderings, per-run settings and a sandbox provide tools for testing revised routing policies. The missing workflow connects a costly decision to its underlying model error, compares a reformulated policy on preserved workloads and safely promotes or rolls back the correction. Excluded tiered tariffs impose a further limit: the documented settings cannot express that missing economic relationship. (2, 10, 11, 3)

Product and architecture integrity

Criterion	Score
Architectural coherence	6/10
System-boundary clarity	7/10
Security seriousness	5/10
Software parsimony and ownership cost	4/10
Compatibility with programmatic and agent-assisted operations	6/10

Average: 5.6/10.

Architectural coherence — 6/10. Planning, dispatch, tracking, and completion records fit a coherent product scope. Economic calculations are less unified: the richer reporting model and narrower selection model can disagree about what an efficient route means financially. (3, 4)

System-boundary clarity — 7/10. External business systems supply jobs, eLogii handles routing and execution, and results can be exported. This boundary is comparatively legible. Responsibilities for upstream priorities and downstream commitments still need to be made explicit in each integration. (11, 12, 26)

Security seriousness — 5/10. Public role restrictions, customer-scoped keys, and separate testing endpoints make some controls inspectable. Full containment of compromised credentials or integrations is less clear. Team membership and broad organization-level access require particular operational care. (11, 13, 14)

Software parsimony and ownership cost — 4/10. The focused product avoids an unnecessary enterprise-planning perimeter, but its many interacting settings create maintenance work. State refresh, tariff changes, route overrides, and mapping dependencies must be included in total cost. (9, 10, 15)

Compatibility with programmatic and agent-assisted operations — 6/10. Public APIs and events can support automated operation and external evaluation. The remaining gap is a fully reproducible cycle for changing decision policies: capturing configuration, testing consequences, promoting a change, and recovering the preceding behavior. (11, 12)

Technical transparency

Criterion	Score
Public technical documentation	7/10
Inspectability without vendor mediation	6/10
Portability and lock-in visibility	6/10
Implementation-method transparency	7/10
Evidence density behind technical claims	6/10

Average: 6.4/10.

Public technical documentation — 7/10. The help center explains settings, failure states, costs, and specific engine behavior. These details make the product materially assessable before a sales process. The underlying implementation and probabilistic assumptions remain incompletely exposed. (2, 3, 6)

Inspectability without vendor mediation — 6/10. A technical reader can inspect request formats and understand significant operating limitations publicly. Reproducing numerical behavior still requires access to the proprietary service, and the documented interfaces do not provide a complete independently executable specification. (11, 19)

Portability and lock-in visibility — 6/10. Operational records and costs can be retrieved through APIs and exports. Preserving a decision system also requires its policy history, configuration, and forecast vintages. Exporting the latest state does not by itself make past decisions reproducible. (4, 11, 7)

Implementation-method transparency — 7/10. Documentation explains how configuration changes interact with existing tasks and routes. Customer accounts describe integration and centralization work. That gives buyers a useful view of implementation mechanics, although less of the recurring engineering effort after deployment. (15, 26)

Evidence density behind technical claims — 6/10. Named deployments, detailed manuals, and an extensive integration surface support the product’s substance. The weaker evidence concerns broad AI superiority, universal service compliance, and aggregate financial returns. (2, 20, 24, 1)

Vendor seriousness

Criterion	Score
Technical seriousness of public communication	4/10
Technology roadmap integrity	6/10
Conceptual sharpness	5/10
Economic accountability	4/10
Defensibility in an agentic-software world	5/10

Average: 4.8/10.

Technical seriousness of public communication — 4/10. The manuals candidly expose limitations that the commercial claims gloss over. Explaining missing nonlinear tariffs as a consequence of not yet knowing the route confuses an implementation restriction with the problem optimization is meant to solve. (3, 1)

Technology roadmap integrity — 6/10. Cloud routing and integration have identifiable delivery and adoption evidence. More recent numerical documentation adds substance, and the Vergo account has acquired an attributed outcome. The contribution of AI claims and the economics of forthcoming extensions remain less established. (25, 26, 2, 24)

Conceptual sharpness — 5/10. The routing domain is well specified, but arbitrary preferences can be encoded in monetary fields and reactive estimates can be confused with predictive reliability. Stronger separation of economic costs, operational priorities, and measurement horizons would improve the decision model. (3, 7, 8)

Economic accountability — 4/10. Customer savings are commercially relevant. The published record does not establish a recurring obligation to keep route-selection policies economically valid or a reproducible basis for the broad ROI claim. Configuration ownership remains central to whether returns persist. (20, 27)

Defensibility in an agentic-software world — 5/10. Established routing behavior, constraint handling, integrations, and mobile execution provide useful product substance. The opportunity is to automate configuration maintenance and improve decision economics. An additional conversational interface would not repair the current cost-model and evaluation gaps. (6, 11, 3)

Sources

All sources were accessed on November 4, 2026. Undated customer pages are current statements; historical dates refer to the identified source or edition.

[1] eLogii product homepage

eLogii product homepage. current November 2026.

[2] Optimization engines

Optimization engines. 2026-09-23.

[3] Cost-based optimization

Cost-based optimization. current November 2026.

[4] Cost calculation

Cost calculation. 2025-05-12.

[5] Revenue calculation

Revenue calculation. 2024-04-08.

[6] Constraints and unconstrained routes

Constraints and unconstrained routes. 2026-02-03.