A new layer of work tools: classify photos and inquiries, then ask for what is missing

A dedicated intake desk for repeated decisions

On October 6, 2026, OpenAI opened the Decisions API in public beta. An API is a connection that lets one service call a specific capability from another service over the internet. This tool receives text and images, then returns a decision in predefined categories instead of a long-form response.

Results can come in three forms: the likelihood that a condition is met, one choice from several options, or a predefined score from low to high. For example, it can sort an inquiry into “repair,” “new installation,” or “human review,” or indicate whether a submitted photo is likely to meet a requirement.

It can receive up to 128 images at once, but it cannot directly read external image URLs or stored-file IDs. It does not support audio, and it may refuse to answer some requests. A service therefore still needs a step that converts photos into the right format, plus a screen for handling cases where a decision is deferred.

OpenAI says the approach can make decisions up to 10 times faster than its previous method. That is the supplier’s own claim, not an independently verified result for Korean-language inquiries or blurry field photos. A real service should test accuracy and speed separately with historical materials.

The API is still in public beta, so its response format, pricing, and usage limits may change. It is difficult to delegate final automated decisions in hiring, lending, insurance, or healthcare, where one decision can affect a person’s rights or opportunities. The best early use cases are intake and classification tasks where a person can quickly correct mistakes.

Separate the intake desk from the larger customer-management tool

There was a reason inquiry classification was handled inside an entire workflow. Incoming text and photos vary widely, so each company had to create and keep revising its own classification rules. Building the full workflow alongside a single decision feature was often easier.

Consider the owner of a window-installation business with 12 employees. Inquiries arrive through the website, text messages, and email. Customers send window photos with short descriptions such as “cold air is coming in.” The owner asks again for the address, whether the job is a repair, the window type, and the preferred visit date, then copies the details to field staff.

For inquiries that cannot be assessed from photos alone, there may be two or three phone calls. A new-installation inquiry may go to a repair technician, or the team may discover only after a visit that a measurement photo was missing. Yet replacing the entire existing customer-management tool can mean burdensome staff training and data migration.

In the new approach, as soon as a customer submits text and photos, the inquiry is tagged as “repair,” “replacement,” “new installation,” or “human review.” At the same time, the service checks intake items such as “address included,” “full window photo included,” and “close-up photo of the problem area included.” It requests missing items with prewritten guidance and sends only complete cases to the staff screen.

The owner’s screen can stay small. Today’s inquiries can be divided into “contact now,” “waiting for materials,” and “needs human classification,” with the original text, photos, and decision result shown together beside each inquiry. When a classification is corrected, the service also records which criteria are frequently wrong.

The piece being separated here is not the whole customer-management system. It is “classification and requests for missing information immediately after intake.” Scheduling, estimates, and customer history can remain in the tools already in use. The new service can begin by sending structured results through email or a file.

Some work does not change. A skilled person still needs to confirm a cause from photos, approve an estimate, and decide whether a site visit is needed. There must also be a route to send low-confidence decisions or inquiries outside the available options to a person.

Intake and review have been improved separately elsewhere

Covered California, a health-insurance enrollment portal in the United States, tested Google Document AI for classifying and verifying identity and income documents submitted by users. In an environment processing about 50,000 documents across 56 document types each month, it sent low-confidence and exceptional cases to staff. This is an example of improving the document-review piece before changing the broader insurance-enrollment process.

According to a case study published by Google Cloud, the previous automated-verification rate was 28–30%, while the trial averaged 84%. The target was more than 95%, but the published figures come from a supplier-presented customer case study and do not guarantee the same outcome elsewhere. The institution’s contract value was not disclosed.

Wolt, a delivery company headquartered in Finland, separated the task of reading and classifying supplier invoices through the Rossum service. After adopting it in 2024, people reviewed exceptions and uncertain documents, while only confirmed results moved into the existing approval and accounting process. It was an approach that changed invoice intake and review before replacing the full accounting system.

A Rossum customer story says the company expanded to 11 countries with the same staffing level and processed an average of 60% automatically. The median review time for documents checked by people was 47 seconds, and adding one country took three to six weeks. These are also supplier-reported figures and need separate verification before adoption.

What could be built from this

1. A pre-visit screener for window consultations

This service reads photos and inquiries, sorts them into repair, replacement, new installation, or human review, and requests missing photos. It is for small window and insect-screen businesses that receive website inquiries but repeatedly make confirmation calls before site visits.

With a component that evaluates text and photos against the same criteria, there is less need to build an entire customer-management tool. The first screen has three columns: “inquiries to contact now,” “inquiries needing more photos,” and “inquiries for human review.”

2. A submission-envelope checker for support-program documents

This service reads submitted files and applicant answers, then sorts them into ready, missing documents, possible content mismatch, or human review. It is for manufacturing businesses with around 10 employees, no dedicated administrative staff, and a first-time application for employment or export-support programmes.

It is a good fit for a small service because it does not decide final eligibility. It only finds what is missing before submission. The first screen places the selected programme, required-document list, file upload, and a one-line missing-item result together.

3. A product-photo checker for online stores

This service sorts seller-uploaded photos into pass, reshoot, or human review according to predefined photography criteria. It is for food and household-goods manufacturers that have sold offline and are entering an online marketplace for the first time.

As image assessment becomes easier to build as a separate function, there is less need to buy an entirely new product-management tool. The first screen places an upload field for one main photo beside results for brightness, text readability, and full product visibility.

4. An issue-sorting inbox for apartment communities

This service sorts residents’ text and photos into facility faults, noise, parking, cleaning, or urgent review, then sends them to the responsible person. It is for management offices at mid-sized apartment communities that receive dozens of issues each day through phone calls and group chats.

Turning free-form complaints into a few handling routes fits the tool’s use case well. The first screen shows new issues, urgent reviews, unassigned items, and the original message together.

What to check today

Take 20 recent inquiries or applications and sort them yourself into four outcomes. If you can sort at least 16 using the same criteria without difficulty, and if at least four required another contact because information was missing, “classification and requests for missing information immediately after intake” is a candidate to build separately. Also check whether you can naturally define a “human review” category for the remaining four cases.

Why this matters where you are

You can check whether your own intake process repeatedly asks for the same missing information or sends the wrong kind of request to the wrong person. The categories, photo requirements, existing workflow tools, and rules for human review will differ by market and industry. Start with a narrow intake task where people can correct uncertain results, rather than replacing the full workflow.