A performance platform can record a review, a goal, a manager decision, or a piece of feedback. It should not silently turn any of those records into a gift order. The reliable operating model separates the confidential evidence used to make a recognition decision from the limited instruction needed to offer a voluntary gift. That separation protects the employee, gives finance a clean approval trail, and makes fulfillment failures reversible.
Start with the decision boundary, not the product list
Culture and performance systems solve different problems from gifting operations. A review system helps an organization collect feedback, run cycles, assign permissions, and report on performance processes. A gifting system helps an approved program present choices, collect delivery information, route an order, and reconcile outcomes. Joining them can remove manual work, but only if the handoff contains less information than the source.
Define the boundary in one sentence: “An authorized owner may convert an approved recognition outcome into a gift invitation, but no review narrative, rating, calibration note, health detail, protected characteristic, or disciplinary information may cross into the gifting workflow.” That sentence should appear in the operating procedure, the data map, and the acceptance test.
The source record can remain detailed. The downstream record should normally contain only a unique event identifier, employee identifier or approved delivery alias, program code, eligibility band, budget ceiling, market, expiration date, consent state, and owner. If the gift message needs context, use a separately approved, neutral reason such as “project milestone” or “annual contribution.” Do not copy a manager’s explanation.
This boundary also clarifies ownership. People Operations decides eligibility and fairness. The employee’s manager may propose recognition but should not expose review content. Finance approves the budget and accounting treatment. Privacy or legal owners review the transfer design when required. The fulfillment owner accepts only the minimum approved record. The employee decides whether to participate and where a physical item may be delivered.
The strongest design is therefore not the integration with the most fields. It is the integration that can prove why each field exists, who can see it, how long it is retained, and how it is removed after the program ends. The NIST Privacy Framework is useful here as a voluntary risk-management reference because it treats privacy as an enterprise risk and encourages organizations to communicate processing purposes and choices.
Compare the platforms on the same evidence
The useful comparison is not a universal ranking. Culture Amp, Lattice, and 15Five all support performance processes, but their documented controls and export paths differ. Giftpack belongs in a separate column: it is a downstream gifting and fulfillment layer, not a performance review suite. Product availability and plan packaging can change, so buyers should validate their exact subscription and configuration before procurement.
| Platform or layer | Primary role in this workflow | Documented handoff evidence | Control to verify | Main tradeoff |
|---|---|---|---|---|
| Culture Amp | Performance cycles, feedback, goals, and development context | Official guidance documents CSV or XLSX performance exports and individual PDF review exports | Full versus demographically limited Performance permissions; submitted versus draft data | Rich review exports can contain far more information than a gift decision needs |
| Lattice | Reviews, goals, feedback, analytics, and configurable workflows | Official product material documents reporting and review export capabilities | Personalized or targeted permissions and cycle-level packet sharing or export settings | Flexible access requires careful role design and cycle-specific testing |
| 15Five | Review cycles, check-ins, objectives, feedback, and manager workflows | Official help content documents role-based PDF and CSV exports across feature areas | Account, HR, review, manager, viewer, and hierarchy-scoped access | Different report types follow different role and visibility rules |
| Giftpack | Approved recipient choice, budget controls, routing, fulfillment, and delivery evidence | Program configuration can use approved choice sets, recipient limits, country rules, restrictions, and fallbacks | Only an approved minimal recognition event should enter the gifting layer | It does not make performance, legal, tax, privacy, or employment decisions |
The table should drive a live proof exercise. Ask each platform owner to show one test employee, one completed cycle, one export, the role that produced it, and the audit evidence for that access. Then ask the gifting owner to demonstrate that the same employee can receive an invitation without the downstream system receiving the review text or rating.
Do not infer an API or native integration from an export button. Culture Amp’s official export guidance describes permission-scoped files. Lattice documents configurable workflows, analytics, and permissions, including a September 2026 control to disable review packet sharing and export at the cycle level. 15Five documents role-based reporting and exports, with managers generally limited to their hierarchy. Those facts establish possible handoff mechanisms, not an automatic, prebuilt gift trigger.
Convert a recognition outcome into a minimal event
Create a recognition-event schema before anyone builds an automation. The schema is a contract between the performance owner and the gifting owner. It should not mirror the source platform. A practical version has twelve fields: event ID, person ID or alias, program ID, reason code, eligibility band, maximum value, currency, market, invitation language, decision timestamp, expiration date, and approval reference.
The reason code must be deliberately coarse. “Annual contribution,” “project milestone,” “service anniversary,” or “peer recognition threshold” can explain a gift without revealing a score or narrative. Avoid labels such as “top ten percent,” “promotion likely,” “performance improvement completed,” or “manager concern resolved.” Even if such labels are technically available, they can expose employment judgments to people and vendors who do not need them.
Use an event ID that is unique and stable. If an export is processed twice, the fulfillment layer should find the existing event instead of creating a second invitation. Store the source system, cycle ID, and approval reference in a restricted reconciliation ledger rather than in the public gift message. The recipient-facing record should contain no hidden notes copied from the review.
Add three explicit states: proposed, approved, and released. A proposed event cannot create an invitation. An approved event has a valid owner and budget but still may wait for the employee’s consent or a scheduled date. A released event may create one invitation. If the event is withdrawn before redemption, the system should cancel the invitation without altering the underlying performance record.
A useful mapping workshop starts with the maximum available export and removes fields one by one. For every remaining field, record the purpose, lawful or organizational basis, owner, retention period, and deletion method. The outcome is not a broad data integration. It is a narrow instruction that can be reviewed without opening the employee’s review packet.
For teams designing that downstream ledger, Giftpack’s recipient-data operations hub offers a practical companion for separating campaign eligibility from delivery details. Its recommendations still need to be adapted to the employer’s policies and local requirements.
Put consent, approval, and delivery data in the right order
The order of operations matters. First, People Operations confirms that the recognition rule is valid and consistently applied. Second, a budget owner approves the value band and population. Third, the workflow creates a gift invitation without a residential address. Fourth, the employee chooses whether to participate and supplies delivery information through the approved channel. Fifth, the fulfillment system routes the order and records only the evidence needed for delivery and reconciliation.
Do not ask a manager to collect home addresses in a spreadsheet. Do not append addresses to the performance export. Do not reveal the employee list to a broad event or procurement team before approval. A manager needs to know that a proposal was accepted or rejected; a fulfillment operator needs to know that a released event exists; neither needs the other system’s full record.
Write the approval rule so it survives staff changes. For example: People Operations owns eligibility, the department leader confirms business context, Finance approves the budget batch, Privacy reviews any new field or destination, and the program operator releases invitations. One person may hold two roles in a small company, but the log should still record which role made each decision.
Recipient choice should be meaningful rather than cosmetic. The employee should be able to accept, decline, select an available option, and provide or correct delivery information. If a market cannot support the preferred item, the program should use an approved substitute, digital alternative, or no-gift outcome rather than improvising. Giftpack’s official help material describes approved choice sets, per-recipient limits, product restrictions, country rules, and fallbacks; the buyer should verify the exact program configuration in its contract and pilot.
The approval packet should include the population count, total authorized ceiling, reason-code distribution, excluded markets, expiration policy, and exception owner. It should not include review comments. Finance can reconcile invitations, redemptions, cancellations, and delivered value against the approved batch without seeing why one manager wrote a particular rating.
Hypothetical case 1: annual recognition after a review cycle
Scenario. A 2,400-person software company wants to offer a voluntary gift after its annual review cycle. The company uses one of the three performance platforms and has employees in the United States, Canada, Taiwan, Japan, and South Korea. This is a hypothetical operating case, not a customer result.
Decision. The People Operations team rejects a direct trigger based on numeric ratings. It creates an approved recognition cohort only after calibration is closed and employment decisions are complete. The gift reason is “annual contribution,” with three budget bands set by a separate compensation and recognition policy. The gifting system receives the band, not the rating.
Alternatives and tradeoffs. A single universal gift would simplify approvals but create availability and cultural-fit problems. Cash or payroll treatment would create a different tax and employment workflow. A manager-selected item would reduce recipient choice and could produce inconsistent outcomes. The team selects a voluntary curated choice program with market-specific fallbacks, accepting that catalog governance requires more preparation.
Execution and owners. The performance administrator exports the closed-cycle participant list within an approved scope. A People Operations analyst maps eligible employees to event IDs and deletes review questions, comments, ratings, calibration fields, and manager narratives from the working file. Finance approves the event count and maximum liability. The privacy owner reviews the twelve-field schema. The gifting operator imports only approved events and sends invitations. Employees who accept provide delivery information directly.
Failure and recovery. During the pilot, the analyst discovers that a demographic column remained in the export. The import is stopped before release. The working file is quarantined, the extra column is removed, the mapping rule is updated, and a second reviewer signs the corrected field list. No invitations are created from the defective file. The source review cycle remains unchanged.
Acceptance evidence. The team requires: one approved cohort manifest, zero review narratives in the downstream record, one invitation per event ID, documented consent or decline, reconciled budget totals, successful delivery or named exception for every accepted order, deletion of the working export after the retention window, and a sample access review showing that fulfillment users cannot open performance records.
This design does not claim that every gift is tax-free or legally required. Payroll, tax, works-council, privacy, and employment owners must decide the treatment for each market. The gifting workflow should preserve their decision, not make it.
Hypothetical case 2: a project milestone without performance leakage
Scenario. A global product team completes a difficult launch. The vice president wants managers to nominate contributors for a thank-you gift while the formal review cycle is still open. Some contributors are employees, some are contractors, and several worked across reporting lines. This is also hypothetical.
Decision. The company does not use draft review comments as the trigger. It creates a separate milestone nomination form with three neutral fields: project ID, contribution category, and manager attestation. People Operations checks eligibility against worker type and local policy. The approved gift message thanks the recipient for the project milestone and never references a rating, promotion, or compensation decision.
Alternatives and tradeoffs. Waiting for the annual cycle would reduce process duplication but weaken timeliness. Letting each manager send a gift directly would be fast but produce inconsistent budgets, duplicate recipients, and poor delivery evidence. Importing continuous feedback tags would be easy technically but could disclose sensitive praise or criticism. The separate form adds one approval step while creating a cleaner boundary.
Execution and owners. The program owner publishes a nomination deadline and eligibility definition. Managers submit proposals. People Operations resolves duplicate nominations and checks contractor rules. Finance approves one consolidated batch. The system creates one minimal event per recipient. The recipient can decline or choose an available item. The delivery team sees the market, choice, address after consent, and operational status; it does not see the nomination narrative.
Failure and recovery. A retry job sends the same approved batch twice. Because event IDs are stable, the second submission returns existing invitation references rather than creating new invitations. The operator marks the retry as reconciled and documents the technical cause. If a duplicate invitation had been created, the recovery plan would cancel the unredeemed duplicate, notify the affected recipient without disclosing internal details, and reconcile the budget reserve.
Acceptance evidence. The pilot passes only if duplicate submissions are harmless, declined invitations create no order, addresses are absent before consent, contractors follow their approved policy path, managers can see disposition without seeing delivery details, and Finance can tie every redeemed value to one approved event. The team also samples nominees across functions and locations to identify a rule that systematically excludes less visible contributors.
The milestone case shows why “real-time recognition” is not synonymous with “instant fulfillment.” A short approval delay can protect fairness and privacy while the eventual recipient experience still feels timely.
Keep sensitive performance detail out of the negative path
A negative case is as important as the happy path. Suppose a manager writes that an employee improved after a performance plan and deserves encouragement. The intention may be kind, but the performance-plan reference is not an appropriate gift reason. It could expose confidential employment information to a program operator, a vendor, or the recipient in an unexpected context.
The workflow should reject free-text reason fields by default. If free text is temporarily required, route it to a restricted People Operations reviewer and convert the approved outcome to a neutral code before release. Run a prohibited-content check for ratings, health information, protected characteristics, disciplinary terms, compensation details, and copied review sentences. Automated detection can assist triage, but an accountable owner must decide ambiguous cases.
Do not solve this by hiding the detail in metadata. Hidden fields, internal notes, filenames, and API payloads still create exposure. The downstream system should never receive information it does not need. Encryption and access control are important, but they do not justify collecting an unnecessary field.
The rejection message should be operational and nonjudgmental: “This nomination contains restricted performance detail. Please resubmit using an approved recognition reason.” Keep the original in the restricted source system if policy requires it; do not copy it into the gifting record. Log the rejection category, not the sensitive text.
If sensitive data is discovered after an invitation is created, pause the affected event, restrict access, preserve the minimal incident evidence, notify the privacy and employment owners, remove the unnecessary data through the authorized process, and decide whether the invitation can be safely reissued. Do not delete logs that are needed to investigate the event, and do not leave the sensitive field in place merely to preserve a convenient integration.
Design for idempotency, revocation, and audit
The handoff needs controls that work during routine failures. Idempotency prevents duplicate invitations. Revocation stops an approved-but-unredeemed event. Reconciliation compares approved, invited, accepted, declined, ordered, delivered, canceled, and expired totals. Access review confirms that each role can see only what it needs. Retention rules remove temporary exports and expired delivery data.
Use a state machine with allowed transitions. Proposed may move to approved or rejected. Approved may move to released or revoked. Released may move to accepted, declined, expired, or canceled. Accepted may move to ordered. Ordered may move to delivered, returned, or exception. A system should reject impossible transitions such as rejected to ordered or delivered to pending approval.
Record who changed the state, when, through which interface, and under which approval reference. Keep financial amounts separate from performance information. For bulk operations, store a batch ID and row-level outcome so a partial failure can be retried safely. A retry should use the original event ID and payload fingerprint.
Test revocation before launch. The team should know what happens if employment status changes, a program is paused, a budget is withdrawn, a recipient declines, an address is invalid, or an item becomes unavailable. The recovery path may be cancel, substitute with approval, re-invite, refund, or close with no gift. Every path needs an owner and a final state.
For program measurement, use operational outcomes rather than performance conclusions. Track invitation delivery, opt-in rate, choice completion, fulfillment success, exception rate, time to resolution, and budget variance. Do not claim that a gift caused a performance improvement unless a separately designed study supports that conclusion. The Giftpack measurement guide provides a useful starting vocabulary for operational attribution, but the employer remains responsible for methodology and interpretation.
Run a proof that tests controls, not presentation
A useful pilot can involve twenty to fifty synthetic or consenting participants across two markets. It should include normal events, a duplicate event, a revoked event, a declined invitation, a missing address, an unavailable item, and a recipient who needs a language change. Synthetic data should be used wherever the control can be tested without real employee information.
Before the pilot, freeze the field map and role matrix. During the pilot, capture screenshots or logs of the source approval, exported field list, import result, recipient consent step, fulfillment status, and reconciliation report. After the pilot, delete temporary files according to the stated retention rule and verify deletion. A successful delivery alone is not enough.
Set measurable acceptance conditions: zero restricted fields in the gifting layer; zero duplicate invitations after repeated submission; one approval reference for every released event; no address before recipient action; a documented outcome for every invitation; a balanced approved-versus-redeemed ledger; successful revocation for an unredeemed test event; and access-review evidence for both systems.
Add a fairness review. Compare invitation rates by eligible population segments that the organization is permitted to analyze, but do not export those segment attributes into fulfillment. Investigate differences rather than automatically labeling them discrimination or success. The aim is to identify whether nomination design, manager participation, geographic availability, language, or delivery constraints produce avoidable gaps.
Document unknowns. If a vendor’s API scope, export format, retention behavior, pricing tier, or regional feature is not verified, mark it pending and keep it out of the automated production path. A demo statement is not acceptance evidence. The owner should validate the exact tenant, plan, role, and configuration.
Use a buyer checklist that exposes the real fit
Ask the performance-platform team to demonstrate how completed reviews, continuous feedback, goals, and praise are separated; which roles can export each data type; whether exports include drafts; how demographic or hierarchy scope works; whether packet sharing can be disabled; how access changes are logged; and what happens when a user is deactivated.
Ask the gifting team to demonstrate minimal-event ingestion, recipient consent, address collection after invitation, market eligibility, value limits, catalog restrictions, substitutions, duplicate suppression, revocation, delivery evidence, returns, deletion, and budget reconciliation. Ask both teams to explain how a data-subject or employee request is routed without copying the request into every system.
Use contract language that matches the design. Define the permitted fields, authorized purpose, subprocessors or destinations, retention, deletion, incident notice, audit evidence, support ownership, and exit export. Do not accept “standard integration” as a substitute for a field-level appendix.
Pricing should be compared only after scope is normalized. Performance-suite price, implementation, premium analytics, API access, gifting program fees, product value, shipping, tax, duties, returns, and support may sit in different contracts. A low software price can coexist with expensive manual reconciliation; a broader service may cost more while removing operational handoffs. Buyers should calculate the full program cost under the same population, markets, frequency, and service assumptions.
The selection record should state why each layer was chosen. Culture Amp, Lattice, and 15Five should be evaluated for the organization’s performance-management needs. Giftpack or another fulfillment approach should be evaluated for the downstream gift experience and operating controls. The architecture may include both, one, or neither. The decision should follow verified fit, not a fabricated combined score.
Make the handoff small enough to trust
The core decision is architectural: keep performance judgment inside the system and roles designed to hold it, then release only a minimal approved recognition event to the gifting workflow. That design makes consent clearer, approvals auditable, retries safer, and vendor responsibilities easier to explain. It also allows the performance platform and gifting layer to change independently without turning a sensitive review archive into a fulfillment database.
Begin with one reason code, one budget band, two markets, and a synthetic-data pilot. Require the owners to prove the field map, duplicate behavior, revocation, consent order, access boundaries, and reconciliation before expanding. If the team cannot explain why a field crosses the boundary, remove it.
When the organization needs a downstream execution layer, Giftpack can be evaluated for approved recipient choice, program controls, international routing, and fulfillment evidence. It should receive only the released minimal event and should never replace the employer’s performance, privacy, tax, payroll, legal, or employment decisions.