ConvoyLedger

What is ConvoyLedger and who is it for?

ConvoyLedger is an ETS2 VTC management software concept built for owners and staff of Euro Truck Simulator 2 virtual trucking companies. It provides one operational command center for assigning jobs, tracking deliveries, calculating driver payroll, and recognizing reliable drivers.

Most VTCs begin with a Discord server, a spreadsheet, and a shared understanding of the rules. That setup is often enough for five friends running occasional convoys. It becomes fragile when the VTC grows, adds divisions, runs recurring contracts, recruits international drivers, or tries to reward consistency fairly.

The core value proposition is straightforward: ConvoyLedger turns the administrative work of running an ETS2 VTC into a structured, transparent workflow without removing the community-first character that makes virtual trucking companies enjoyable.

Instead of asking staff to reconcile screenshots, chat messages, spreadsheets, and third-party tracker data at the end of every week, the platform creates a clear operational record:

• Which jobs were assigned
• Which drivers accepted and completed them
• Whether deliveries met time, cargo, route, and event requirements
• What each completed job is worth
• Which drivers are consistently dependable
• Which dispatchers or managers need to follow up on exceptions

This positions ConvoyLedger as more than an ETS2 job tracker. It is a virtual trucking company operations platform for leaders who want to run a more organized, scalable, and rewarding community.

The ETS2 VTC management software problem

The ETS2 multiplayer and virtual trucking community is built around coordination. VTC owners plan events, recruit drivers, publish route requirements, review applications, manage internal ranks, and create reasons for members to keep returning. Yet the administrative layer is frequently fragmented.

A typical established VTC may use:

• Discord for announcements, job claims, support, and informal updates
• Google Sheets or Excel for payroll and delivery records
• Forms for recruitment or trip submissions
• Third-party telemetry and logging tools for driving evidence
• Manual screenshots for proof of cargo, distance, and destination
• Discord roles for ranks and participation recognition

Each individual tool can work. The issue is the handoff between them. A dispatcher posts a job in Discord. Drivers react with an emoji to claim it. A delivery is submitted through a form. Someone copies the details into a spreadsheet. A manager reviews the entry later. Payroll is calculated in another tab. The driver then waits for a role update or reward.

That process creates several recurring operational problems.

Manual administration does not scale with driver activity

The real challenge is not simply having more drivers. It is having more exceptions. As job volume rises, managers need to handle incomplete submissions, duplicate records, late deliveries, changed routes, cargo substitutions, event-only rules, and questions about payment calculations.

Manual systems force staff to spend their time doing clerical reconciliation instead of welcoming new members, hosting events, or supporting drivers.

Drivers cannot always see how performance is measured

A VTC can unintentionally create frustration when driver rewards feel opaque. If a member does not know whether their delivery was accepted, why it was rejected, how their pay was calculated, or what they need to do to rank up, motivation drops.

A reliable ETS2 VTC payroll system should make the reward logic visible. The goal is not to make every community overly competitive. It is to make expectations fair and understandable.

Discord is excellent for community, not operational accounting

Discord should remain central to a VTC community. It is where members socialize, coordinate convoys, and build identity. However, it is not designed to be a dependable job ledger, payroll engine, or delivery audit database.

ConvoyLedger should complement Discord rather than attempting to replace it. The product wins when it lets Discord handle conversation while the application handles structured operations.

Existing tools can leave operational gaps

VTC owners often adopt specialized tools for tracking, websites, recruitment, or event planning. Many still need to connect those activities to internal job assignment, rewards, payroll rules, and driver reliability.

The market gap is an operational layer that answers practical questions such as:

• Which dispatch jobs are currently open?
• Who is responsible for each route?
• Which delivery submissions need approval?
• How much virtual payroll is owed this week?
• Which drivers have completed the most verified work?
• Which members are inactive, improving, or especially reliable?
• How can staff reward dependable driving without manually calculating everything?

Target audience for ConvoyLedger

