Partner programme — AiHummer Docs

Open the partner portal and select your organisation. Available actions depend on your current role and published policies. Rates, limits, eligibility and deadlines come from the current Billing records, rather than a separate price table here.

1. Become a partner

Submit legal details and required documents. Follow the independent application review and accept the applicable agreement. Invite named colleagues with only the roles they need; sensitive actions require fresh MFA.

2. Bring a customer

Share your original referral code. The customer owner reviews and confirms the source. Attribution grants neither customer access nor ownership; a referral or forecast is not a paid commission.

3. Protect a deal

Register the customer, product scope and original evidence. Read the reviewed protection decision and expiry. Resolve duplicate claims through the recorded dispute; never replace a protected source with a CRM edit.

4. Deploy on a customer’s account

Agree the project, resource and deployment scope. Obtain customer-approved access and the required paid entitlement. Follow the original installation until the customer’s Core confirms application; submitting a task does not complete deployment.

5. Request access

Specify purpose, permissions and duration. The customer owner reviews the exact grant and confirms it. Use your own identity; do not request passwords. Revocation or expiry ends delegated access without transferring ownership.

For technical reports obtain separate current customer approval and explicit delivery by the original instance owner. Health exchange is health-only. Confirm the exact report scope and duration, redact optional support material and treat execution totals separately from business outcomes. An exported copy cannot be recalled.

6. Understand an accrual

Inspect the original order, paid facts, fulfilment, returns and captured policy. Distinguish pending, available and withheld amounts. Request an asynchronous export and use its original completion notice and expiry; report discrepancies against the original record.

7. Receive a payout

Confirm legal, tax and payout documents. Submit the available amount for independent approval. Track the original outgoing operation and verified bank settlement. An unknown bank outcome requires reconciliation of that operation, not a new payment.

A reservation is not evidence of a bank transfer.

8. Transfer servicing

Have the customer approve the replacement scope and handover. Withdraw old access, transfer agreed tasks and retain history. Recover unfinished original commands before new actions; changing servicing does not rewrite past accruals.

9. Become certified

Use the published course revision and personal assessment. Check the certificate’s scope, expiry and verification. Missions need accepted evidence of your own contribution; credits are not money. Seasonal deadlines and voluntary public ranking follow the published rules.

10. Use the brand

Use approved materials and the published campaign limits. Obtain MDF approval before spending; reimbursement needs verified supplier documents and bank settlement. Review advertising responsibility and consent. An initial discount does not automatically discount renewals.

11. Publish a solution

Submit the original material, version, rights and deployment scope for independent review. Paid installation rights remain separate. A public customer case additionally needs that customer’s current explicit consent; project acceptance alone is insufficient.

12. MSP and OEM

Use the approved agreement, tenant boundaries and captured rights. A demo or NFR resource retains its original expiry; remote NFR access is rechecked within a lease of at most 30 seconds. It is not a portable paid licence. Export configuration through the actual instance owner’s local interface, excluding secrets and content.

Transfer a demo to a customer instance

The actual local owner of the source demo opens “Demo → customer”, selects a workspace and exports configuration. Register that original export, then download aihummer-sandbox-configuration.json. History, content, demo secrets and licences are excluded.
In the partner portal select that recorded export and the customer’s current paid project. Give a reason, review the original operation and explicitly confirm it. Download the separate aihummer-demo-handoff.json file.
The customer instance owner opens the local transfer, selects the destination workspace and both files: configuration up to 512 KiB and portal handoff up to 64 KiB. Check the displayed project title and previewed changes. No manual identifier is needed; files themselves grant no authorization.
Check customer authorization. Before applying, explicitly approve the displayed permissions and dangerous actions separately, if present. Apply the changes: imported resources are paused and agents do not start automatically.
Sign the retained import result, then send it. The portal shows Applied (applied) only after receiving the original confirmation.
The current source demo owner separately finalizes the transfer in the portal: give a reason, review and confirm deletion. cleanup means removal is pending; converted follows actual deletion of the old VM.

After an interruption recover the original operation and read its outcome. If needed send the same retained result; do not create a second export or import. A missing response or expiry is not evidence of cancellation.

Before authorization the proposal can be cancelled in the portal. After authorization the customer Core owner must explicitly retire the original unapplied import, sign and send its retirement confirmation. An applied import cannot be retired this way. Rollback removes only unchanged paused resources; it does not refund payments.

If the demo supplier is unavailable, an administrator checks its connection and the protected original installation credentials. Do not include those credentials in handoff files or messages. A budget reservation is not a supplier invoice.

13. Leave the programme

