Skip to content

Request intake and assignment

Every request reaches the right person

We organise request intake, checks and assignment with a clear owner, deadline and next action, including a path for incomplete or uncertain requests.

Explore the solution

01 / Who it is for

Who owns the request that just arrived?

A customer fills out a form, then follows up through another channel. One colleague starts replying while another forwards the same request, and nobody knows who owns it. For a small team, we propose a shared queue and straightforward assignment rules. Across several branches, routing can consider location, service, working hours and available teams. The coordinator can see unassigned requests, overdue actions and cases needing a decision without reconstructing every conversation. Colleagues can hand work over with a clear record of the next action and responsibility.

02 / What the project can include

From an incoming message to a tracked task

01

Intake and checks

We agree which channels to include and what information makes a request actionable. Missing details go into a clarification queue, while possible duplicates are flagged before another task is created, keeping the original source visible.

02

Assignment by clear rules

We define who receives each request based on service, location or declared availability. Where rules conflict or no eligible owner is available, the request enters an exception queue with a named coordinator responsible for resolving it.

03

Deadlines and follow-up

Each request gets an owner, a next action and a deadline appropriate to its type. Internal notifications and escalation can make delays and handovers visible, helping coordinators follow up when a task has not been accepted.

03 / Illustrative example

Illustrative example: a repair enquiry

Imagine a workshop receiving a repair enquiry through its form. Contact details are checked and, where there is a reliable match, the request is linked to the existing customer in the CRM. Location and equipment type identify the right team; an available manager receives the task of confirming the details. A missing address sends the request for clarification. A repeat enquiry is flagged as a possible duplicate. The coordinator follows the request through to acceptance, including when its original owner does not pick it up on time.

04 / How we work

How we define the request journey

  1. 01

    Review incoming requests

    We review anonymised enquiries, the channels used and how your team currently chooses who replies. We identify missing information and places where ownership becomes unclear.

  2. 02

    Agree routing rules

    We agree assignment criteria, their priority, deadlines and the person responsible for exceptions. We cover absences, possible duplicates and requests arriving outside working hours.

  3. 03

    Configure and verify

    We configure the agreed process and review representative cases together: a complete request, missing details, a possible duplicate and no eligible owner available at the time.

  4. 04

    Review actual handovers

    We introduce the process to the team and check that tasks reach their intended owners. We refine rules using unaccepted requests and exceptions observed during use.

05 / What you receive

What your team receives

  • A documented request journey with routing rules and exception handling.
  • A configured process for the channels and systems included in the project.
  • A view of unaccepted requests and guidance for coordinators and task owners.

What the project can include

What we agree before implementation

  • Connecting a channel depends on access and the capabilities of the service; we explicitly agree which channels are included.
  • Customer records and relationship history belong in the CRM. AI interpretation of free-text messages is assessed separately.
  • Uncertain matches do not automatically merge customers; we name an owner for duplicate checks and unassigned requests.

Where we start

Discuss your project

Show us three anonymised requests from different channels and explain who should handle each one. Include a request that went unanswered so we can understand where the actual handover failed.

Organise request intake