Where its goals come from changes who is accountable.
A worker can extend the capacity of named sellers, holding their targets restricted to the accounts it covers. Or it can hold a remit of its own from the business, behaving as an internal service provider whose output a seller consumes. Most real deployments are both, which means the interesting question is not whose goals it has but what happens when they disagree.
The distinction is not cosmetic, and it is usually visible in who signs for the deployment.
| Question | Delegated | Chartered |
|---|---|---|
| Whose targets is it working to? | The reps it is paired with | The business function that chartered it |
| Who may redirect it? | Its reps, within their accounts | The remit owner. A rep may request, not redirect |
| Who is accountable for the outcome? | The rep, whose authority it exercises | The remit owner, with the rep accountable for anything committed on their accounts |
| What is a rep's relationship to it? | Their worker | A service they consume, with a service level and a feedback path |
The worker extends the capacity of named people and holds no targets of its own. Its goals are their goals, restricted to the accounts it covers. The natural shape when a worker is bought to make three sellers more effective.
A remit from the business rather than from any individual. Two hundred qualified opportunities a quarter in the mid-market. Every installed base account touched quarterly. The top hundred targets mapped to the economic buyer. A capability the business owns rather than a tool an individual operates.
In either model the worker opens, navigates, qualifies and hands over to a sales representative, human or virtual, whose job is to close.
| Role | Responsible for | The worker's relationship to them |
|---|---|---|
| Sales representative | The commercial outcome. Owns the account | The principal in a delegated model, the consumer in a chartered one. Qualified work hands over to them either way |
| Remit owner | The worker's charter and its standing targets | Present only in a chartered model. Sets and reviews the remit, and owns the outcome against it |
| Inside sales worker | Opening, navigating, qualifying, coverage, intelligence | The worker itself. There may be more than one on a large account |
| Pre-sales or solution engineer | Technical credibility and fit | May be scheduled inside their declared availability. Never spoken for technically |
| Marketing owner | Campaigns, content and the event calendar | Supplies campaign lists, receives outcomes back, and is where asset requests go |
| Customer success | An existing customer's health and renewal | On a customer account, frequently the principal instead of the sales rep |
| Support owner | Open issues | A support event is a sales event, and this is the link that makes that visible |
| Legal and contracts | Terms and the signature process | Outside the worker's authority entirely. It observes, and it escalates |
| Partner contact | A co-selling or reselling relationship | Frequently at another organisation, which is why the team lives in the relationship graph |
A worker receives an assignment: a scope, the people it serves within it, and the charters it holds.
| Kind | Set by | Example | Scoped? |
|---|---|---|---|
| Chartered | The remit owner | Two hundred qualified opportunities a quarter in the mid-market | No. The charter is its own scope |
| Delegated | A rep's own targets | Their quota, coverage ratio and meeting count | Yes, to the accounts the worker holds |
| Account | Either, per account | Reach the economic buyer. Protect this renewal | Inherently one account |
| Standing | The worker definition | Gather budget authority and competitive position wherever the conversation allows | Opportunistic, everywhere |
Delegated goals are computed, not copied. A charter is not narrowed at all, because the charter is the scope.
Copying a delegated target would be simpler and would be wrong within a fortnight, because a quota changes, an account is reassigned, a territory is redrawn, and a copied goal quietly carries on working towards a number nobody is carrying any more. Computing it means a territory redraw moves accounts and the numbers follow, with nobody reconfiguring anything.
Not an average. Work on one rep's accounts counts towards that rep.
With nobody reconfiguring anything. A territory redraw moves accounts, and the coverage targets recompute at the next cycle.
Against each charter, against each person's contribution, and against the fleet's own coverage and quality. A single number answers none of those.
A worker holding a charter and two delegations will receive incompatible demands. An implicit resolution rule is one nobody can predict, so it is explicit, and it separates two kinds of conflict that need different answers.
The pairing between a worker and a representative is a versioned configuration object, not a paragraph of prompt text somebody edits. It is the most frequently adjusted thing in a live deployment.
| Clause | What it declares |
|---|---|
| Commit without asking | What the worker may agree outright: a meeting inside your declared calendar windows, a callback, an approved asset |
| Commit with approval | What needs your confirmation first, and how long it waits before falling back to a safe alternative |
| Authority grade per class | For each privileged activity, one of five grades: not granted, propose only, act with approval, act within limits, or act freely. Everything privileged starts at not granted |
| Limits | Where an activity involves a value, the band or ceiling inside which the worker acts unaided, and what happens outside it |
| Exclusions | Named individuals or topics this pairing keeps away from. A tactical instruction rather than a capability limit |
| Handover and acceptance | What counts as qualified, what must be in the record, how long you have, and what happens on a timeout |
| Hand back | You can return an account with an instruction, which is how a long nurture actually starts |
| Escalate to me on | The named conditions that interrupt you rather than waiting for a digest |
| Availability | The windows it may offer, refreshed from your calendar rather than typed in once |
There is a version of this product that lists things a virtual worker may never do. It reads as responsible and it is wrong.
A hard coded prohibition is a bet that nobody will ever have a legitimate reason, and that bet loses. A worker negotiating a data sharing memorandum has to discuss terms. A renewal worker may legitimately apply a discount inside a band your pricing system already approves. A worker doing new hire screening or onboarding has to see compensation, leave balances and beneficiaries, because that is the job.
The platform does not withhold capability. It withholds authority, and authority is configuration.
| Grade | Meaning |
|---|---|
| Not granted | Unavailable to this worker. Where every privileged activity starts on a newly commissioned one |
| Propose | The worker prepares and recommends. A human acts, and nothing reaches the counterparty |
| Act with approval | The worker acts once a named approver confirms |
| Act within limits | Unaided inside a declared band, ceiling or mandate. Outside it, back to approval |
| Act freely | No per instance gate within the class |
Privileged activities, all off until granted: pricing and quotation, discounting and commercial concession, contractual terms including memoranda and service levels, delivery commitments, forward looking product statements, transaction execution, refunds and credits, access to sensitive personal data, and contact with a named individual outside the ordinary scope. Every grant carries a grantor with the standing to give it, a scope, a ceiling, an expiry, a reason and a review interval. And a grantor cannot confer authority they do not themselves hold: a seller who cannot approve a fifteen percent discount cannot give that to a worker, and the request routes to whoever can.
A data sharing memorandum, a service level agreement and its remedies, a renewal price, a partner arrangement. This is the case the authority model exists for.
| Element | What it declares |
|---|---|
| Scope | Which instrument, which counterparty, which clauses are in play |
| Opening position | Where the worker starts. Sourced rather than chosen |
| Concession ladder | What may be conceded and in what order, because conceding in the wrong order gives away value that did not need to move |
| Reservation point | The floor. Reaching it is an escalation rather than a failure |
| Trades | What may be sought for each concession, so a concession is a trade and not a gift |
| Authority to close | Whether the worker may agree the final position, propose it, or only report it |
| Expiry | Mandates do not stand indefinitely |
You can narrow a worker's authority at any moment and it takes effect on the next call rather than the next release. Nothing about delegation requires an administrator or a deployment.
Delegated authority is still your authority. The platform's job is to make the delegation explicit, inspectable and reversible, not to relocate the accountability into a system. Anyone who tells you a machine can carry the accountability is selling you something.
An instruction is typed, scoped, attributed, time bounded and visible. Prioritise this account. Stop while a complaint is open. Lead with the security angle. Find out who signed the last renewal. Interrupt me if they mention the incumbent. Move this to me. Give it back to nurture for two quarters.
Directs what happens on their accounts: priority, approach, exclusions, escalation, handover and hand back. They cannot change how the fleet is paced and they cannot approve a prompt revision.
Human or virtual. Directs how the fleet works: assignment, capacity, pacing, list allocation, coaching and the approval of revisions. They cannot authorise a commitment on a representative's account, because it is not their account.
Renewals of subscriptions and maintenance agreements are the common case: the terms exist, the relationship exists, and the conversation is a confirmation rather than a negotiation.
A worker never authors a commitment; it sources one. Where it holds no pricing authority a request for different terms escalates. Where it does, the same request is a call to whoever owns the answer.
Where the worker holds no pricing authority, a different price, term, quantity or entity is a variation and it escalates immediately. Where it does hold authority, the same request routes to the system that owns the answer. It never invents a figure either way.
It is warranted evidence of what a person said. It is never evidence that a contract exists. Only your order system can say an order was placed, and only your signing system or contract record can say a contract was signed.
| Event we react to | What the worker does |
|---|---|
| Signature packet sent | Notifies, and starts the chase cadence |
| Viewed, not signed | Waits the configured interval, then one gentle follow up |
| Signed by one party | Records progress. Does not treat as complete |
| Declined | Stops immediately and escalates. A decline is a human conversation |
| Expired or voided | Escalates, and does not silently reissue |
| Completed | Records the outcome, updates the account, thanks the customer, closes the flow |
| Amended | Treated as a variation, so it escalates |
| Offline signature recorded | Identical to completed. Wet ink and a company stamp are the normal path in several of our markets, so the flow responds to the event and treats how the signature was obtained as a property of it |
Events divide by where they come from, which turns out to be more useful than what they are about.
Arrived from outside, and we did not decide they happened. A stage change in the CRM, a renewal date approaching, a signature completed, a support ticket escalated, a payment failure.
Computed from what we see and what we know. A champion has gone quiet, coverage will fall short, three stakeholders mentioned the same competitor, a renewal is at risk.
Produced for your systems to consume. Meeting booked, qualification threshold reached, escalation raised, intelligence captured, suppression requested.
| Source | What arrives |
|---|---|
| Customer relationship management | Stage, owner, close date, amount, opportunities created, won or lost, contacts added or removed, and activity logged by a human, which is how the worker knows to stay out of the way |
| Subscription, billing and orders | Renewal approaching, auto-renew changed, term or seats changed, usage thresholds, payment failed, invoice overdue, entitlement lapsed, cancellation requested |
| Support and service | Ticket raised, severity escalated, satisfaction low, service level breached, ticket resolved |
| Signature and contract | Sent, viewed, signed, declined, expired, voided, completed, amended, and the manually recorded offline signature |
| Marketing and events | Campaign launched, event date changed, registration, cancellation, attendance, no-show, asset downloaded, form completed |
| Product and usage | Trial started or expiring, feature adoption, a lapse in logins on an account that was active |
The subscription row is the richest untapped source in most businesses, because an expiring term and a failed payment are commercial events that almost never reach the person who could act on them. The support row is the second, because a support event is a sales event and most organisations cannot see that at all, the two systems never having been joined.
An administrator will run a bulk update and forty thousand accounts will change owner. A subscription system will be migrated and every renewal date rewritten. A marketing platform will replay a week of webhooks after an outage. Each of these is normal, and each will happen.
An event never causes a call. An event can only create or reprioritise a piece of work. The worst an event storm can do is fill a queue, and a full queue is visible, throttled and reversible.
Outbound contact happens exclusively through the dispatcher, which applies the caps, the spacing, the compliance check and the suppression state before anything is sent. In a naively reactive system, each of those routine operational events produces an outbound catastrophe. Here the architecture makes it impossible rather than the policy making it unlikely.
Forty edits to one opportunity in five minutes are one event as far as the worker is concerned.
A connector exceeding its expected rate by a wide margin is paused rather than believed. The right answer to a suspicious flood is a person looking at it, not dropping it and not acting on it.
A change touching a large share of your records is reported as one thing that happened, rather than deriving thousands of individual consequences from it.
The fastest way to see whether this fits is to describe how you actually work with an inside sales team today: what they may commit, what they must check, and what you want to know about immediately.