A successful go-to-market strategy should avoid treating every ETS2 player as a buyer. The primary customer is the person who feels the pain of operational overhead and has enough authority to introduce a shared tool.

Primary audience: established VTC owners

The ideal early ConvoyLedger customer is a VTC owner or co-owner with an active driver base and a recurring administrative burden. They may already have a website and Discord setup, but their operating processes are improvised.

Their needs typically include:

• Reducing the time spent checking delivery evidence
• Giving dispatchers a standardized way to assign work
• Maintaining a credible internal economy or payroll model
• Recognizing high-quality, consistent drivers
• Making onboarding easier for new staff
• Providing a professional experience that differentiates the VTC from competing communities

This customer is likely to pay for saved staff time, improved retention, and a more polished member experience.

Secondary audience: dispatchers, HR staff, and event coordinators

These users may not control the budget, but they determine whether the tool becomes part of the VTC’s routine. Their experience must be fast and practical.

For a dispatcher, the ideal workflow is not a complex enterprise system. It is the ability to create a job, set eligibility and completion rules, assign or open it to drivers, and resolve exceptions quickly.

For an HR or management team member, the platform should make driver participation visible without requiring them to search hundreds of chat messages.

Tertiary audience: serious independent drivers

Drivers are product users even when VTC owners are the paying customers. A driver should receive direct value from ConvoyLedger through a clear personal dashboard.

That dashboard can show:

• Assigned and available jobs
• Delivery requirements and route guidance
• Submission status
• Earnings history
• Reliability score or streaks
• Rank progress
• Recognition badges
• Upcoming VTC events

The driver experience is essential because adoption fails if members view the system as extra paperwork. The product should make participation easier, not more bureaucratic.

Market opportunity and the operational gap

The opportunity for ConvoyLedger sits at the intersection of gaming communities, lightweight workforce management, and creator-style community monetization.

VTCs behave like small organizations even though they are voluntary gaming communities. They have leadership structures, onboarding processes, rules, recurring work, performance signals, events, and member retention goals. Yet they usually do not want traditional enterprise operations software. Products designed for real-world logistics companies are too expensive, too complex, and fundamentally mismatched to a simulated trucking environment.

At the other end of the market, spreadsheets are flexible but difficult to govern. They rely on one or two knowledgeable people, lack proper permissions and audit trails, and become error-prone as participation increases.

ConvoyLedger occupies the middle ground:

• More structured than a spreadsheet
• More operational than a basic VTC website
• More community-aware than conventional fleet management software
• More flexible than a rigid leaderboard or one-purpose delivery logger

Why the timing is favorable

Community management expectations have changed. Members increasingly expect self-service profiles, immediate status updates, transparent rules, and modern dashboards. VTC leadership teams also increasingly distribute responsibility among dispatchers, recruiters, event staff, and moderators.

At the same time, SaaS architecture has made multi-tenant products much easier to launch and operate. Managed databases, real-time interfaces, identity platforms, observability tooling, and reliable billing services allow a focused team to build a credible VTC command center without recreating infrastructure from scratch.

When validating market demand, use direct evidence from the community rather than relying on broad gaming-market statistics. Interview VTC owners and ask for artifacts such as:

• Their current payroll spreadsheet
• The exact messages used to assign jobs
• A recent example of a disputed delivery
• The weekly time spent by staff on administrative work
• The point at which their existing system started to break down

These conversations reveal the real willingness to pay. A VTC owner who says, “Our operations manager spends four hours every Sunday reconciling jobs,” has a much stronger pain signal than someone who simply says the concept sounds useful.

A focused beachhead market

The best beachhead is not every VTC. Start with English-speaking or multilingual VTCs that meet most of these criteria:

1. They have at least 20 active drivers.
2. They run internal jobs, contract systems, or activity requirements.
3. They already use Discord heavily.
4. They have at least two staff members involved in operations.
5. They reward activity through roles, virtual currency, promotions, or recognition.
6. They are frustrated by manual tracking.

