FAQ

Question 1

What is a Transportation Management System (TMS)?

Accepted Answer

A Transportation Management System is comprehensive software that orchestrates the entire freight lifecycle from initial planning and carrier selection through execution, tracking, delivery, and final settlement. Modern TMS platforms have evolved far beyond simple dispatch boards—they now serve as the operational backbone for logistics companies, integrating with accounting systems, telematics devices, load boards, and business intelligence tools.

EKA Omni-TMS™ represents the next generation of transportation management, built as a modular, API-first platform that serves carriers, brokers, and shippers simultaneously. Unlike legacy TMS systems that force rigid workflows, EKA adapts to how your business actually operates through configurable modules and real-time integrations. The platform combines automated dispatch, end-to-end visibility, embedded accounting, and AI-powered optimization in a unified cloud environment that eliminates data silos.

What makes modern TMS platforms truly transformative is their ability to act as a headless system, separating the presentation layer from the data and business logic layer, allowing companies to customize user experiences while maintaining robust backend functionality.

Question 2

How is EKA different from legacy TMS platforms like McLeod, TMW, or PCS Software?

Accepted Answer

The differences between EKA and legacy TMS platforms are fundamental, not incremental. Traditional systems were built 20-30 years ago when freight operations looked completely different—before smartphones, before cloud computing, before AI, and before the API economy. These platforms require 3+ months for implementation because they were designed as monolithic systems where every component is tightly coupled. When you want to change one thing, you risk breaking everything else.

EKA deploys in 2-6 weeks because our modular architecture treats each function—dispatch, accounting, visibility, compliance—as an independent module connected through clean APIs. You’re not paying per-user licenses that penalize growth; our load-based pricing aligns costs with revenue. While legacy systems create operational bottlenecks, EKA’s API-first design connects seamlessly with modern tools your team already uses: Samsara for telematics, QuickBooks for accounting, DAT for load boards, and Triumph (formerly Denim) for instant carrier payments.

The operational impact is dramatic. Legacy platforms require manual data bridges—someone downloads a CSV from the TMS, reformats it in Excel, then uploads it to accounting. EKA’s effortless integrations eliminate these manual touchpoints entirely. When your driver confirms delivery in their ELD, the shipper sees it instantly, accounting generates the invoice automatically, and your financial optimization system updates cash flow projections in real-time.

Explore our complete integration ecosystem

Question 3

What makes EKA an AI-native TMS?

Accepted Answer

Being “AI-native” means artificial intelligence isn’t bolted onto an old system as an afterthought—it’s woven into the platform’s fundamental architecture from day one. Many vendors are adding ChatGPT-style interfaces to legacy systems and calling it “AI-powered,” but that’s like putting a touchscreen on a typewriter. Real AI-native platforms require three foundational elements that most TMS implementations completely miss.

First, you need a clean data spine—consistent data models, instrumented workflows, and complete audit trails. If your system doesn’t know the difference between a customer and a carrier (yes, this happens in legacy systems), AI can’t help you. Second, you need real-time data flow, not nightly batch processes. AI making decisions based on yesterday’s data is useless in freight operations. Third, you need the computational infrastructure to run machine learning models continuously, not just when someone clicks a button.

EKA’s AI agents operate across the entire platform: document parsing automatically extracts data from rate confirmations, bills of lading, and invoices with 95%+ accuracy; intelligent load-to-carrier matching learns from your dispatchers’ patterns to suggest optimal assignments; natural language search lets you ask “show me late loads in Texas” instead of building complex filter queries; predictive ETA calculations factor in traffic, weather, and historical patterns to beat carrier estimates by 15-20%.

The difference between EKA’s approach and AI overlay solutions that vendors are selling is comparable to the difference between a Tesla (designed as an electric vehicle from the ground up) and a conversion kit that electrifies a gas car. Both might claim to be electric, but only one delivers the full benefits.

Read about AI in transportation management outcomes
Learn how AI workflows reduce trucking costs

Question 4

How do I know if my company is ready for a new TMS?

Accepted Answer

The clearest signal isn’t what your current TMS can’t do—it’s what your team is doing around it. When dispatchers maintain shadow spreadsheets because the system doesn’t show what they need, when accounting reconciles invoices manually because automated matching doesn’t work, when customer service can’t give accurate delivery ETAs without calling drivers, when you’re turning down profitable business because your systems can’t handle the complexity—these are symptoms of a system that’s become an operational anchor rather than an enabler.