Stop new applications, revoke credentials and end delegated access. Cancel or recover original pending commands. Resolve retained obligations and keep required records; departure does not delete the customer’s purchased data or transfer ownership.

Customer controls

In the customer portal, review invitations, partner scope, servicing changes and public-case consent. Grant and revoke explicitly. Customer ownership remains yours; support participants see only their authorised conversation, never operator private notes.

Administrator workflow

Publish versioned rules with eligibility, limits and effective dates after simulation and independent review. Reconcile cash against original evidence. Campaigns, tiers, rewards, incidents and rollbacks keep history. Notification preferences, quiet hours and marketing consent apply; recorded events do not prove delivery.

Operational stops block new admissions separately from commercial policy; access withdrawal, original recovery, history and existing paid customer rights continue.

API and recovery

Use the deployed Billing contract for partner API calls; the Core API is a separate surface. Human module commands retain one original UUID: prepare, review, execute or cancel. Reuse its idempotency key and expected version. After interruption query that original outcome; missing or expired status is not proof of cancellation. Scope service accounts narrowly, protect first-only secrets, verify webhook signatures and deduplicate original event IDs. CRM sync changes only permitted fields; money and protection require Billing review.

Transfer installation ownership

In the customer cabinet, open Organizations and start a separate transfer using a confirmed installation relationship, destination organization and authority documents. Both parties confirm the original case from their own accounts with MFA; an operator independently reviews the documents. In Core, the original local owner selects an existing owner, the recipient confirms from its own account, and the source completes a private backup. Upload the signed evidence to the original case and complete the customer transfer. Licence, data and payment history remain; old automatic renewal stops. Unknown ownership opens a separate recovery request, never automatic transfer by tax ID. After a lost reply recover the same command; absence is not cancellation.

After the transfer, the current owner pays for a separate accepted order in their own customer account. Previous payments, invoices and the former payer’s automatic debit authorisation remain in the original history. This is a new purchase for an existing instance, not instance creation or a transfer of the old subscription. If a response is lost, check the original order; a missing record does not mean cancellation. Payment confirmation and acceptance of licence issuance are checked separately from the licence’s actual application on the server.

Contact and your private first-30-day plan

Follow up an enquiry

Provide the contact channel you requested and read the separate privacy and marketing terms. With a published rule, the contact chain is planned for days 0/3/7/14: enquiry response, reminder, useful material and closure. The working calendar, consent, quiet hours and limits may defer or prevent a contact. After discovery, the manager separately records the summary, constraints and next step; starter drafts alone enable nothing.

To record a reply or refusal, use the original receipt and private code in the response form. Keep the code out of links and do not share it with others. A reply, refusal or active conversation stops repeat contact; refusal is retained even before a chain starts. Withdrawing consent stops the relevant messages without removing your account, ownership or purchased rights. A telephone enquiry creates a private operator task for manual contact; automatic SMS or calls are not promised.

Onboarding tasks

Your private organisation plan shows your original tasks, deadlines, responsible manager and history. The published first-30-day plan includes:

Day 0: agreement and a team with the required roles.
Day 3: commercial training and a personal exam.
Day 6: technical practice after the required courses and independent assessment.
Day 11: a registered deal with current protection.
Day 16: customer-approved project scope linked to the original order.
Day 22: methodologist review of implementation.

Record three customer-scenario hypotheses, describe the customer profile and choose a priority. Completed tasks are checked against original records and skipped for reminders; a UI tick is not a result. A methodologist separately reviews the first two projects, current configuration and submitted test observations, recording acceptance or required corrections. Published rules set the assistance allowance; additional help requires a separate agreement. For a delay, the manager records the cause—no customer, unclear value, competence, economics or a product defect—with a plan and next review date.

If an action’s response is lost, check the same original operation; a missing result does not prove failed sending or cancellation. Do not retry automatically or create a new key. A mail provider accepting a message proves neither inbox delivery nor reading. An uncertain outcome needs explicit checking and a decision, rather than automatic repeat mail.

Request an initial or successor proposal

Choose the protected deal, current catalogue and exact customer/resource scope. An initial request needs no existing quote and waits for customer-owner approval. Finance staff offer a separately prepared native quote. This grants neither quote sharing nor acceptance or payment. A successor request retains the previously customer-shared base quote; prices change through the native quote workflow. Recover or explicitly cancel the original request after a lost reply.

Arrange a meeting

Request a meeting in the original support ticket with a UTC time, timezone and duration. The assigned manager confirms or reschedules it; a requested time is not a booking. Cancel using the original request. An external calendar invitation is a separate action.

Amend a legal name