This segment has an urgent problem, enough repeat activity to see value quickly, and a clear champion who can coordinate rollout.

ConvoyLedger’s unique selling proposition

The strongest ConvoyLedger USP is not merely “manage your VTC.” That phrase is too broad and easy for competitors to imitate.

A more defensible position is:

ConvoyLedger is the operational ledger for ETS2 VTCs that need fair job dispatch, verifiable delivery records, transparent virtual payroll, and meaningful reliability rewards.

The word “ledger” matters. It signals a trusted, historical record instead of a temporary task board. Every operational decision should be traceable: who created a job, who accepted it, what was submitted, who approved it, and how the reward was calculated.

This creates differentiation in four areas.

Operational trust as a moat

The deeper competitive advantage is trust. Once a VTC has a reliable history of jobs, payroll, driver recognition, and internal policies inside ConvoyLedger, replacing it becomes inconvenient. This is not lock-in through obscurity. It is retention through accumulated operational value.

The platform should make data export easy and transparent. Trust grows when customers know they can access their records. The better the product serves them, the less reason they will have to leave.

Community-aware workflows as a moat

Generic project management tools can assign tasks. They do not understand VTC concepts such as cargo requirements, kilometers driven, delivery proof, convoy attendance, driver rank thresholds, or virtual economy rules.

The product should use the language of the community. This makes onboarding faster and gives the platform a clear category identity as virtual trucking company management software.

Core ConvoyLedger features and solution design

The MVP should solve a complete operational loop. Avoid launching with a broad collection of disconnected features. A VTC should be able to create work, have drivers complete it, approve results, calculate rewards, and use that history for recognition.

VTC workspace and role-based access

Each VTC needs an isolated workspace with its own brand, rules, divisions, and permissions. The workspace setup should include:

• VTC name, logo, timezone, and default currency display
• Optional divisions such as long-haul, heavy cargo, event team, or recruitment
• Driver ranks and eligibility policies
• Payroll settings
• Job templates
• Custom delivery review fields
• Staff roles and permissions

Role-based access control is non-negotiable. A driver should not be able to alter payroll rules. A dispatcher should be able to assign jobs without necessarily accessing billing or owner settings. An auditor or HR manager may need read-only access to driver history.

Recommended default roles include owner, administrator, dispatcher, reviewer, HR manager, and driver.

Job board and dispatch workflow

The job board is the product’s daily heartbeat. Dispatchers should be able to create jobs from scratch or use templates for recurring routes.

A job record may contain:

• Origin and destination
• Cargo type
• Required or recommended distance
• DLC and map requirements
• Allowed completion window
• Maximum number of drivers
• Assigned driver or open-claim status
• Expected virtual reward
• Priority level
• Instructions and supporting links
• Evidence requirements
• Tags such as event, hazardous cargo, beginner-friendly, or team route

The workflow should support both direct assignment and open dispatch. Direct assignment works for planned events or role-based work. Open dispatch lets qualified drivers claim available jobs.

To prevent confusion, every job needs a visible lifecycle. Suggested statuses are draft, open, assigned, in progress, submitted, needs revision, approved, rejected, expired, and cancelled.

Delivery tracking and evidence review

Delivery tracking is where product design must balance integrity with convenience. A system that requires too much manual proof will reduce adoption. A system that accepts everything automatically may undermine trust.

Start with flexible proof submission:

• Screenshot uploads
• Delivery completion notes
• Relevant trip identifiers where supported
• Optional kilometers and duration fields
• Reviewer comments
• Timestamped submission history

Over time, ConvoyLedger can add integrations with compatible public tracking ecosystems where their APIs and terms allow it. The product should not make unverified claims about automatic tracking until integrations are technically and contractually validated.

A review queue helps staff focus on exceptions. Reviewers should see the job requirements next to the submitted proof, then approve, reject, or request clarification with a standardized reason.

Configurable VTC payroll management

