How to Acknowledge and Route Emailed Store Inquiries to the Right Team

Build a Spojit workflow that auto-acknowledges inbound store inquiry emails, classifies them into general, loyalty, returns, or supplier, files each one into the matching Front inbox, and replies to the sender confirming receipt.

What This Integration Does

A retail pharmacy counter gets a steady stream of email: loyalty card questions, return and exchange requests, supplier and rep enquiries, and a long tail of general "do you stock X" messages. Sorting them by hand is slow, and customers wait without knowing their email even arrived. This Spojit workflow gives every inbound message an instant acknowledgement, then quietly classifies it and files it into the right Front inbox so the correct counter or admin queue picks it up. It is a triage and notification workflow only: it organizes and acknowledges admin correspondence, and it never offers clinical advice, dispensing decisions, or anything beyond store operations.

The run model is push-based. You point a public-facing inquiry address (or a forwarding rule from your shop inbox) at a Spojit Mailhook address, and every email that lands there starts a run within seconds. A Connector node in Agent mode reads the message and returns a fixed JSON classification, a Condition node branches on that category, the front connector files the message into the matching inbox, and a Send Email node replies to the sender. The workflow is asynchronous: there is no live reply to the sender's mail server, so the acknowledgement always comes from the Send Email step. Each message is deduplicated, so a re-delivered email does not create a second acknowledgement.

Prerequisites

A workspace where you can create workflows in the Spojit Workflow Designer.
A front connection (API key) added under Connections, with access to the inboxes you want to route into.
The Front channel ID for each destination inbox (general, loyalty, returns, supplier). You can read these with the list-inboxes tool on the front connector once and note them down.
Your sender address allowlisted under Settings > General > Email recipients so the Send Email acknowledgement can reach external customers.
An inquiry email address or forwarding rule you control, so you can point it at the generated Mailhook address. The customer name and the question are all that is needed; do not collect clinical detail.

Step 1: Receive the email with a Mailhook trigger

Add a Trigger node and set Trigger Type to Mailhook. Optionally set an Address prefix (1-24 characters, default mh) such as store, then click Generate email address. Spojit creates a unique address like store-9f3a1c7b2e5d4a06@mailhook.spojit.com. Copy it and forward your shop inquiry email to it (or set a forwarding rule from your existing inbox). To cut noise, add an optional Subject regex or a From allowlist. Every message that arrives is available downstream as {{ input }} with fields including {{ input.subject }}, {{ input.text }}, {{ input.from }}, and {{ input.replyTo }}. There is no mailbox or OAuth to connect: the address itself is the trigger.

Step 2: Classify the inquiry with a Connector node in Agent mode

Add a Connector node and switch it to Agent mode. Agent mode lets the agent read the message and decide an outcome, while a Response Schema forces the result into a fixed JSON shape so the downstream Condition node can branch on it reliably. In the prompt, pass the subject and body and ask for a single category. Keep the workflow on the admin side of the line: instruct it that any message touching health, symptoms, medication advice, or clinical topics must be classified as general so a person handles it, never answered automatically.

Classify this store inquiry into exactly one category for routing.
Subject: {{ input.subject }}
Body: {{ input.text }}

Categories:
- loyalty   (loyalty card, points, rewards sign-up)
- returns   (returns, exchanges, refunds of retail goods)
- supplier  (suppliers, reps, wholesale, ordering)
- general   (everything else, AND anything about health,
            symptoms, medication, or clinical advice)

Return only the schema fields. Do not answer the customer's
question and do not give any health or clinical guidance.

Set the Response Schema so the node always returns a predictable object:

{
  "type": "object",
  "properties": {
    "category": {
      "type": "string",
      "enum": ["loyalty", "returns", "supplier", "general"]
    },
    "summary": { "type": "string" }
  },
  "required": ["category", "summary"]
}

Map the node output to a variable such as triage so later steps can read {{ triage.category }} and {{ triage.summary }}.

Step 3: Branch by category with a Condition node