The market is accelerating these pressures. 2026 belongs to businesses running the leanest operations, not those with the most trucks or the biggest customer lists. Regulatory changes like the non-domiciled CDL crackdown and new trucking regulations are tightening capacity just as freight demand remains soft. Companies that can’t measure performance in real-time, can’t adapt workflows quickly, or can’t scale operations without proportional headcount growth will struggle.

The mathematical trigger point typically hits when carriers manage 30+ trucks, or brokers handle 1,000+ loads monthly. Below these thresholds, spreadsheets and basic tools can work. Above them, the complexity overwhelms manual systems. But the real question isn’t size—it’s trajectory. If you’re growing, systems that barely work today will actively harm you tomorrow. Supply chain resilience requires adaptable technology, not just more headcount.

See how EKA customers scaled operations

Question 5

What size company is EKA built for?

Accepted Answer

EKA serves the mid-market to enterprise segment of logistics operations—companies that have outgrown starter tools but don’t need the complexity (or price tag) of systems built for Fortune 100 companies. Our sweet spot includes carrier fleets running 30-500 trucks, brokers managing 1,000-50,000 loads monthly, and shippers coordinating complex multi-carrier networks with annual freight spends from $10M to $500M+.

The beauty of modular architecture is that you’re not locked into a one-size-fits-all approach. Small to medium carriers might activate dispatch, driver settlement, and basic accounting modules initially, then add customer portals and advanced analytics as they scale. Enterprise carriers need everything from day one, plus multi-terminal coordination, complex asset management, and sophisticated business intelligence.

Our load-based pricing model means you pay for transaction volume, not arbitrary user counts. A 50-truck carrier moving 2,000 loads monthly pays roughly the same as a broker moving 2,000 loads monthly, even though the broker might have 20 dispatchers while the carrier has 5. This aligns technology costs with business outcomes rather than penalizing operational efficiency.

Explore solutions for brokers and 3PLs
See distribution and manufacturing shipper solutions

Question 6

Can EKA handle both carrier and broker operations simultaneously?

Accepted Answer

Yes, and this is one of EKA’s most powerful differentiators in a market where most TMS platforms force you into binary carrier-or-broker mode. The freight industry increasingly operates in hybrid models—carriers who broker overflow freight when their trucks are full, brokers who invest in dedicated power-only capacity for key lanes, and shippers who manage both private fleets and contracted carriers. Traditional systems make you pick one mode and then jump through workarounds to support the other.

EKA’s unified architecture treats freight as freight regardless of whether it moves on your trucks or a third-party carrier’s equipment. You see consolidated P&L across asset and non-asset operations. Your accounting system doesn’t care if a load generated revenue through your truck or through carrier procurement—it flows through the same automated invoicing and settlement workflows. InCompass Logistics uses this capability to manage a $100M+ freight book that seamlessly combines private fleet operations with 3PL brokerage services.

The operational flexibility this creates is substantial. During periods when volatile market conditions and tariff uncertainty make capacity unpredictable, hybrid operators can shift between asset-based and brokered freight based on real-time profitability calculations. When driver shortages tighten or when cross-border regulations change, you adapt workflows instantly rather than ripping out systems and starting over.

Learn about supply chain resilience through hybrid models

Question 7

How does EKA's modular architecture actually work?

Accepted Answer

Think of traditional TMS platforms as a house where the plumbing, electrical, and HVAC systems are all welded together. If you want to upgrade the heating system, you risk breaking the plumbing. If you need to add an electrical outlet, you might need to tear down walls. Everything is interconnected in ways that make changes expensive, risky, and slow.

EKA’s modular, headless approach is more like a modern smart home. Each system—dispatch, accounting, visibility, compliance, analytics, is an independent module with clean interfaces (APIs) that connect to other modules and external tools. You can upgrade the dispatch module without touching accounting. You can add a new integration with a load board without risking your driver settlement logic.

Here’s what this means practically: A carrier might activate the fleet dispatch module, driver pay module, and basic accounting integration initially. As they grow, they add the customer portal module so shippers can track loads. When they start brokering overflow freight, they activate the carrier procurement module. When they need deeper insights, they turn on advanced analytics. Each module activates in hours or days, not months.