A virtual payroll feature should never assume every VTC rewards drivers the same way. Some use a fictional currency, some use leaderboard points, and some use payroll purely as a roleplay mechanic. ConvoyLedger should support configurable formulas rather than prescribing one economy.

Possible payroll inputs include:

• Base amount per completed job
• Distance-based rate
• Cargo category multiplier
• Difficulty or priority multiplier
• On-time completion bonus
• Event participation bonus
• Consecutive completion streak bonus
• Penalties for approved policy violations
• Manual adjustments with required notes

Every calculation should be explainable on the driver’s payout record. For example, a driver should see that a job paid a base reward plus a heavy cargo bonus, rather than receiving an unexplained total.

This feature is particularly valuable because it converts spreadsheet formulas into durable product logic with approvals and audit history.

Driver reliability and reward system

Reliability must be designed carefully. It should motivate positive participation, not shame people who take breaks or cannot attend every event.

A practical reliability model can include:

• Completed jobs divided by accepted jobs
• On-time delivery rate
• Verified delivery rate
• Attendance at optional registered events
• Streaks for consistent participation
• Low cancellation rate
• Positive staff recognition

The score should be transparent and contextual. Drivers need to understand the time period, inputs, and how they can improve. Avoid presenting a single score as an absolute judgment of a player’s character.

Better reward options include badges, rank eligibility, priority job access, cosmetic profile recognition, milestone certificates, and Discord role automation. The platform should also allow VTC owners to disable scoring entirely if it does not fit their culture.

Reporting and operational insights

Owners need actionable insight, not dashboards full of vanity metrics. The first reports should answer decisions a VTC leader already needs to make.

Useful dashboard metrics include:

• Open, assigned, and overdue jobs
• Delivery approval turnaround time
• Total approved distance during a selected period
• Payroll owed or awarded
• Active drivers versus inactive drivers
• Completion rate by division
• Job demand by route or cargo category
• New-driver activation rate
• Top reliability trends

Export to CSV is essential from the first version. It allows owners to keep control of their data, prepare community reports, and transition gradually from existing systems.

Recommended technology stack for an ETS2 VTC platform

ConvoyLedger needs a stack that supports multi-tenancy, role-based access, responsive dashboards, file uploads, audit logs, and future integrations. Early technical choices should optimize for product iteration and operational reliability rather than theoretical maximum scale.

Frontend and application framework

A strong choice is Next.js with React and TypeScript. This combination supports server-rendered marketing pages, authenticated dashboards, API routes or server actions, and type-safe interfaces in one ecosystem.

For the UI layer, Tailwind CSS offers fast iteration and makes it easier to create a consistent design system for tables, status states, mobile layouts, and data-rich dashboards.

The main trade-off is that a full-stack Next.js application requires thoughtful separation between browser code, server-only code, and authorization checks. For an early SaaS product, that discipline is worth the benefit of a unified codebase.

Database and data access layer

PostgreSQL is a natural fit because the core domain is relational. A job belongs to a VTC, may be assigned to a driver, can produce a delivery submission, can generate one or more payroll ledger entries, and may be reviewed by staff.

A managed PostgreSQL provider paired with Prisma can accelerate development through migrations, typed database access, and readable schema definitions.

The most important data-design decision is multi-tenancy. Every business record should be scoped to a vtc_id, and every server-side query must enforce that scope. Do not rely only on hiding records in the user interface.

Authentication and Discord identity

Discord is the logical identity provider because it reduces onboarding friction for VTC members. Discord OAuth2 documentation should guide the authentication implementation.

Discord login should be paired with an internal user identity model. Do not make Discord profile data the only source of truth. Store the minimum required identifiers, allow account linking, and build a clear process for handling users who change Discord names or leave a server.

For authentication infrastructure, Auth.js is a reasonable option for teams that want an open ecosystem and direct framework integration. A managed auth provider can reduce setup work, but may create pricing and portability trade-offs as usage grows.

Background jobs, uploads, and observability

