We built Hey Button because a small business needs a teammate configured around how it already operates, with approval rules the owner controls from the first day. The two options most owners encounter first fail to do that. One is a chatbot widget that answers a fixed list of questions, and the other is an "AI employee" marketed like a hire you cannot genuinely manage. We avoid that term because it implies judgment and autonomy the software does not possess.
Why do we call it an AI teammate instead of an AI employee?
We call it a teammate because that word describes a role, a working relationship, and a clear boundary all at once. "Employee" implies autonomy and judgment that software does not have. Describing it as software that acts on your behalf is accurate, yet it tells a business owner nothing about whether to trust it with the inbox.
A teammate has a clearly defined job and works alongside you, while you determine what it can read, what it can draft, and what it may do without asking first. That final point carries the most weight. A lawn care owner deciding whether software can answer quote requests needs to know precisely where the line sits before anything goes out under the company name.
The trade-off is that "teammate" can sound like a person in the room, and we address that head-on. Teammates work through text, email, and forms, and we state plainly that they are software. If the word leads someone to expect more than that, the intake conversation is where the expectation gets corrected. You can see how teammates are described on the teammates page.
Why isn't a chatbot widget enough for a small business?
A chatbot widget performs well when every question has a fixed answer, but most small business work does not follow that pattern.
A website widget can share your hours, your service area, and a link to your contact page, yet it cannot recognize that a text from a regular customer requests to move a Thursday cleaning to Monday, verify the schedule, and draft a reply for your approval. Contractors receive messages in the middle of a job, and office staff receive emails that need a human decision. The work spreads across a shared inbox, a text thread, a web form, and a spreadsheet, and a widget only sees the single place where it lives.
| Website chat widget | AI teammate (Hey Button) | |
|---|---|---|
| Main job | Answers questions from a fixed list | Organizes incoming work across the tools you already utilize |
| Where it begins | Your website | An intake about how work arrives and where busywork piles up |
| Customer-facing actions | Limited to the chat window | Drafts and sends only within the approval rules you choose |
| Oversight | Chat logs | Access levels per task and a client portal |
The trade-off is simplicity, since a widget is quicker to understand and easier to explain to staff. If every question a customer requests already has an answer on one page, a widget may be all you need. A teammate earns its place when the work is messy, spread across several tools, and needs a person to make the final call.
What does Hey Button operate on, and what do we build ourselves?
Hey Button operates on open tooling, with OpenClaw serving as the automation framework and Hermes forming part of the underlying runtime. Claude and GPT models respond through that stack, depending on the task. We do not claim to have built a new AI model from scratch, and we state that plainly because a small business owner deserves an accurate picture of what they are trusting.
What we build is the layer that makes this practical for a small business, and that layer has three parts. The first is a business-first intake questionnaire that requests how work arrives, which tools you utilize, and where repetitive work accumulates. The second is model routing, covered in the next section. The third is a client portal, where you can observe what the teammate is doing and why.
The trade-off is dependence, because building on open tooling means your setup inherits both the strengths and the limitations of those projects. A model or framework update can change behavior, which is one reason the ongoing review in Mend exists. This approach also fails to suit every need, and if you want a model trained from scratch on your private records, Hey Button is not that product.
How does model routing choose a model?
Model routing selects the least expensive model that still performs the job correctly for a given request. If the first-choice model responds slowly or is unavailable, the system can fall back to another capable model.
Routing is a cost and reliability decision, not a permissions decision. A model switch never alters the teammate's instructions, your business facts, or the access boundaries you establish. When a different model answers a request, the same rules still determine what the teammate can read, draft, or send, and whichever model writes a draft, a reply to a client waits for your approval before it goes out.
Consider a small law office whose intake emails might be answered by one model on one day and by a backup model on another day when the primary model is unavailable. The office's rules stay fixed regardless of which model responds. The attorney still reviews every client-facing draft, and the portal still records what was sent.
The trade-off is that "least expensive model that still performs the job" is a judgment call, since a fallback model may produce a plainer draft or a less polished summary. That is one practical reason drafts go to a person before they reach a customer rather than being trusted automatically.
What happens during Stitch?
Stitch is the intake conversation in which we learn how work reaches your business, which tools you already utilize, and where busywork accumulates. The teammate is then configured around those actual workflows rather than a generic template that every business receives.
A typical Stitch covers four areas:
- Inbound channels. List every place work arrives, including shared inboxes, text threads, web forms, and any intake documents.
- Tools in utilize. Name the systems the work touches, such as scheduling software, spreadsheets, invoicing tools, or a practice management system.
- Repetitive tasks. Mark the jobs that take the most time, such as rewriting the same quote reply or chasing the same missing detail.
- Decisions only you make. Write down what should never be automated, such as price exceptions, scope changes, or anything involving a sensitive client matter.
Stitch needs your time at the outset, and that investment is the real cost of doing it properly. Skipping it produces a teammate that guesses at your work, which is worse than having no teammate at all. If your business has one inbox and one repeated task, a shorter intake may suffice, and we will say so during the conversation.
Which access level should each task get?
Each task receives its own access level, selected from three options: read-only, draft-and-approve, or full access. No single switch governs the whole business, because a teammate that can read your inbox does not need permission to issue a refund.
| Access level | What the teammate can do | Typical fit |
|---|---|---|
| Read-only | Reads and organizes information, and takes no outward action | Sorting an inbox before you determine anything |
| Draft-and-approve | Writes replies and proposed changes, and waits for your approval before anything goes out | Quote requests, customer messages, scheduling replies |
| Full access | Acts within the limits you set, without asking each time | Routine, low-risk tasks you have already watched it handle correctly |
Read-only suits work where the teammate should view and organize information but never act outward. Draft-and-approve suits most customer-facing work, because you review the wording before anything is sent. Full access suits routine tasks that you have already reviewed during Press.
The trade-off is speed against exposure. Full access saves review time, yet a mistake on a task you have not yet observed costs more than a mistake in a draft. AI can make mistakes, so review and explicit limits form part of the setup rather than an afterthought, and they are the reason access is configured task by task.
What happens during Press before anything touches a customer?
Press is go-live. You establish explicit approval rules governing what the teammate can read, draft, and do independently, then observe it handle real examples before anything touches a customer.
The sequence unfolds as follows:
- Write the rules task by task. Name what is always read-only, what always needs approval, and what needs your sign-off because it involves money or a sensitive change.
- Operate real past examples. Utilize recent inquiries or messages from your own inbox, and review what the teammate would have drafted.
- Correct what missed. If a draft left out the property address or used the wrong tone with a long-time customer, adjust the rule or the intake until the draft is right.
- Go live where the examples look right. Keep every other task in draft-and-approve until it earns a wider level.
Spending, customer messages, and sensitive changes remain behind the approval rules you select. You establish those boundaries during setup rather than leaving the software to infer them afterward.
The trade-off is time, since Press delays the moment the teammate begins saving you effort, and that delay is deliberate. A teammate that goes live before its rules are written produces mistakes that you then have to clean up in front of customers.
What does Mend cover after go-live?
Mend is the ongoing care that keeps a teammate useful as your business evolves. It has two components: tuning that people direct, and a client portal that displays what the teammate has been doing and why.
Tuning happens whenever the business changes, because a new service, a revised intake form, or a rule that proves too strict each leads to a setup change that passes through the same approval rules as the original configuration. The portal is where you verify that the teammate handles matters the way you expect, without needing to ask someone to pull logs.
Several examples illustrate the kinds of changes that happen in Mend. A lawn care business that adds snow removal needs new questions in its quote intake, while a cleaning business that begins offering move-out cleaning needs a separate scheduling reply. A small law office that revises its intake form needs the questions reordered so the most important details come first.
The trade-off is that Mend needs attention from someone on your side. If nobody reviews the portal, a teammate gradually drifts away from how the business genuinely operates, so plan for a brief, regular review rather than assuming the setup keeps itself.
What does a teammate look like for each kind of business?
Every business moves through the same three stages, although the inbound work and the approval lines differ by trade. Our starting point is Northeast Indiana, including Fort Wayne, Auburn, Allen County, and DeKalb County, and the examples below are illustrative rather than case studies.
Lawn care business (illustrative). A customer texts, "Can you give me a quote for a spring cleanup?" The teammate organizes the inquiry, notes missing details such as the property address and photos of the yard, and drafts a reply requesting them. Nothing goes out without approval. The owner reviews the draft, adds the price, and determines whether to send it.
Contractor (illustrative). A contractor's teammate might sort incoming requests by job type and location, flag any request that needs a site visit, and draft a scheduling reply. Approval lines typically sit around estimates and any change to the scope of work, since those decisions affect margins and commitments.
Cleaning business (illustrative). Recurring schedules generate the majority of the busywork. A teammate can draft confirmation and reschedule messages for approval while flagging any client who has moved the same appointment three times, and anything involving billing remains behind your approval.
Small law office (illustrative). Intake emails frequently need the same organizing steps and the same missing-information follow-ups, and a teammate can organize each intake while drafting a holding reply for attorney approval. Read-only access is frequently the right starting level here, because the sensitivity of client matters calls for a slower rollout.
Across all four, the trade-off is that a more regulated or higher-stakes business typically begins with narrower access and takes longer to reach full access on any task. That outcome reflects the design working as intended rather than a shortcoming.
When is a teammate the wrong fit?
A teammate is the wrong fit when your approval rules cannot yet be written down, when a single fixed page already answers every question your customers request, or when the majority of the work depends on a person's judgment in the moment.
In each case, the honest move is to wait. If the rules are unclear, Stitch will surface that rapidly, so you will know where the lines belong before anything is configured. If one page answers everything, a website widget or a simple FAQ may serve you better, and if the work depends predominantly on in-the-moment judgment, a teammate can organize the paperwork around it without replacing the decision.
The trade-off operates in both directions, since passing on a teammate leaves manual work in place, while a teammate with unclear rules creates work you then have to undo. If you are unsure whether your business fits, the contact page is the place to start that conversation, and the answer may well be that you do not need one yet.
Frequently Asked Questions
How is Hey Button priced? Typically setup and ongoing support are quoted around your workflows and integrations. Any software subscription or usage charge is identified before you commit, so there are no surprise line items. Ask for that breakdown during your intake conversation, and get it in writing before you agree to anything.
Can a teammate handle phone calls? No — teammates work in text, email, and forms. They do not answer or make phone calls, so any work that needs a live voice conversation stays with you or your staff. Plan for that boundary during intake, not after go-live.
Does the teammate learn and improve on its own? No — tuning is directed by people. You and the Hey Button team review what the teammate handled, determine what should change, and update its setup through the approval rules. The teammate does not rewrite its own instructions or widen its own access between reviews.
Do I need technical staff to set one up? Typically not. Stitch is a conversation about how your work operates, and you do not need to write code or connect tools yourself. You do need someone who can make approval decisions for the business, and you should know which tools hold customer information before intake begins.
What happens if the teammate makes a mistake? Typically the approval rules catch it first. Anything customer-facing that you set to draft-and-approve waits for a person before it goes out, and the portal demonstrates what happened and why. When an error gets through, we review the rule behind it and tighten the setup.
Ready to see whether a teammate fits your business? Start the setup questionnaire at https://heybutton.ai/start, and we will map your workflows from there.
Frequently Asked Questions
- How is Hey Button priced?
- Typically setup and ongoing support are quoted around your workflows and integrations. Any software subscription or usage charge is identified before you commit, so there are no surprise line items. Ask for that breakdown during your intake conversation, and get it in writing before you agree to anything.
- Can a teammate handle phone calls?
- No — teammates work in text, email, and forms. They do not answer or make phone calls, so any work that needs a live voice conversation stays with you or your staff. Plan for that boundary during intake, not after go-live.
- Does the teammate learn and improve on its own?
- No — tuning is directed by people. You and the Hey Button team review what the teammate handled, determine what should change, and update its setup through the approval rules. The teammate does not rewrite its own instructions or widen its own access between reviews.
- Do I need technical staff to set one up?
- Typically not. Stitch is a conversation about how your work operates, and you do not need to write code or connect tools yourself. You do need someone who can make approval decisions for the business, and you should know which tools hold customer information before intake begins.
- What happens if the teammate makes a mistake?
- Typically the approval rules catch it first. Anything customer-facing that you set to draft-and-approve waits for a person before it goes out, and the portal demonstrates what happened and why. When an error gets through, we review the rule behind it and tighten the setup.
Hey Button
Want a teammate that handles this for you?
Answer a few questions about your business and Hey Button will show you what an AI teammate would take off your plate, with you approving anything that goes out.
