Product capabilities

The first screen is a question: what do you need? A person says it, types it, photographs the nameplate or drops in a spreadsheet, and Konyx turns it into a structured request — items, quantities, part numbers, manufacturer, urgency — then asks one or two specific questions with the usual answers ready to tap.

Every extracted field carries a state — confirmed, inferred or unknown — and the request's confidence is computed from those states in code, not reported by the model. The person sees the draft, corrects anything, answers the open questions and confirms; nothing is created until they do. A short answer such as a size is enough on its own, and follow-ups re-send the original photos so the model still sees the item.

It works on a phone browser on the plant floor: the composer is pinned at the bottom, the draft opens as a sheet, and voice is transcribed on the server when the browser cannot do it.

Inputs

• typed text
• voice
• photos (nameplates, labels, the part itself)
• spreadsheets and CSV files

Outputs

• a structured request with one line per item
• per-field confirmed / inferred / unknown state
• clarifying questions with tappable answers
• catalog matches and purchase history per line
• vendors ranked with reasons

Not in v1

• barcode scanning
• email-to-request
• a native mobile app

Related: Matching against the company's own catalog · Vendors ranked with reasons · Step 1 — Ask · The technician does not know the part number

Source: konyx-erp — the Ask Konyx screen; prompt request-extract v4 · Checked 26 September 2026 · Version 1 · capabilities.ask-konyx

Every request line is matched against what the company already buys — its item master and its vendors' catalogs — by part number and normalised description. It is a lookup in the database, not a model's guess: nothing a model invents, a record found in the company's own data.

Matching is identifier similarity: a request for a Lovejoy L190 finds the catalog's Lovejoy L-190. Each match carries the vendor that sells it, the contract or catalog price, and the vendor's own part number. A stated manufacturer must agree on both sides; when two catalog rows disagree Konyx leaves the match blank rather than guess, because a wrong part number on a document a vendor ships against is worse than none.