The API-first foundation means every module exposes its functionality to other systems through modern, documented interfaces. Your partner ecosystem tools, Samsara for ELD, Denim for payments, RMIS for insurance certificates, connect through the same standardized interfaces. When Samsara updates a driver’s hours of service status, EKA’s dispatch module sees it instantly. When accounting posts an invoice, your business intelligence dashboard updates in real-time.

Explore our integration ecosystem
See how continuous improvement works

Question 8

What does API-first really mean for my operations?

Accepted Answer

“API-first” is technical jargon that translates to something simple: every piece of information in the system is available to other systems in real-time, and every action you can take in the user interface can also be triggered programmatically by another system. This eliminates the manual data bridges that consume hours of admin time and create opportunities for errors.

Consider a typical load lifecycle in a legacy system versus EKA. Legacy: dispatcher creates load in TMS, manually copies information into Excel, uploads to load board, downloads carrier information from load board, copies back into TMS, exports invoice data to CSV, imports into QuickBooks, and manually reconciles when payment arrives. Each manual step takes time and introduces error risk.

EKA’s API-first approach: dispatcher creates load, system automatically posts to integrated load boards based on configured rules, carrier accepts through load board API, and information flows back automatically, delivery confirmation from ELD triggers invoice generation in accounting system, payment through Denim updates both accounting and carrier scorecards simultaneously. Zero manual intervention required.

The effortless integration capability extends to custom integrations, too. Need to sync with your proprietary warehouse management system? Feed load data to a custom analytics platform? Automatically create service tickets in your CRM when exceptions occur? Standard REST APIs make these integrations achievable in days rather than months.

See our partner ecosystem
Learn about end-to-end visibility

Question 9

How long does a typical EKA evaluation and selection process take?

Accepted Answer

Most companies complete the evaluation in 2-4 weeks when they approach it systematically. Week one focuses on requirements validation and demo customization; we configure the demonstration environment to mirror your actual operations rather than showing generic scenarios. This means seeing your load types, your workflow patterns, and your integration requirements reflected in the system you’re evaluating.

Week two typically involves technical validation: your IT team (if you have one) reviews API documentation, security certifications, and integration capabilities; your operations team tests actual workflows with sample data; your accounting team validates how settlement, invoicing, and financial reporting would work. For companies without dedicated IT resources, we provide guided technical reviews that demystify the architecture without requiring deep technical expertise.

Week three addresses commercial terms, implementation planning, and change management preparation. Successful TMS implementations require people and process alignment, not just good technology. We help you build internal consensus, identify super-users who will champion the system, and plan the training approach that fits your team’s learning style.

Week four finalizes contracts, schedules implementation kickoff, and begins data migration planning. If you’re starting from scratch with no clear TMS criteria, add 1-2 weeks for internal requirements gathering. We provide evaluation frameworks that help structure decision-making, but the most important factor is clarity about what problems you’re solving.

Contact us to start your evaluation

Question 10

Should I choose a TMS that specializes in my freight type or a general platform?

Accepted Answer

Choose based on workflow complexity and integration needs, not freight type. The “specialized TMS” pitch usually means the vendor has hard-coded assumptions about how your freight type should work into their system. This works great until your business model evolves—then you’re stuck with someone else’s vision of how refrigerated freight or flatbed operations or port drayage “should” work.

EKA’s configurable workflows adapt to any freight type because we separate the data model (what information the system tracks) from the business logic (how that information is processed) and from the user interface (how people interact with it). Holt Logistics runs thousands of port-centric loads weekly with custom clearance workflows, container tracking, and international compliance requirements. Other customers handle standard dry van truckload. The platform molds to business logic through visual configuration rather than forcing you into predefined templates.

The real differentiation comes from integration capabilities, not freight-type specialization. A refrigerated carrier needs TMS integration with temperature monitoring devices, cold storage warehouses, and food safety compliance systems. A flatbed operation needs integration with securement documentation, specialized load boards, and permit management. An intermodal operation needs container tracking, chassis pool management, and rail yard integrations. EKA’s API-first architecture supports these specialized integrations without locking you into rigid freight-type assumptions.

Explore workflow customization capabilities

EKA | Frequently Asked Questions

TMS Selection and Evaluation

Implementation and Migration

Technical and Architecture