An owner/admin may propose a legal display-name amendment for the same verified entity. Independent review needs original registry and identity evidence. Country, legal form and canonical identity stay fixed; a different entity needs onboarding. Prior agreements remain unchanged; bank verification tied to the old legal details does not automatically verify the amended name.

Restore financial operations

Every Billing process starts with new transfer admission closed. Staff review genuine backup, restoration, queue and bank-export evidence before an explicit reopening for later reservations. Old or uncertain transfers remain query-only using their original bank ID; a missing response never permits another send. Existing paid customer rights continue.

Refunds, points and rewards

Genuine original refunds reverse the original qualifying XP and credits using their captured rules. Undelivered rewards release original reservations; delivered benefits retain delivery history and separate lost eligibility. A demo stop remains pending until its native owner confirms it; an independently paid conversion continues. Physical returns and delivered manual benefits require actual owner resolution.

Historical records and corrections

Staff scan and separately verify bounded original census pages, counts, currency totals and document hashes before backfill. Unknown ownership remains an exception and mappings grant no rights. Reviewed unpaid attribution corrections append conserved held entries; they are not spendable earnings. Paid/reserved history and genuine contractual opening balances need their separate original owners.

Read analytics

Read each metric’s original sources, cohort, window and calculation. Keep currencies and operational counts separate from paid revenue and business outcomes. Missing source data is unavailable, never an invented zero; insufficient observations do not establish ROI. Technical reports need separate current customer approval. Use the published policy for financial interpretation.

Confirmed native expenses alone do not establish the complete cost of a campaign. Full cost coverage, including partner training and support, needs a separate independently approved original cost cut. Calculate ratios only within the same original currency and minor-unit exponent. A missing current source is explicitly unavailable; do not infer conversions from other activity. Customer and contact IDs are not disclosed. Incurred costs do not prove bank settlement.

Temporary local access without connectivity

When the capability is supported, the local owner gives a named engineer short access only to the selected workspace’s technical health under a signed published Billing policy. Renewal and immediate revocation happen locally. Central revocation remains pending synchronization until the instance imports a verified signed receipt; lost connectivity does not prove revocation was applied. A restart requires new local approval. This access grants no administrative rights, content access or paid license.

Bank invoices, gifts and a renewal card

In the customer cabinet, select your organisation and open the original quote. Review the whole basket, accept its terms and pay its bank invoice. A partial receipt does not complete the order. Even after the full amount arrives, wait for whole-order confirmation and separately check licence, resource or module delivery; server licence application has its own result.

A “Gift — no charge” line remains in the order but establishes neither commission nor a first paid purchase for accruals. Extra incoming money is accounted for separately and does not automatically pay another order. Money genuinely linked to your order can show the amount received, actually returned and still held; this promises no automatic refund.

After confirmation of an eligible service, the organisation owner selects “Connect a card for renewal”. Read the terms, choose a bank and separately accept renewal and the 1 RUB verification payment with its refund.
Continue to the bank. This 1 RUB verifies the card, rather than paying an order or service period. Its refund has a separate pending, unresolved or completed status.
After returning, explicitly check the same operation’s status. The return link alone confirms neither successful payment nor charge authorization.
Separately select “Confirm card and renewal”. If the outcome is unknown, read the original operation; do not start another connection or resend automatically.

A future renewal is a separate payment for its own period. The initial BANK order and its history remain; the card alone proves neither payment nor delivery of a new period.

Change servicing partner

The customer organisation owner first proposes a pending assignment to the receiving partner for the same resource. The receiving partner’s owner selects “Propose change”, the previous assignment, effective date and reason. Confirm all five handover checks: service scope, open work, received documentation, service continuity and previous access revocation. Review the receiving assignment’s original agreement title and full terms before explicitly confirming the proposal.

The customer owner reviews the previous and receiving partners, initiator, dates and consequences. “Next period date” shows the recorded date from the original service or “Unavailable”; an absent or elapsed date is never a forecast. Select “Approve change”, then separately “Complete change” on or after the effective date. Approval and passage of time do not complete the change. “Cancel change” cancels a proposed or approved change before completion.

Completion revokes the previous assignment and its technical permissions. New engineer access needs separate customer approval; instant remote revocation on an offline instance is not guaranteed. Paid licences, money and recorded attribution remain intact. Later financial effects follow the existing policy without a promised payment or commission. The customer’s independent right to revoke access remains available during commercial disputes.

After a lost response, select “Recover original result” and check the same operation. An absent or unknown result remains unresolved. Only after checking may “Retry the same original” explicitly resend the retained exact request. Do not start a replacement or resend automatically.