Email sits in three mailboxes, approvals in the OA system, alerts in a monitoring channel, tickets somewhere else, and newsletters everywhere. DQ INBOX pulls them into one timeline. AI de-duplicates, summarizes and weighs each item, then surfaces the ones that need you. Everything else stays out of your way but goes into a knowledge base. Three months later you can ask "what did that supplier say back then?" and get the answer with the original attached.
Below is the full processing record for a supplier email, from arrival to archive. Every step is logged, so you can always go back and see why it was handled the way it was.
Ingest fixes scattered, understand fixes long, triage fixes too many, memory fixes forgotten. Drop any one and you're back where you started.
Multiple mailboxes, IM group messages, OA approvals, tickets, monitoring alerts, system notices and newsletters flow into one timeline. Mailboxes connect read-only through official authorization; IM and system notices connect through open APIs or webhooks. No source system has to change.
Quoted replies, signatures and boilerplate get stripped. People, companies, projects, amounts, dates and to-dos get picked out. A long email becomes one line, and a burst of alerts becomes "the same fault, occurrence #n" instead of twenty separate pings.
Each item is rated action needed, worth knowing or archive only. Action items go to the right person with a deadline. Worth-knowing items go into a daily digest. Archive-only items bother nobody but are still stored. You can change the rules, and every decision shows its reasoning.
Every message is filed onto the timeline of its person, company and project, building a knowledge base you can question in plain language. Answers must cite the original email or message, which opens in one click. If there's nothing on record, it says so.
Every channel connects read-only. DQ INBOX never sends mail for you, never clicks an approval, and never changes anything in a source system.
Every mailbox connected, including the junk folder, where login codes and bills often end up.
The few lines in a group chat that you actually need get pulled out of the hundreds of casual ones.
Repeated alerts are grouped into one incident, so you can see whether it's new or a relapse.
Every message follows the same pipeline from arrival until it can be searched. If a step fails, the original is kept and the reason recorded. Nothing gets dropped silently.
Mail is pulled incrementally through official authorization; IM and system notices are pushed in via open APIs or webhooks. A full copy of the original is always kept.
Every channel's format is mapped to one structure: sender, recipients, time, body, attachments, source. Quoted replies and signatures come off emails.
A message cc'd to several mailboxes is kept once. Consecutive alerts for the same fault become one incident with a running count.
People, companies, projects, amounts, dates, to-dos and tone are picked out, and a one-line summary is written.
Rules sort each item into action needed, worth knowing or archive only. Action items reach the owner with a deadline and the reasoning.
Each item is attached to its person, company and project timelines, indexed by vector and keyword, and linked to related exchanges.
From then on it answers plain-language questions with links to the originals. The daily digest collects the worth-knowing tier.
These are the defaults. You can override them per person or department, and the reasoning behind each decision is always visible. It isn't a black box.
| Message type | Signals | Tier | Where it goes |
|---|---|---|---|
| Customer / supplier email | Deadline, amount, contract or a request to confirm | Action needed | Pushed to the owner immediately, with the deadline |
| Approval pending | Needs your approval and is close to timing out | Action needed | Pushed now, reminded once more before timeout |
| Monitoring alert | New fault, or the same fault recurring within an hour | Action needed | Sent to on-call, repeats grouped |
| Group chat message | Mentions you, or includes a to-do and deadline | Action needed | Pushed with the surrounding discussion |
| Internal notice | Relevant to your department | Worth knowing | Daily digest |
| Ticket status change | A ticket you follow | Worth knowing | Daily digest |
| Newsletter | — | Archive only | Not pushed, searchable |
| Automated notice | Login alerts, marketing, no action required | Archive only | Not pushed, searchable |
Most of what an organization knows never gets written up as a document. It lives in email threads and group chats. DQ INBOX organizes that part automatically, threading it into timelines by person, company and project.
Every customer, supplier and project gets its own timeline, threading together email, chat and tickets in order.
"How many times did Huachen raise prices this year?" "How was that alert eventually fixed?" Just ask; no keywords to remember.
Every conclusion shows which email or message it came from, and when. One click opens the original.
With nothing on record it answers "no related exchanges found" rather than inventing a plausible reply.
The biggest risk in centralizing messages is widening access. The rule here is simple: if you can't see it at the source, you can't see it here.
Every channel connects read-only. It doesn't send mail, click approvals, post in groups or change anything in a source system.
Each message keeps the visibility it had in its source system. Searches are filtered by the asker's permissions before AI sees anything.
Login codes, ID numbers and bank accounts are handled separately on ingest and replaced with placeholders before any cloud model call.
Each search records who asked, what, which messages matched and what came back. Admins can export by person or period.
Capabilities are the same in every setup. What differs is where the messages and models live. If your email content is under strict confidentiality rules, go private.
| Deployment | Message storage | AI processing | Data egress | Best for |
|---|---|---|---|---|
| Hosted | Cloud environment you nominate | Cloud models | Leaves masked | Teams proving value first |
| Hybrid | On-premise | Cloud + private models | Sensitive channels stay in | Most mid to large enterprises |
| Fully private | On-premise | Private models | Nothing leaves | Finance, legal, regulated |
| Item | Details |
|---|---|
| Connection | Mailboxes read-only via official authorization; IM, approvals, tickets and alerts via open APIs or webhooks |
| Backfill | On connection, historical mail and messages can be imported over a range you choose |
| Originals | The original message is always kept; AI summaries and decisions never overwrite it |
| Triage rules | Defaults work out of the box; override per person, department or source; reasoning shown every time |
| Citations | Every answer must cite its source messages; with no evidence it says nothing was found |
| What it does not do | Send mail, click approvals, post in groups, modify any source system, or store mailbox passwords |
After a week you'll get a breakdown: how many messages came in, how many really needed you, and how many it kept out of your way while still keeping them searchable.
Book a demo