The short version
- A deployer is a person or an agency that sets companies up on afka inside their own workspace: connecting the client tools, setting autonomy and caps with the client, and handing over a working agent with the audit log open.
- The terms are published and they are the whole promise: 30 percent of the client subscription for twelve months from the first paid invoice, first-touch attribution for 90 days, and the implementation fee stays the deployer's own business.
- The method is published too: five playbooks, one per business function, each with the client profile, the team map, the five steps of the first session, the weekly rhythm, and the money section.
- afka publishes no income projections. The offer is the terms, the playbooks and the product, and a deployer can verify all three before committing to anything.
There is a gap in the market that has a shape everyone recognises and a name almost nobody uses. Companies want working AI agents: the support queue is growing, the pipeline is stale, the founder answers tickets in the evening. And the same companies do not have the person who will sit down, connect the tools, set the limits, and walk the first piece of work through to the end. The software exists. The hands do not.
That gap is a job. We call the person who does it a deployer: a person or an agency that sets companies up on afka inside their own workspace and gets paid for every month the client stays. This article is the whole offer, written down. Not a teaser for a call, not a partner portal behind a form. The terms, the method, and the reasoning, in public.
What a deployer actually does
A deployment is not an integration project. It is one or two working sessions with a rhythm the playbooks spell out step by step.
The first hour is questions. Which ten ticket types fill the inbox. Which deals went quiet. What the must-have criteria for the open role really are. The client has these answers; nobody has ever written them down. The deployer writes them down, because the list decides what the agent handles first and what stays with a person.
Then the tools are connected through managed connectors. afka never receives third-party passwords: the client authorises each tool and can revoke it by disconnecting. This is the step people expect to be hard, and it is the easiest one on the list.
Then the conversation that separates a deployment from an install: autonomy and caps, agreed out loud. The agent starts on Review, refunds wait for approval, the caps are numbers the client says with their own mouth, and the deployer shows that the caps are enforced in code rather than in a prompt. A cap that can be talked around is not a cap.
Then the moment the client understands the product: one real piece of work, end to end, while they watch. A real ticket resolved. A pipeline visibly cleaner. A ranked shortlist where every score carries its citation. Not a demo with sample data: their queue, their deal, their role.
The handover artifact is the audit log itself.
The handover is the last step, and it is done with the audit log open: who did what, when, at what cost, and which decisions waited for a person. The client leaves owning the autonomy dial. The deployer leaves with a client who saw the work happen rather than heard it described.
The terms, stated once
You earn 30 percent of the client subscription for twelve months from the first paid invoice, with first-touch attribution for 90 days. Your implementation fee is your own business and stays yours. afka publishes no income projections: the terms are the terms.
That paragraph appears word for word on every playbook page, and it is deliberately short. There is no tier ladder to climb, no quota to defend, no certification fee. Whether a deployment takes you an afternoon or a week, what you charge for your own time is between you and your client.
The five playbooks, published
The method is not gated, because the method is the offer. One playbook per business function, each with the client profile, the team map, the skill-pack interview, the five steps of the first session, the weekly rhythm, the money section, and the questions clients actually ask:
Deploy the support agent: from a crowded inbox to resolved tickets. Deploy the sales agent: pipeline work that runs without a person driving it. Deploy the recruiting agent: a screened shortlist instead of an applicant flood. Deploy the store agent: buyers answered and the back office handled. Deploy the content agent: LinkedIn run as GTM infrastructure.
Why the method is public
A gated document can promise anything. A public page has to be true, because anyone can hold it against the product it describes. Publishing the playbooks costs us the mystique of a partner program and buys something better: a deployer who has read exactly what the work is before committing, and a client who has read exactly what they are buying. Both arrive with the right expectations, which is the only foundation a twelve-month relationship can stand on.
There is a second reason, and it is not a secret. A future deployer searches for how to set up an AI support agent for a client, and the playbook is the answer they find. Recruiting deployers is a content task, and the offer itself is the content.
Who this fits, and who it does not
It fits agencies that already hold client trust: marketing agencies whose clients keep asking about AI, operations consultants, IT service firms whose retainer work is shrinking. It fits operators who set up one agent inside their own company and noticed they now have a skill their peers keep borrowing. The common thread is not a technical background. It is standing in front of a client, asking the first-hour questions, and being trusted with the answers.
It does not fit anyone shopping for passive income. The 30 percent is recurring; the work that earns it is not passive. A deployment is real work with a client watching, and the playbooks do not pretend otherwise anywhere.
The deployer page carries the agreement and your link. The playbooks carry the method. Between the two of them, that is the entire offer.
Frequently asked questions
Do I need to be a developer to deploy afka for clients?
No. A deployment is configuration and judgment, not code: connecting the client tools through managed connectors, setting autonomy and caps with the client, and walking the first real piece of work through end to end. The playbooks assume no programming.
What do I earn, exactly?
You earn 30 percent of the client subscription for twelve months from the first paid invoice, with first-touch attribution for 90 days. Your implementation fee is your own business and stays yours. afka publishes no income projections: the terms are the terms.
Why does afka publish the whole method instead of gating it?
Because the method is the offer. A deployer can read exactly what the work is before committing, a client can read exactly what they are buying, and a published page can be checked against the product it describes. A gated document can promise anything; a public page has to be true.
Put your agents to work
See what it looks like when an agent finishes the whole job, under your control, on the record.
Start now