Aras Kargo and Tolk.

Illustrative scenario — not a customer case study. This article explores a proposed Aras Kargo operating model. It does not describe a confirmed Tolk deployment, partnership, endorsement, or measured customer results. The workflow and evaluation plan are proposals for a bounded pilot.

One parcel can generate several conversations: a tracking question, a delivery-time change, a missed visit, and a request to collect from a pickup point. For the customer, these are parts of one journey. For a support team, they can become separate records spread across channels, branches, and delivery operations.

This scenario explores how Tolk could bring those conversations and their shipment context together, helping teams respond with clearer ownership while keeping sensitive decisions under human control.

The company

Aras Kargo is a parcel-delivery and logistics company with a nationwide network across Türkiye. Its published support resources describe live support, call-center assistance, enquiries, feedback, and claims.

At that scale, customer service is closely connected to delivery operations. A useful response depends on understanding the shipment, what has already happened, and which team can take the next step. The opportunity explored here is to connect that context to the conversation without replacing the systems that run the logistics network.

The challenge

Customers may use live support, a call center, social channels, or a branch to ask about the same parcel. A request can move from general support to a delivery team or claims specialist, requiring each employee to reconstruct the situation before responding.

An agent may need the shipment reference, current delivery stage, previous attempts, earlier conversations, and any address or delivery-time request. Repeating that work increases waiting time and can lead to unnecessary handoffs.

Not every enquiry needs the same response. A routine tracking question is different from a parcel marked delivered but not received, or a damage claim. The proposed workflow therefore focuses on three priorities:

• Keep the context together: connect customer history and approved shipment information to one conversation.
• Recognize the request early: distinguish routine questions from urgent, disputed, or sensitive cases.
• Make ownership clear: route each case to the support, branch, delivery, or claims team able to resolve it.

The proposed solution

Tolk would serve as a customer-conversation layer in front of Aras Kargo's existing logistics, tracking, CRM, and delivery infrastructure. Those systems would remain responsible for shipment information and operational decisions.

One conversation, with its history intact

Supported channels could feed a shared workspace containing the customer identity, shipment reference, contact history, current owner, priority, labels, and internal notes. When a case moves between teams, that context would travel with it.

The objective is continuity: the next employee should understand the case and the action already taken, rather than asking the customer to repeat the story.

AI assistance with human control

Kai could help classify the request, identify urgency, summarize the conversation, and prepare a response using approved knowledge. Routine tracking guidance, pickup-point information, return procedures, and delivery options would be suitable starting points for an assisted workflow.

For example, a Turkish message saying “Kargom teslim edildi görünüyor ama elime ulaşmadı” describes a parcel marked delivered but not received. In this scenario, it could be classified as a delivery dispute, marked high priority, and sent to a resolution team for human review.

A message saying “Kargom yarın gelecek ama evde olmayacağım” raises a different need: guidance on eligible delivery preferences. Assistance should follow the options confirmed by the logistics system, rather than promise an unsupported address or time change.

AI would prepare the work, not take ownership of every decision. Compensation, disputes, identity-sensitive changes, missing shipments, complaints, and unclear information would remain under human review.

Routing and handoffs that preserve context

Routing could distinguish tracking enquiries, eligible delivery changes, returns, missing shipments, damage claims, branch complaints, and corporate account requests. Each would enter its appropriate workflow, with an owner and a clear next step.

For a non-receipt dispute, an illustrative handoff could include the masked shipment reference, last tracking event, contact channel, previous enquiry, checks already completed, and the assigned investigation team. This would give the receiving employee a case summary instead of an unexplained transfer.

Connected systems, voice, and social support

Approved APIs and webhooks could make shipment status, the last scan, destination branch, delivery attempts, eligible options, and return status available beside the conversation. Access and permitted actions would need to be defined and validated during the pilot; Tolk would not become the source of truth for shipment state.

Eligible voice workflows could add a reviewable call summary covering the reason for contact, customer request, agent action, follow-up, and resolution status. This could reduce repeated documentation and help the next employee understand the previous call.

Social Engage could help teams identify public questions, complaints, urgent cases, and spam. Public replies should avoid personal shipment details and guide customers to a private support channel when identification is required.

The pilot: start with one workflow

A deployment at this scale should begin with a bounded pilot, not an immediate company-wide migration. The following sequence is a proposed pilot plan; it does not document a real implementation.

1. Phase 1 — establish the baseline: focus on tracking and delivery-change enquiries. Connect live chat, one support team, approved FAQ knowledge, a shipment-status API, and basic routing.
2. Phase 2 — validate assisted handoffs: add missing-delivery cases, return questions, escalation, AI summaries, team routing, and operational reporting.
3. Phase 3 — review expansion: consider selected call-center and social workflows, claims handoffs, additional teams, and SLA monitoring after reviewing the earlier phases.

The purpose of the pilot would be to test whether connected context and assisted triage improve the chosen workflow before expanding its scope.

Measure the service journey

A proposed nine-month review would compare time to a useful first response, manual triage effort, routing accuracy, repeated customer questions, after-call documentation, reopened cases, and satisfaction by issue type. Reviewers would use comparable case groups and a measured baseline.

AI assistance would be recorded separately from autonomous resolution. A prepared reply or transfer would not count as a solved delivery dispute. Changes in service quality, operating effort, and customer outcomes would determine whether the pilot should expand.

From support reporting to operational insight

Structured conversations could help managers see why customers contact support, which issues are growing, where queues approach SLA risk, and which workflows create repeated escalation or handoffs. Reporting could also track AI assistance, gaps in FAQs, and customer satisfaction by issue or channel.

A recurring delivery-preference question might reveal a need for clearer customer guidance. Repeated handoffs could point to unclear ownership, while unanswered FAQs could identify missing knowledge. The aim would be to understand what creates support demand, not simply count incoming conversations.

The proposed outcome

Aras Kargo's logistics network would remain the foundation of the delivery journey. Tolk's proposed role would be to connect customer communication to that operation: less repetition for customers, more context for agents, and clearer visibility for managers.

The model brings together a unified inbox, Kai assistance, knowledge-backed replies, routing, automation, voice, Social Engage, APIs, reporting, and human handoff. Its value would need to be demonstrated through a controlled pilot with clearly defined responsibilities and measured outcomes.

Company background: Aras Kargo's official company information. Public company information is provided for context and does not establish a Tolk customer relationship.