Skip to content

SMART INBOX

One inbox that shows the job, not just the message

A customer request rarely arrives as a request. It arrives as a forward of a forward, with a signature block under it, a quoted reply under that, an attachment in whatever format was to hand, and the actual question three paragraphs down. Markyard puts every one of them into a single operational inbox, beside the job details it read out of them.

An inbox, plus job context

A mail client shows

One message, opened one at a time.

Markyard shows

One job: what was asked for, what is known, what is missing, and what happens next.

WHAT ACTUALLY ARRIVES

Every request has to be read by a person first

Nothing about a print inquiry is standardised. It is written by whoever needed the shirts, forwarded by whoever holds the budget, and answered inside a chain that already has three messages in it. Before anyone can price it, somebody has to read the whole thing and work out what is actually being asked for.

That reading is most of why quoting takes twenty minutes to three hours today. Five minutes is the target, and the reading is the part that has to go.

  • A forward of a forward

    The original request sits under two layers of routing, each with its own header block and its own greeting.

  • Quoted replies

    Half the thread is a copy of the other half, and the newest information is not reliably at the top.

  • Signature blocks

    Contact details, a legal footer and a logo image, repeated on every message in the chain.

  • Attachments in awkward formats

    A logo pasted into a text document, a photograph of a printed sample, a file that is a screenshot of a file.

  • The question, three paragraphs down

    Quantity, deadline and print method get mentioned in passing, inside a sentence about something else.

None of this is a complaint about customers. It is simply what a request looks like when the person writing it does not buy print for a living.

ONE OPERATIONAL INBOX

From a forwarded thread to a job with a next action

One inquiry, held three ways: the message exactly as it arrived, the job read out of it, and the reply prepared from what is still missing. The customer, the subject and the attachments stay attached to all three, so nothing has to be looked up somewhere else.

  1. As it arrives

    Illustration of a forwarded customer inquiry as it arrives in the mailbox. Sample data, not a live account.

    Custom T-Shirts for Event

    Inbox

    From Dana Reyes, forwarded twice

    Fwd: Fwd: shirts for the company day

    Hi! We are doing a company thing next month and need some shirts, maybe 50 to 100 people going? Logo on the front, navy or black. Need them by the 15th, see below.

    Thanks, Dana. Northbridge Events, Frankfurt am Main.

    logo-final.pngbriefing.pdf
  2. As Markyard reads it

    Illustration of the same inquiry held as a job: extracted fields with confidence, the missing fields, and the next action. Sample data, not a live account.

    Inquiry MY-0312

    Missing info

    Dana Reyes, Northbridge Events

    ProductT-ShirtsHigh
    Quantity50 to 100Medium
    DeadlineThe 15th
    • Print method not stated
    • Size run not given

    Next action: ask for the two fields above, then price it

  3. What Markyard prepares

    Illustration of a draft reply prepared from the missing fields and held for human approval. Sample data, not a live account.

    Draft reply

    Held for review

    Hello Dana,

    thank you for the inquiry. To price it accurately, could you confirm the print method and the sizes you need? The logo you attached is being checked in the meantime.

    Kind regards

    Nothing here is sent until a person on your team approves it. That gate lives in the database, not only in the interface.

Every name, number and file above is sample data, written to show the shape of one inquiry. No customer of any print shop appears on this page.

THE DIFFERENCE

Markyard is not an email client

A mail client is built to move messages. It shows what arrived, in the order it arrived, and leaves the reading to whoever opens it. That is the right design for correspondence and the wrong one for a shop floor, where the unit of work is not a message but a job.

Markyard is an inbox plus job context. The same addresses, the same threads, the same customers. What changes is the question the screen is answering.

A mail client answersMarkyard answers

Did something arrive?

What was asked for?

Who sent it, and when?

What is already known, and how sure is the reading of it?

Is there an attachment?

Is the artwork usable at the size that was requested?

Have I replied to this one?

What is still missing before a price can be set?

Which folder is it filed in?

What is the next action, and who has to approve it?

New

Pulled in from the connected mailbox, deduplicated against what is already there, not yet looked at.

In progress

Details read out, gaps flagged, waiting on your team or on an answer from the customer.

Answered

An approved reply has gone back into the same thread the customer already had open.

Closed

The job is done, or it went elsewhere. Either way it stops asking for attention.

WHAT IS RUNNING TODAY

What is built, and what is still blocked

The inbox above is the design, and parts of it are much further along than others. Both gaps below are recorded in the project status, and neither one is dressed up here as something that already runs.

Written and tested

In the codebase now

  • The extraction code and its prompt, with a confidence score kept per field rather than one score for the whole message
  • A rule that a value not present in the email does not exist, so a missing quantity stays missing instead of becoming a plausible number
  • The inquiry tables, with tenant isolation enforced by the database itself and proved by a test rather than by application code
  • Classification of the messages that are not inquiries at all: newsletters, out of office replies, invoices, cold outreach
Not live yet

What is still blocked

  • Connecting a Gmail account. The Google credentials this needs do not exist yet, so no mailbox has ever been connected.
  • Extraction against a live model. The code is written and covered by unit tests that make no network calls, and it has not yet been run against the model it is written for.

Until both are cleared, no print shop is being served by this inbox in production. Saying otherwise would be the easiest claim on this site to disprove.

SMART INBOX, ANSWERED

Quick answers about the inbox

Does this replace my email?
No. Your mailbox stays where it is, at the address your customers already write to. Markyard reads from it and, once a person approves a reply, sends back into the same thread. Nothing is copied out by hand and no customer is asked to learn a portal.
Can I connect my Gmail today?
No. Connecting a mailbox needs Google credentials that do not exist for this project yet, so the connection has never been made. Everything on this page describes how the inbox is built to work once it is.
Has the extraction run against a real model?
Not yet. The extraction code, its prompt and its handling of forwards, signatures and quoted replies are written and covered by unit tests that make no network calls. It has not been run against a live model, and this page does not claim otherwise.
What happens to a message that is not an inquiry?
Newsletters, out of office replies, invoices and cold outreach all reach the same mailbox. The extractor is built to mark those as not an inquiry and give a short reason, rather than open a job for them.
Does anything reach a customer on its own?
No. Every outbound message waits for a person to approve it, and that gate sits in the database rather than only in the interface, so there is no path around it.

See it against your own threads

Start a trial to follow one of your own inquiries through the inbox, or book a demo and we will walk the whole path together, forwarded signature blocks included.