A row only counts as the item when it is the item: the size (2", 2 in and 2-inch are the same), the material and grade, the end connection, the pressure rating, the maker and any code written into the description must agree, and a 3-way valve or a repair kit is not the valve. A vendor that only has other sizes or materials is shown as having similar items — never pre-selected as carrying it.

Method

Trigram and word similarity in Postgres on normalised names and part numbers, scoped to the company, then a same-item check on size, material, ends, rating, maker and codes — in code, not a model

Outputs

• matched item
• vendor and price
• the vendor's own part number
• contract price when one exists

Related: Purchase history beside every line · Vendors ranked with reasons · Which AI models does Konyx use, and what sees our data?

Source: konyx-api — core/item-match.ts · Checked 28 September 2026 · Version 2 · capabilities.catalog-matching

Under each line of a draft, Konyx shows whether the company bought this before — from its imported purchase history, earlier quotes and earlier requests — and what it paid. The same last-paid price sits beside every quote later.

This is a query over the company's own rows, so it costs nothing and cannot hallucinate. It is what makes a quote comparison credible: you paid this in August; this quote is that.

Sources

• imported purchase history
• quotes received in Konyx
• earlier requests

Shown

• on the intake draft
• on the request page
• beside every quoted line

Related: Quotes side by side · What did we pay last time? · Spreadsheets and CSV

Source: konyx-api — core/purchase-context.ts · Checked 26 September 2026 · Version 1 · capabilities.bought-before

For every request, the company's own approved vendors are ranked best-first with the reasons on the card: how many lines they carry, exact part-number hits, the lowest price on a line, volume pricing, and whether there is someone to email. Then the Konyx network, then vendors found on the open web.

The buyer picks from one list. Ranking is explainable arithmetic over the company's data, so two buyers see the same order and can say why a vendor is first.

Order

• the company's own vendors
• the Konyx network
• vendors found on the web

Reasons

• lines covered
• exact part numbers
• lowest price on a line
• volume pricing
• contactable

Related: The Konyx network · Vendor discovery on the open web · One RFQ to all the vendors

Source: konyx-api — core/vendor-rank.ts · Checked 26 September 2026 · Version 1 · capabilities.vendor-ranking

The Konyx network is a set of vendors and catalogs maintained by Konyx, suggested beneath a company's own vendors only when a catalog line actually matches the request. Choosing one copies it into the company's own list.

Network vendors are platform data, not any customer's. A company never sees another company's vendors; it sees Konyx's, and only where they carry the part.

Related: Vendors ranked with reasons · What is the Konyx network?

Source: konyx-api — platform vendors and catalogs · Checked 26 September 2026 · Version 1 · capabilities.konyx-network

For niche parts nobody in the company's list carries, Konyx searches the web, filters the results cheapest-first, reads the survivors' contact pages, scores each candidate with the score's parts kept, and shows a Found on the web section — with contacts and reasons. Nothing is emailed until a person picks the vendor and checks the address.

Search returns links and snippets without fetching pages; a denylist, free heuristics and one cheap model call remove retailers and noise before any page is read. Each find is kept as platform data with its product pages crawled afterwards, so the next request from any company benefits.

The page the search found is read for the product on it before the answer comes back — the vendor's SKU, the maker's part number and the maker, from the data shops publish for search engines, from labelled text, or from a short model read of that one page. The card says how the vendor lists the item, and that vendor's RFQ carries their number.

Discovered vendors are gated behind buyer review by design: it is the quality gate, the deliverability gate and the legal gate in one.

Outputs

• candidate vendors with domain, contact and reasons
• the product on the page each was found on, with its part number and maker
• an explainable confidence score
• their catalog, crawled in the background

Never does

• email a discovered vendor automatically
• scrape a search engine directly

Related: Discovered vendors are reviewed · A rush part with no known supplier

Source: konyx-api — core/discovery · Checked 28 September 2026 · Version 2 · capabilities.vendor-discovery

A buyer drafts one request for quotation, sees the exact email each vendor will receive — subject, opening, note, deadline, the vendor's own quote link and their own part numbers — and presses Send. RFQs are never sent automatically: sending is a separate permission from drafting.

Each recipient's copy is rendered on its own, so the greeting, the reply address and the item numbers differ per vendor. Replies can come back into Konyx or go straight to the team's own inbox, by company setting. A draft can be deleted while nothing has gone to a vendor.

A request has one draft at a time: choosing other vendors changes that draft rather than starting another. The request stays with the buyer while the RFQ is a draft and reads RFQ sent once it has gone out.

Every item table reads: item number (that vendor's own code), item, description, manufacturer, quantity — the way a vendor identifies a part. When the request names no maker, each vendor sees the one they list the item under.

Send from

• Konyx
• the buyer's own mailbox, via their mail app

Replies to

• Konyx
• the team's own inbox

Permission

rfq.send, separate from rfq.create

Related: Sending from the buyer's own email · The vendor's quote link · A person presses Send · The same gasket has a different number at every supplier

Source: konyx-erp — RFQ page and send screen · Checked 28 September 2026 · Version 2 · capabilities.rfq

An RFQ or a purchase order can go out from the buyer's own mailbox instead of a Konyx address. Konyx prepares each vendor's message and the buyer sends it from their own mail app, then ticks the recipients they sent; quotes still come back through the vendor's link.

Some plants must send from their own domain by policy, and a message from procurement at the customer's own domain lands better than one from a platform. A per-company default chooses the mode; the send screen can switch it.

Related: One RFQ to all the vendors · Email · Vendors must hear from the plant's own domain

Source: konyx-erp — send screen, mailto mode · Checked 26 September 2026 · Version 1 · capabilities.own-email-sending

Vendors answer an RFQ through a link in the email — no account, no login. They price each line, state lead time and terms, and can revise; every revision is kept, never overwritten.

The link is unique to the vendor and the RFQ and is rate-limited. Quotes land in Konyx as comparable lines the moment they are submitted.

Related: Quotes side by side · Do our vendors need an account?

Source: konyx-erp — portal pages; konyx-api — portal · Checked 26 September 2026 · Version 1 · capabilities.vendor-quote-portal

Quotes come back into one grid: every vendor's price per line, the lowest highlighted, beside what the company last paid. The buyer picks the winning lines and issues the purchase order from them.

Lines are compared as lines, not as documents, so a partial quote and a full one sit in the same table. On a phone the grid stacks into labelled cards.

Related: Purchase history beside every line · Purchase orders from a quote

Source: konyx-erp — quote comparison grid · Checked 26 September 2026 · Version 1 · capabilities.quote-comparison

Anyone holding the po.issue permission can turn chosen quote lines into a purchase order at the quoted prices, numbered with the company's own prefix and carrying its ship-to address, terms and standard conditions. The order reaches the vendor one of three ways and always says which.

Konyx can email the order with the PDF attached; the buyer can send it from their own mailbox and mark it sent; or Konyx emails the buyer a copy to forward. Order lines snapshot the vendor's part number and the specification at issue time, so a later catalog import can never change a document a vendor already filed.

Issuing the order walks the request to Ordered; the RFQ closes when every line is ordered. Approval rules are planned; until then the issuer's permission stands in.

Permission

po.issue

Company settings

• PO number prefix
• ship-to
• payment terms
• standard conditions

Output

a PDF and an email, or the plain text for the buyer's own mail app

Related: Quotes side by side · Approval rules and the simulator · Who can issue a purchase order?

Source: konyx-api — core/purchase-order.ts, core/po-pdf.ts · Checked 26 September 2026 · Version 1 · capabilities.purchase-orders

A request moves through an eleven-state lifecycle behind one guarded transition function. Someone who cannot source it themselves sends it up the supervisor chain to the first person who holds the needed permission; notes travel with the request; a bell announces anything that happens to yours.

Escalation is mechanical: the first person up the chain with the permission, then any holder, the owner last — so a request cannot dead-end because a direct manager lacks the right. The requester can amend a request from Ask Konyx while nothing has gone to a vendor.

Notifications are written in the same transaction as the thing they announce — a request sent to you, a note, a change, a quote back, an order issued.

States

eleven, with an explicit allowed-transition map

Notes

plain messages between the requester and whoever the request is with

Bell

polled every 45 seconds and on focus; no sockets

Related: Roles and permissions · An employee who may raise a request but not send an RFQ · Where is my request?

Source: konyx-api — core/request-state.ts, core/approver.ts, core/notify.ts · Checked 26 September 2026 · Version 1 · capabilities.request-routing

Each company defines its own roles from 26 hard-coded permission toggles. A person holds the union of their roles; the owner holds everything. Requesting, drafting an RFQ, sending it and issuing a purchase order are separate permissions.

That matches how procurement delegates: an administrator grants one maintenance lead the right to send RFQs without promoting them. Default roles come with every company, including Procurement and a built-in Super user, and can be cloned and changed.

Permissions

26, as a closed list checked on every API call

Examples

• request.create
• rfq.create
• rfq.send
• po.issue
• request.assign

Related: Permissions on every call · Routing, escalation, notes and notifications

Source: konyx-api — authz; 26 permissions · Checked 26 September 2026 · Version 1 · capabilities.roles-and-permissions

Every action — who, what, when — is written to an append-only log in the same transaction as the change, and shown in plain sentences on the request, the person and the company.

The log is append-only at the database level, not by convention. Changes made by Konyx staff through the console are written as done by Konyx, so a company can always see what its vendor did.

Related: An audit trail that cannot drift

Source: konyx-api — core/audit.ts · Checked 26 September 2026 · Version 1 · capabilities.activity-log

From one export of a company's purchasing history, Konyx computes what it would have saved: price gaps against the company's own best price and the Konyx network, cycle time, late deliveries, quote competition, rush and card spend, and buyer hours — then writes the findings up as a five-page report.

Every figure is computed in code from the file; the model only writes the narrative from those figures. The audit runs before any contract and is how a pilot's baseline is set. It is prepared by Konyx staff from the company's file, not self-served.

Input

one CSV of purchase orders or lines, any column names — mapping is confirmed on screen

Outputs

• money: price gaps and where they are
• buyer hours and calendar days, manual process versus Konyx
• findings, price gaps, vendors, method
• a PDF report

Related: Baseline — before any contract · How savings are measured

Source: konyx-admin — Audit page; konyx-api — core/savings-analysis.ts · Checked 26 September 2026 · Version 1 · capabilities.savings-audit

For every RFQ that goes out, Konyx sets what it would have taken a buyer by hand against the time it actually took in Konyx — per RFQ, per company and across the platform. By hand is estimated step by step from the RFQ's own items, vendors, new vendors and quoted lines; in Konyx is measured from the recorded steps, with idle time capped.

In Konyx runs from the first thing the person asked Konyx for the request to the moment the RFQ went out, adding the time between each recorded step — model calls and every logged action. A pause longer than ten minutes counts as ten, so a draft left overnight is not counted as a night's work. The clock time from first question to sent is shown beside it.

By hand counts only the steps that applied: going back to the requester for details, checking stock and past prices per item, finding each vendor (a vendor new to the company takes longer than one on file), writing the RFQ and typing each item, emailing each vendor, retyping each quoted line that came back through the vendor's link, and laying two or more quotes side by side. The minutes per step are set by Konyx for every company and listed on the page; nothing is estimated by a model.

A company's people with the analytics permission see the Time saved page and a line on their overview; anyone who can read RFQs sees the figure on each sent RFQ. Konyx staff see every company and the platform total, and set the minutes.

Measured

• time in Konyx, first question to sent, idle capped at 10 minutes
• clock time, first question to sent

Estimated per RFQ (built-in minutes)

• clarify the request: 10 per request
• stock and past prices: 4 per item
• vendor on file: 5 each
• new vendor: 30 each
• write the RFQ: 10, plus 3 per item
• email each vendor: 4
• retype a quoted line: 2
• compare two or more quotes: 10

Also shown

• value of the time at a buyer's hourly cost, $45 by default
• medians per RFQ, both ways
• where the by-hand minutes would have gone

Related: How savings are measured · One RFQ to all the vendors · Customer results

Source: konyx-api — core/time-saved.ts; konyx-erp — Time saved page; konyx-admin — Time saved · Checked 1 October 2026 · Version 1 · capabilities.time-saved

Vendors and their catalogs come in from one spreadsheet, with contacts; columns are mapped with the model's help and confirmed on screen; every problem row is shown before anything is committed, per vendor; an import can be undone as a unit. The team comes in from a five-column CSV with invitation links.

Each row is judged after it is chosen, by its content rather than its file label, so a phone can pick the file and an Excel workbook gets a clear ask to save as CSV. A test set of 20 vendors and 6,600 catalog rows lands in about six seconds.

Vendor file

one CSV: vendor, contacts, item, part number, price ladder

Team file

ID, Name, Email, Role, Manager

Purchase history

any export, mapped on screen — used by the savings audit and for last-paid prices

Planned

• inventory
• open purchase orders
• contracts

Related: Spreadsheets and CSV · Adoption — real requests from week one

Source: konyx-erp — vendor import, team import · Checked 26 September 2026 · Version 1 · capabilities.data-import

Each company has limits set by Konyx: how many people, how many RFQs a month, how many items on one RFQ. They are enforced in the API and shown to the company under Settings.

Defaults

• 5 people
• 250 RFQs a month
• 30 items per RFQ

Set by

Konyx, from the console; every change is written to the company's log

Related: What does Konyx cost?

Source: konyx-api — core/limits.ts · Checked 26 September 2026 · Version 1 · capabilities.plan-limits

Policy-based approval routing — by amount, category or exception — with a simulator that shows who would approve a given order before the rule goes live. Not shipped yet; today the issuer's po.issue permission stands in.

Related: Purchase orders from a quote

Source: Engineering Action Plan — §3.7, Next · Checked 26 September 2026 · Version 1 · capabilities.approval-rules

Reading a quote out of a vendor's emailed PDF or spreadsheet as a fallback to the quote link. Not shipped: vendor replies by email currently go to the team's inbox, and quotes come back through the link.

Related: The vendor's quote link · Email

Source: Engineering Action Plan — §3.6 · Checked 26 September 2026 · Version 1 · capabilities.email-quote-capture

Sending RFQs and orders through the buyer's mailbox by API, so they appear in Sent without the buyer's mail app being involved. Not shipped; own-email sending works today through the buyer's mail app.

Related: Sending from the buyer's own email · Microsoft 365 and Gmail

Source: Engineering Action Plan — Next · Checked 26 September 2026 · Version 1 · capabilities.mailbox-connectors

There is no iOS or Android app. The web application is built phone-first — voice, photos and the request draft all work in a phone browser — and nothing in the product requires an installed app.

Related: Ask Konyx — request intake · Does it work on a phone?

Source: Engineering Action Plan — Scope decisions · Checked 26 September 2026 · Version 1 · capabilities.native-mobile-app

Konyx never sends an RFQ, awards a quote or issues an order on its own. The AI interprets and prepares; a named person with the permission releases every send and every order. This is a design decision, not a missing feature.

Related: A person presses Send · Principles Konyx is built on

Source: Engineering Action Plan — §3.7, decision log · Checked 26 September 2026 · Version 1 · capabilities.autonomous-purchasing