Recurring payroll periods, reminder notifications, report generation, and integration syncs should run in background jobs. Use a durable queue or managed workflow platform rather than attempting to run long tasks inside a browser request.

Delivery screenshots and evidence files should be stored in object storage with strict access controls, signed URLs, file-size limits, and malware scanning where appropriate. Evidence is sensitive to VTC operations even if it is not high-risk personal data.

For error monitoring and performance visibility, Sentry is a widely used option. Instrument the most important workflows first: sign-in, job claim, delivery submission, approval, payroll calculation, and Discord notifications.

Suggested data model

The schema should preserve an audit-friendly history instead of overwriting key business events.

type JobStatus =
  | "DRAFT"
  | "OPEN"
  | "ASSIGNED"
  | "IN_PROGRESS"
  | "SUBMITTED"
  | "APPROVED"
  | "REJECTED"
  | "EXPIRED"
  | "CANCELLED";

type PayrollEntry = {
  id: string;
  vtcId: string;
  driverId: string;
  jobId?: string;
  amount: number;
  currencyLabel: string;
  calculationSnapshot: Record<string, unknown>;
  createdAt: Date;
};

type AuditEvent = {
  id: string;
  vtcId: string;
  actorId: string;
  entityType: "JOB" | "DELIVERY" | "PAYROLL" | "DRIVER";
  entityId: string;
  action: string;
  metadata: Record<string, unknown>;
  createdAt: Date;
};

The calculationSnapshot field is important. If a VTC later changes its distance rate or cargo multiplier, historical payroll entries should still explain the rule used when they were generated.

Monetization strategy for ConvoyLedger

ConvoyLedger should use B2B-style SaaS pricing even though its users are gaming communities. The VTC, not the individual driver, is the customer. Pricing needs to feel accessible for volunteer-run groups while clearly connecting to operational value.

Tiered subscriptions based on active drivers

A tiered model is intuitive and aligns revenue with customer value.

• "Free trial": limited time access to the full workflow, ideally with guided setup and sample data
• "Starter": for small VTCs with a modest active-driver cap and core job tracking
• "Growth": for established VTCs needing payroll automation, custom roles, reporting, and Discord automation
• "Pro": for larger organizations needing multi-division support, advanced analytics, priority support, and higher storage limits

Use active drivers rather than registered accounts for limits. VTCs often have many former members or inactive accounts, and charging for every historical profile will feel punitive.

Paid operational add-ons

Add-ons can increase average revenue without complicating the core subscription:

• Additional evidence storage
• White-label or custom domain experience
• Advanced reporting exports
• Multiple VTC divisions or regional branches
• Branded driver certificates
• Advanced Discord automation
• Extended audit-log retention

Keep the core job-to-payroll workflow available in the primary plan. Do not gate the product’s main outcome behind too many add-ons.

Avoid advertising as the primary model

Ads are likely to reduce trust and make an operations platform feel less professional. They also introduce a misalignment: the product would benefit from attention rather than from helping VTCs run better.

Subscription revenue is more predictable, supports better support standards, and reinforces ConvoyLedger’s position as serious VTC infrastructure.

Key risks and practical mitigation

A strong SaaS strategy acknowledges risks early. ConvoyLedger’s risks are manageable, but ignoring them can produce expensive rework or weak adoption.

Risk: integrations depend on external platforms

Discord APIs, game-adjacent tracking tools, and community services can change their policies, permissions, or availability.

Mitigation should include:

• Designing a useful manual workflow before building integrations
• Treating integrations as optional accelerators, not the only product path
• Versioning connector logic separately from core business rules
• Maintaining clear user messaging when a sync is delayed or unavailable
• Avoiding unsupported scraping or any workflow that violates third-party terms

Risk: VTCs have highly different rules

One VTC may prioritize realism and formal dispatch. Another may run casual weekend convoys. A rigid product will fit neither group well.

