Services Where Humans Handle Only the Final Click for Bookings and Applications

A web assistant that used to read pages is starting to click buttons

OpenAI now provides a cloud browser inside ChatGPT Work. A cloud browser opens websites on a remote computer separate from the user’s own device, reads their content, clicks buttons, and fills in fields. Its earlier dedicated browser, ChatGPT Atlas, ended on August 9, 2026.

The feature is being rolled out to some paid accounts in supported regions, including South Korea. It is not available on free accounts, and it may not yet appear even on the same paid plan, depending on an organisation’s administration settings or rollout order.

When entering a new website, the user grants access. The three settings are ask every time, auto-approve, and always allow; OpenAI does not recommend always allowing every site. At login, users use a separate secure input screen rather than entering a password in the chat.

Granting site access does not mean every action is allowed. Before actions tied to money or commitments—such as payments, confirming bookings, sending emails, or changing accounts—the system asks the user again for confirmation. Service operators can now place a human approval step between information gathering and final execution.

The points where this model can fail are also clear. Some sites block automated interaction, and attacks in which AI mistakes text on a webpage for a user instruction have not yet been solved. A service that tries to hand over everything from the start can lose trust through a single malfunction.

How this could change a day at a 12-person window and door contractor

Consider the owner of a window and door installation company with 12 employees. After receiving site measurements, the owner opens several material vendor sites to check specifications and stock, then re-enters the same address and business details in each quote-request form. When a customer changes the schedule, the installation team’s schedule and planned order date also need updating.

Today, the owner repeatedly logs into different sites and copies model names and quantities from one screen to another. A phone call can interrupt the work, making it easy to lose track of which vendor has been checked or select a similarly named product by mistake. Reviewing everything again before clicking order can take longer than the automation itself.

With a web-task assistant, the owner could enter the site name, specifications, quantity, and preferred installation date once. The assistant opens approved vendor sites in sequence, gathers stock and delivery information, and prepares quote requests or shopping carts up to the point just before ordering. If login is required, it stops and shows the owner the login screen.

The owner’s screen should resemble an approval inbox more than a chat window. On one page, it should show the item, quantity, supplier, price, delivery date, original webpage URL, and what has changed. A quote can be sent or an order confirmed only after the owner approves it.

Many tasks still remain with people. AI has difficulty deciding whether site measurements are correct, whether substitute materials are acceptable, or whether to renegotiate price with a supplier. People should also handle cancelling problematic orders and explaining delays to customers.

If this service fails, the likely problem is the choice of workflow rather than AI capability. Tasks that happen only once or twice a month, require identity verification on every site, or involve more exception judgment than data entry will only create more approval requests. A better small starting point is work where the same information is frequently moved across several sites and only the final confirmation requires care.

The first product, then, is not an assistant that replaces all web work. It is a service for one recurring task in one industry, divided into preparation, review, and confirmation, with the assistant responsible only through preparation. It should preserve the pages visited and information entered in sequence so a person can continue when the task stops.

Abroad, the first work handed over was repeated portal work

Commure, a US healthcare operations service, automated work in which hospital staff logged into insurer portals to check claim status and download insurance-benefit documents. Using Browserbase’s remote browser, it made the execution screen available for real-time monitoring and recording, with costs based on browser-use time and the number of screens opened simultaneously.

A Browserbase customer case says this reduced more than 8,000 hours of manual work over three months and increased daily claims throughput twentyfold. These are vendor-reported figures and need independent verification. The starting point was narrow: checking status and retrieving files from existing insurance portals, not diagnosis.

US insurance broker USI Insurance Services used UiPath to automate insurance placement, payment processing, and data entry. Cases requiring judgment were sent to a human review inbox called Action Center, while Action Center task and process audit logs were centrally stored in Orchestrator. Enterprise pricing is quoted separately according to the number of users and the scale of automated runs.

UiPath says USI saved 30,000 hours annually, reduced insurance-placement data-entry time by 80%, and reduced payment-processing time by 20%. This represents work that several employees would repeat over years, but these too are vendor customer-case figures. The important point is not that people disappeared, but that exceptions and approvals were brought into one place.

Numeral, a US service, handles tax portals across 48 US states for online sellers that sell products in multiple states. It deals with state-by-state logins, two-factor authentication, permission registration, and filing screens. The service does not disclose its price. Its underlying browser service charges based on usage time and execution volume.

At first, it had to build fixed procedures for each portal over several days. It is now expanding toward finding its way again even when screens change. Because this includes hard-to-reverse actions such as filing submissions, customer permission and final review are especially important. Whether it works at the same level across every portal nationwide needs separate verification.

Four things you could build now

1. A pre-order review inbox for materials

• What it does: Collects stock and delivery information from several wholesale sites, then prepares quote requests or shopping carts until just before confirmation.
• Who uses it: Owners or site managers who handle material orders at window, door, or interior-construction contractors with around 10 employees.
• Why now: The assistant can read websites and enter information directly while keeping order confirmation under human approval.
• First screen: For each site, place item, supplier, price, delivery date, and an awaiting-approval button side by side.

2. A scheduling inbox for mobile repair visits

• What it does: Checks booking sites and technician schedules, finds available visit times, and prepares change notices to send to customers.
• Who uses it: Boiler and appliance repair companies with around five employees that receive both phone and web bookings.
• Why now: The system can handle finding times and entering details while staff decide on the customer message and booking confirmation.
• First screen: Show bookings that need changes, three possible times, travel distance, and the message to send the customer.

3. Re-entering information for support-programme applications

• What it does: Moves a company’s basic information and recurring documents into fields across several support-programme sites and saves each application before submission.
• Who uses it: Administrative support staff at manufacturers with fewer than 20 employees applying for export, hiring, or equipment support programmes for the first time.
• Why now: It can read different site formats and fill drafts, though whether public-sector sites permit automated access must be checked first.
• First screen: Put the application deadline, still-empty fields, attached documents, and statements to review before submission in one place.

4. An approval log for web tasks

• What it does: Records what AI plans to change on a site, with before-and-after screens, and sends it to an approver.
• Who uses it: Franchise operations teams that update operating hours, menus, and notices across portals for multiple locations.
• Why now: As automated entry increases, a record of what was approved and by whom becomes as important as the service itself.
• First screen: Sort pending approval tasks by risk level and show before-and-after content, target site, and scheduled execution time.

Today’s check

Ask one person who actually handles work in a candidate industry to show you their screen for 30 minutes. Follow one task from start to finish where the same information is moved into two or more places. If it repeats several times a week and can be temporarily saved or reviewed before final confirmation, it may be worth building a pilot. If human judgment is needed constantly during entry or identity verification must start over every time, look for another workflow.

Why this matters where you are

Look for work in your market where staff repeatedly move the same information between portals, but can still pause before a payment, booking, or submission. The portals, login requirements, and rules on automated access will differ by market and by industry. A practical first step is to identify one narrow workflow where a human approval inbox can contain the risk.

Sources

• ChatGPT cloud browser usage guide
• Notice on the transition away from Atlas browser-task features
• Atlas protections against webpage-instruction attacks
• Security research on agentic browsers
• Commure insurance-portal automation case study
• USI Insurance Services automation case study
• Numeral case study on state tax portals