Partnerprogram
Välj organisation i partnerportalen. Åtgärder beror på aktuell roll och publicerade regler. Satser, gränser, krav och tidsfrister kommer från aktuella Billing-poster, inte en separat pristabell här.
1. Bli partner
Skicka juridiska uppgifter och nödvändiga dokument. Följ den oberoende granskningen och acceptera gällande avtal. Bjud in namngivna kollegor med endast nödvändiga roller; känsliga åtgärder kräver aktuell MFA.
2. Ta in en kund
Dela din ursprungliga hänvisningskod. Kundens ägare granskar och bekräftar källan. Tillskrivning ger varken åtkomst eller ägande; hänvisning och prognos är inte betald provision.
3. Skydda en affär
Registrera kunden, produktomfånget och ursprungliga bevis. Läs skyddsbeslutet och slutdatumet. Lös dubbla anspråk genom den sparade tvisten; en CRM-ändring ersätter ingen skyddad källa.
4. Inför på kundens konto
Kom överens om projekt, resurs och införandeomfång. Få kundgodkänd åtkomst och nödvändig betald rättighet. Följ ursprunglig installation tills kundens Core bekräftar tillämpningen; att skicka en uppgift avslutar inte införandet.
5. Begär åtkomst
Ange syfte, behörigheter och varaktighet. Kundens ägare granskar och bekräftar den exakta tilldelningen. Använd egen identitet, begär inga lösenord. Återkallelse eller utgång avslutar delegerad åtkomst utan att överföra ägandet.
Tekniska rapporter kräver kundens separata aktuella godkännande och uttrycklig sändning av den ursprungliga instansägaren. Normalt tillståndsutbyte ger endast status. Bekräfta omfång och varaktighet, anonymisera valfritt supportmaterial och skilj körningsantal från affärsresultat. En exporterad kopia kan inte återkallas.
6. Förstå intjäningen
Granska ursprunglig order, betalningsfakta, uppfyllelse, återbetalningar och sparad policy. Skilj mellan väntande, tillgängliga och innehållna belopp. Begär asynkron export med ursprungligt meddelande och slutdatum; koppla avvikelser till ursprungsposten.
7. Ta emot utbetalning
Bekräfta juridiska, skatte- och betalningsdokument. Lämna tillgängligt belopp för oberoende godkännande. Följ ursprunglig utgående operation och verifierad bankavräkning. Reservation bevisar ingen banköverföring. Ett okänt bankresultat kräver avstämning av samma operation, ingen ny betalning.
8. Överlämna service
Kunden godkänner nytt omfång och överlämning. Återkalla gammal åtkomst, överför överenskomna uppgifter och bevara historiken. Återhämta oavslutade ursprungliga kommandon före nya åtgärder; servicebyte skriver inte om tidigare intjäning.
9. Bli certifierad
Använd publicerad kursrevision och personlig bedömning. Kontrollera certifikatets omfång, slutdatum och verifiering. Uppdrag kräver godtagna bevis för ditt eget bidrag; krediter är inte pengar. Säsong och frivillig offentlig topplista följer publicerade regler.
10. Använd varumärket
Använd godkänt material och kampanjgränser. Få MDF-godkännande innan utgifter; ersättning kräver verifierade leverantörsdokument och bankavräkning. Kontrollera reklamansvar och samtycke. Den första rabatten gäller inte automatiskt vid förnyelse.
11. Publicera en lösning
Skicka originalmaterial, version, rättigheter och installationsomfång till oberoende granskning. Betalda installationsrättigheter är separata. Ett offentligt kundfall kräver dessutom kundens aktuella uttryckliga samtycke; projektacceptans räcker inte.
12. MSP och OEM
Använd godkänt avtal, kundgränser och sparade rättigheter. Demo och NFR behåller ursprungligt slutdatum; fjärråtkomst för NFR omprövas med tillstånd i högst 30 sekunder. Det är ingen portabel betald licens. Exportera konfiguration genom den verkliga instansägarens lokala gränssnitt utan hemligheter eller innehåll.
Överför demon till kundens instans
- Den ursprungliga demons faktiska lokala ägare öppnar ”Demo → kund”, väljer en arbetsyta och exporterar konfigurationen. Registrera den ursprungliga exporten och hämta
aihummer-sandbox-configuration.json. Historik, innehåll, demohemligheter och licenser överförs inte. - Välj den registrerade exporten och kundens aktuella betalda projekt i partnerportalen. Ange skäl, granska den ursprungliga åtgärden och bekräfta den uttryckligen. Hämta den separata filen
aihummer-demo-handoff.json. - Kundinstansens ägare öppnar den lokala överföringen, väljer målarbetsytan och båda filerna: konfiguration upp till 512 KiB och portalfil upp till 64 KiB. Kontrollera projektnamnet och förhandsvisade ändringar. Ingen identifierare anges manuellt; filerna ger i sig inget tillstånd.
- Kontrollera kundens godkännande. Bekräfta uttryckligen de visade behörigheterna och eventuella farliga åtgärder separat innan du tillämpar ändringarna. Importerade resurser är pausade och agenter startar inte automatiskt.
- Signera det bevarade importresultatet och skicka det sedan. Portalen visar tillämpat tillstånd (
applied) först efter att den ursprungliga bekräftelsen har mottagits. - Den ursprungliga demons nuvarande ägare slutför överföringen separat i portalen: ange skäl, granska och bekräfta borttagningen.
cleanupbetyder att borttagning väntar;convertedvisas först när den gamla VM:n faktiskt har tagits bort.
Efter ett avbrott återställer du den ursprungliga åtgärden och läser resultatet. Skicka vid behov samma bevarade resultat; skapa inte en andra export eller import. Ett uteblivet svar eller en passerad tidsfrist bevisar inte annullering.
Innan tillstånd har beviljats kan förslaget annulleras i portalen. Därefter måste kundens Core-ägare uttryckligen återkalla den ursprungliga ännu inte tillämpade importen samt signera och skicka återkallelsebekräftelsen. En tillämpad import kan inte återkallas så. Återställning tar endast bort oförändrade pausade resurser; betalningar återbetalas inte.
Om demoleverantören är otillgänglig kontrollerar en administratör anslutningen och den skyddade konfigurationen av ursprungliga installationsuppgifter. Skicka inte dessa i överföringsfiler eller meddelanden. En budgetreservation är ingen leverantörsfaktura.
13. Lämna programmet
Stoppa nya ansökningar, återkalla autentiseringsuppgifter och delegerad åtkomst. Avbryt eller återhämta ursprungliga väntande kommandon. Lös bevarade förpliktelser och behåll nödvändiga poster; utträde raderar inte kundens köpta data eller överför ägandet.
Kundkontroll
Granska i kundportalen inbjudningar, partneromfång, servicebyte och samtycke för offentliga fall. Bevilja och återkalla uttryckligen. Ägandet förblir ditt; supportdeltagare ser endast tillåtna samtal, aldrig operatörens privata anteckningar.
Administratörens arbetsflöde
Publicera regelversioner med krav, gränser och datum efter simulering och oberoende granskning. Driftstopp blockerar nya åtgärder separat från affärspolicyn; återkallelser, historik och befintliga betalda rättigheter kvarstår. Stäm av pengar mot ursprungliga bevis. Kampanjer, nivåer, belöningar, incidenter och återställningar bevarar historik. Meddelandepreferenser, tysta timmar och marknadsföringssamtycke gäller; ett registrerat event bevisar ingen leverans.
API och återhämtning
Använd driftsatt Billing-kontrakt för partneranrop; Core API är separat. Ett mänskligt kommando behåller ett ursprungligt UUID: förbered, granska, kör eller avbryt. Återanvänd dess idempotensnyckel och förväntade version. Fråga efter avbrott om ursprungligt resultat; saknad eller utgången status bevisar ingen avbokning. Begränsa tjänstekonton, skydda engångshemligheter, verifiera webhook-signaturer och deduplicera ursprungliga event-ID. CRM ändrar endast tillåtna fält; pengar och skydd kräver Billing-granskning.
Överför installationens ägare
Öppna Organisationer i kundkontot och starta en separat överföring med bekräftad installationsrelation, mottagarorganisation och behörighetsdokument. Båda parter bekräftar det ursprungliga ärendet i sina konton med MFA; en operatör granskar dokumenten oberoende. I Core väljer den ursprungliga lokala ägaren en befintlig ägare, mottagaren bekräftar i sitt konto och källan slutför en privat säkerhetskopia. Ladda upp det signerade beviset till det ursprungliga ärendet och slutför överföringen. Licens, data och betalningshistorik bevaras; den gamla automatiska förnyelsen upphör. Okänd ägare kräver en separat återställningsbegäran, ingen automatisk överföring via skatte-ID. Efter förlorat svar återställ samma kommando; frånvaro är inte avbokning.
Efter överföringen betalar den nuvarande ägaren en separat accepterad beställning i sitt eget kundkonto. Tidigare betalningar, fakturor och den tidigare betalarens medgivande för automatiska debiteringar finns kvar i den ursprungliga historiken. Detta är ett nytt köp för en befintlig instans, inte skapandet av en instans eller en överföring av den gamla prenumerationen. Om svaret går förlorat, kontrollera den ursprungliga beställningen; en saknad post innebär inte en annullering. Betalningsbekräftelsen och acceptansen av licensutfärdandet kontrolleras separat från licensens faktiska tillämpning på servern.
Kontakt och din privata plan för de första 30 dagarna
Följ upp en förfrågan
Ange den kontaktkanal du har begärt och läs de separata villkoren för integritet och marknadsföring. Med en publicerad regel planeras kontakterna till dag 0/3/7/14: svar, påminnelse, användbart material och avslut. Arbetskalender, samtycke, tysta tider och gränser kan skjuta upp eller förhindra kontakt. Efter det inledande mötet registrerar den ansvariga sammanfattning, begränsningar och nästa steg separat; startutkast aktiverar inget på egen hand.
För att registrera ett svar eller avböjande använder du det ursprungliga kvittot och den privata koden i svarsformuläret. Lägg inte koden i en länk och dela den inte med andra. Ett svar, avböjande eller pågående samtal stoppar upprepade kontakter; avböjandet sparas även innan serien börjar. Återkallat samtycke stoppar berörda meddelanden utan att ta bort konto, ägande eller köpta rättigheter. En telefonförfrågan skapar en privat uppgift för operatören att kontakta manuellt; automatiska SMS eller samtal utlovas inte.
Introduktionsuppgifter
Din privata organisationsplan visar ursprungliga uppgifter, tidsfrister, ansvarig och historik. Den publicerade planen för de första 30 dagarna innehåller:
- Dag 0: avtal och team med de roller som behövs.
- Dag 3: kommersiell utbildning och personligt prov.
- Dag 6: teknisk praktik efter obligatoriska kurser och oberoende bedömning.
- Dag 11: en registrerad affär med gällande skydd.
- Dag 16: kundgodkänd projektomfattning kopplad till den ursprungliga ordern.
- Dag 22: metodologens granskning av genomförandet.
Skriv tre hypoteser om kundscenarier, beskriv kundprofilen och välj en prioritet. Slutförda uppgifter kontrolleras mot ursprungliga poster och hoppas över i påminnelser; en bock i gränssnittet är inget resultat. Metodologen granskar de två första projekten, aktuell konfiguration och inskickade testobservationer separat och registrerar godkännande eller korrigeringar. Publicerade regler anger hjälpens omfattning; extra hjälp avtalas separat. Vid försening registrerar den ansvariga orsaken—ingen kund, oklart värde, kompetens, ekonomi eller produktfel—plan och datum för nästa genomgång.
Om svaret på en åtgärd försvinner, kontrollera samma ursprungliga operation; ett saknat resultat bevisar inte misslyckat utskick eller avbokning. Försök inte automatiskt igen och skapa ingen ny nyckel. Att e-postleverantören accepterar ett meddelande bevisar varken leverans till inkorgen eller läsning. Ett osäkert utfall kräver uttrycklig kontroll och beslut, inte automatiskt upprepat utskick.
Begär första eller följande offert
Välj skyddad affär, aktuell katalog och exakt kund-/resursomfattning. Första begäran behöver inget befintligt quote och väntar på kundägarens godkännande. Ekonomipersonal erbjuder ett separat förberett ursprungligt quote; delning, acceptans och betalning är separata. Följande begäran behåller kundens tidigare delade grundquote. Efter förlorat svar återställ eller avbryt uttryckligen ursprungsbegäran.
Boka ett möte
Ange UTC-tid, tidszon och längd i ursprungligt supportärende. Tilldelad ansvarig bekräftar eller flyttar; önskad tid är ingen bokning. Avbryt ursprungsbegäran. En extern kalenderinbjudan är en separat åtgärd.
Ändra juridiskt namn
Ägare/admin kan föreslå samma verifierade enhets juridiska namn. Oberoende granskning kräver ursprungliga register- och identitetsbevis. Land, juridisk form och kanonisk identitet står fast; annan enhet kräver anslutning. Tidigare avtal och bankverifiering uppdateras inte automatiskt.
Återställ ekonomiska åtgärder
Varje Billing-process börjar med nya överföringar stängda. Personal granskar äkta backup, återställning, kö och bankutdrag innan senare reservationer öppnas. Gamla/osäkra överföringar får bara kontrolleras med ursprungligt bank-ID; saknat svar tillåter ingen ny sändning. Kundens betalda rättigheter består.
Återbetalningar, poäng och belöningar
Äkta ursprunglig återbetalning återför tillhörande XP/krediter enligt ursprungsreglerna. Ej levererade belöningar frigör reservationer; levererade behåller historik och separat förlorad behörighet. Demostopp väntar på ursprungsägaren; oberoende betald konvertering består. Fysiska returer och manuellt levererade förmåner kräver verklig ansvarig hantering.
Historik och rättelser
Före backfill granskar personal separat avgränsade ursprungliga inventeringssidor, antal, valutasummor och dokumenthashar. Okänt ägande förblir undantag; koppling ger inga rättigheter. Granskade obetalda tillskrivningsrättelser lägger till balanserade innehållna poster, inga tillgängliga intäkter. Betald/reserverad historik och avtalsenliga ingående saldon har egna ursprungsägare.
Läs analyser
Kontrollera ursprungskällor, kohort, tidsfönster och formel. Skilj valutor, antal åtgärder, betalda intäkter och affärsresultat. Saknad källa är otillgänglig, aldrig noll; få observationer bevisar inte ROI. Tekniska rapporter kräver kundens separata aktuella godkännande. Ekonomisk tolkning följer publicerad policy.
Bekräftade utgifter från de ursprungliga systemen visar inte i sig kampanjens fullständiga kostnader. Ett fullständigt kostnadsunderlag, inklusive utbildning och stöd till partner, kräver ett separat ursprungligt kostnadsutdrag med oberoende godkännande. Beräkna kvoter endast inom samma ursprungliga valuta och med samma exponent för den minsta valutaenheten. En saknad aktuell källa visas uttryckligen som otillgänglig; konverteringar härleds inte från annan aktivitet. Kund- och kontaktidentifierare lämnas inte ut. Uppkomna kostnader bekräftar inte en bankbetalning.
Tillfällig lokal åtkomst utan anslutning
När funktionen stöds ger den lokala ägaren en namngiven ingenjör kort åtkomst endast till den valda arbetsytans tekniska status enligt en publicerad och signerad Billing-policy. Förnyelse och omedelbar återkallelse sker lokalt. Central återkallelse väntar på synkronisering tills instansen importerar en verifierad signerad bekräftelse; förlorad anslutning bevisar inte att återkallelsen har tillämpats. En omstart kräver ett nytt lokalt godkännande. Åtkomsten ger inga administratörsrättigheter, ingen åtkomst till innehåll och ingen betald licens.
Bankfaktura, gåvor och kort för förnyelse
Välj din organisation i kundportalen och öppna den ursprungliga offerten. Kontrollera hela varukorgen, godkänn villkoren och betala bankfakturan. En delbetalning slutför inte ordern. Vänta efter att hela beloppet kommit in på bekräftelse av hela ordern och kontrollera leverans av licens, resurs eller modul separat; tillämpning av licensen på servern har ett eget resultat.
En rad ”Gåva — kostnadsfri” finns kvar i ordern men skapar varken provision eller ett första betalt köp för intjäning. Extra inbetalningar redovisas separat och betalar inte automatiskt en annan order. Vid en verifierad koppling till din order kan du se mottaget, faktiskt återbetalat och kvarvarande belopp; automatisk återbetalning utlovas inte.
- När en lämplig tjänst har bekräftats väljer organisationens ägare att ansluta ett kort för förnyelse. Läs villkoren, välj bank och godkänn förnyelsen och kontrollbetalningen på 1 RUB med återbetalning var för sig.
- Fortsätt till banken. Denna 1 RUB kontrollerar kortet och betalar inte ordern eller en tjänsteperiod. Återbetalningen har en egen status: väntande, under utredning eller klar.
- Kontrollera uttryckligen samma åtgärds status efter återkomsten. Returlänken bekräftar varken betalning eller debiteringsmedgivande.
- Bekräfta kortet och förnyelsen separat. Om resultatet är okänt, läs den ursprungliga åtgärden; starta inte en ny anslutning och skicka inte automatiskt igen.
En framtida förnyelse är en separat betalning för sin egen period. Den första bankordern och dess historik finns kvar; kortet ensamt bevisar varken betalning eller leverans av en ny period.
Byt servicepartner
Kundorganisationens ägare föreslår först en väntande tilldelning till den nya partnern för samma resurs. Den nya partnerns ägare väljer ”Föreslå ett byte”, tidigare tilldelning, ikraftträdandedatum och skäl. Bekräfta alla fem kontroller: serviceomfattning, öppna arbeten, mottagen dokumentation, servicekontinuitet och återkallelse av tidigare åtkomst. Läs titeln och alla villkor i den nya tilldelningens ursprungliga avtal innan du uttryckligen bekräftar förslaget.
Kundens ägare granskar partnerna, initiativtagaren, datumen och följderna. ”Datum för nästa period” visar det bevarade datumet från ursprungstjänsten eller ”Inte tillgängligt”; ett saknat eller passerat datum blir ingen prognos. Välj ”Godkänn bytet”, sedan separat ”Slutför bytet” på ikraftträdandedagen eller senare. Godkännande och tidens gång slutför inte bytet. ”Avbryt bytet” avbryter ett föreslaget eller godkänt byte innan det slutförs.
Slutförandet återkallar den tidigare tilldelningen och dess tekniska behörigheter. Ingenjörens nya åtkomst kräver separat kundgodkännande; omedelbar återkallelse på distans på en offline-instans garanteras inte. Betalda licenser, pengar och registrerad fördelning bevaras. Senare ekonomiska följder följer befintlig policy utan löfte om betalning eller provision. Kunden behåller sin självständiga rätt att återkalla åtkomst även vid en affärstvist.
Efter ett förlorat svar väljer du ”Hämta ursprungligt resultat” för samma åtgärd. Ett saknat eller okänt resultat förblir olöst. Först efter kontroll får ”Försök med samma begäran igen” uttryckligen skicka den bevarade exakta begäran igen. Skapa ingen ersättningsåtgärd och skicka inte automatiskt igen.