Mitigation comes from configurable templates, optional modules, and sensible defaults. Let VTCs rename ranks, define payroll formulas, control evidence requirements, and choose which metrics appear publicly. Avoid building custom one-off features for every early customer unless the need reveals a reusable product pattern.

Risk: drivers perceive it as surveillance or busywork

The platform can fail if drivers feel that every trip needs administrative proof.

Mitigation should focus on low-friction workflows. Let VTCs decide which jobs require proof. Make submission mobile-friendly. Use clear progress states. Celebrate approved work and milestones instead of displaying only compliance warnings.

Risk: payroll disputes reduce trust

Disputes are inevitable when rewards are calculated from configurable rules.

The answer is explainability. Preserve formula snapshots, policy versions, reviewer comments, adjustment reasons, and audit events. A manager should be able to answer a dispute with evidence in minutes.

Risk: small communities have limited budgets

Many VTCs are volunteer organizations with constrained spending.

Counter this by making the ROI concrete. If ConvoyLedger saves several staff hours each month, improves new-driver activation, and reduces member churn caused by confusing processes, a modest monthly subscription is easier to justify. A free trial and an entry tier reduce adoption risk.

Competitive advantage and defensibility

ConvoyLedger can build a meaningful advantage by becoming the source of truth for VTC operations. The key is to create value that compounds with use.

The more jobs a VTC manages, the more useful its historical delivery records become. The more payroll cycles it runs, the more important its trusted ledger becomes. The more reliable drivers it recognizes, the more valuable its progression system becomes to the community.

This produces several defensibility layers:

• "Workflow depth" comes from solving connected operational tasks, not offering a single job board.
• "Historical data value" comes from delivery, payroll, and recognition records that inform future decisions.
• "Community fit" comes from terminology, UX patterns, and policies designed specifically for ETS2 VTCs.
• "Integration value" comes from connecting operational records with Discord communication and future approved tracking sources.
• "Switching value" comes from dashboards, templates, processes, and team training built around the platform.

The product should still remain interoperable. CSV export, documented data policies, and transparent account ownership improve credibility. In community SaaS, trust is often a stronger retention engine than artificial friction.

An actionable implementation roadmap

The best implementation plan is a staged release that proves demand before adding technically expensive integrations.

Define MVP success metrics before launch

ConvoyLedger should not measure success only by registered users. The product is successful when VTCs move real operational work into it.

Track metrics such as:

• Percentage of invited drivers who complete onboarding
• Percentage of created jobs that receive a claim or assignment
• Time from delivery submission to final review
• Percentage of approved jobs with automatically generated payroll entries
• Weekly active staff members per VTC
• Number of VTCs still using the platform after 30, 60, and 90 days
• Qualitative reports of spreadsheet or Discord admin work eliminated

A particularly useful activation event is when a VTC completes its first full job cycle with no off-platform payroll reconciliation.

Build the first version with speed and maintainability

A production-ready SaaS starter can reduce time spent rebuilding authentication, billing, team management, dashboard foundations, and application infrastructure. For teams that want to concentrate on ConvoyLedger’s ETS2-specific workflows instead of commodity SaaS setup, TurboStarter can provide a practical starting point.

Final recommendation

ConvoyLedger has a clear opportunity because it addresses a persistent and specific pain point: VTC leaders need a better way to coordinate work and reward participation than scattered Discord messages and fragile spreadsheets can provide.

The winning product should not try to become a full real-world logistics simulator. It should become the trusted operational system for virtual trucking companies. That means focusing first on job dispatch, delivery verification, configurable virtual payroll, driver reliability, and transparent rewards.

The strongest early promise is simple: give VTC staff less administration, give drivers more clarity, and give the entire community a fairer way to recognize reliable participation.

Start with a narrow MVP, validate with active VTCs, keep the workflow flexible, and make every important decision visible in an audit-friendly ledger. If ConvoyLedger earns trust in the weekly rhythm of VTC operations, it can become difficult to replace and genuinely valuable to the communities it serves.