Add a Condition node that checks {{ triage.category }}. Create branches for loyalty, returns, and supplier, and treat the default (general) branch as the admin queue. Because the classifier is forced to label any clinical-adjacent message as general, those messages flow to the human-staffed general inbox rather than being acted on automatically. Each branch leads to its own front filing step in the next step, but all branches reconverge on the same Send Email acknowledgement at the end.

Step 4: File the message into the matching Front inbox

On each Condition branch, add a Connector node on the front connector in Direct mode and select the send-message tool. Direct mode is right here because there is no judgement left: the category is already decided, so you map one tool deterministically with no AI cost. Set channelId to the Front channel ID for that category's inbox, set to to the array of teammate or queue handles that should own it, and put the triage summary and original message in body.

channelId: cha_loyalty_inbox_id
to:        ["loyalty-desk@yourpharmacy.example"]
subject:   New loyalty inquiry: {{ input.subject }}
body:      <p>{{ triage.summary }}</p>
           <p>From: {{ input.from }}</p>
           <p>{{ input.text }}</p>

The body field supports HTML. Repeat the node on the returns, supplier, and general branches, changing only channelId and to so each inquiry lands with the team that owns it. If you also want to label conversations, you can add a second front Direct-mode node using the add-tag tool.

Step 5: Acknowledge the sender with a Send Email node

After the branches reconverge, add a Send Email node that replies to the original sender. Send Email uses Spojit's built-in mail service, so no connection is needed. Set Recipients to {{ input.replyTo }} (the Mailhook trigger always exposes the sender's reply address there), write a templated Subject and Body, and keep the wording purely transactional: confirm receipt and set an expectation, nothing clinical.

Recipients: {{ input.replyTo }}
Subject:    We received your message: {{ input.subject }}
Body:       Thanks for contacting us. We have received your
            message and routed it to the right team at our store.
            A team member will follow up with you shortly.

Set If sending fails to Continue anyway if you would rather the run still complete the Front filing even when an acknowledgement bounces. Remember that external recipients must be on the org allowlist under Settings > General > Email recipients, and that each acknowledgement counts toward your monthly email allowance.

Step 6: Save, name, and enable the workflow

Give the workflow a clear name such as "Store inquiry triage", save it, then enable it from the workflow list. From that point, every email forwarded to the Mailhook address starts a run automatically. You can watch runs in the execution history to confirm the trigger fired, the classifier returned a clean category, the correct front inbox received the message, and the acknowledgement was sent. If you prefer to scaffold this faster, open Miraxa, the intelligent layer across your automation, and describe the flow in a sentence; it can add and connect the nodes on the canvas for you, then you fine-tune fields in the properties panel.

Tips

Read your Front channel IDs once with the list-inboxes tool on the front connector, then hard-code them per branch in Direct mode so each run stays fast and deterministic.
Use the Mailhook Subject regex or From allowlist filters to keep automated newsletters and spam from starting runs you do not want.
Keep the classifier prompt short and force the JSON shape with the Response Schema; this keeps AI cost low and makes the Condition node branch predictably.
Store the triage summary in {{ triage.summary }} so the Front message your team sees is a one-line overview, not just the raw email.

Common Pitfalls

Replying to the wrong field: use {{ input.replyTo }} for the acknowledgement, not {{ input.from }}, since some senders set a different reply-to address.
Forgetting the allowlist: if the customer's domain is not on the Email recipients allowlist, the Send Email step cannot deliver the acknowledgement.
Letting clinical questions get auto-answered: never add an automated reply that gives health guidance. Keep clinical-adjacent messages flowing to the general admin queue for a person to handle.
Regenerating the Mailhook address: Regenerate address kills the old address instantly, so any forwarding rules still pointing at it stop firing until you update them.

Testing

Before enabling broadly, send a few test emails to the generated Mailhook address: one clear loyalty question, one return request, one supplier note, and one vague "do you have something for a headache" message that should land in general. Open the execution history and confirm each run classified correctly, posted into the expected Front inbox, and sent exactly one acknowledgement to your own test address. Start with the Send Email step set to Continue anyway so a delivery hiccup does not mask a routing problem, and only widen the From allowlist once the categories look right.