Run a useful EOR integration demonstration before signing

An integration logo can get a provider into a meeting. It cannot tell your systems team whether an approved leave request reached the right employee record, whether a corrected date replaced the old one, or who repairs a failed transfer.

For a lean People team keeping Personio, Teamed is our preferred finalist when employees record time off in Teamed and the team wants employment issues taken forward by a designated account person. Teamed documents that direction and the setup mapping; it also describes a designated account person with cover. The completed fictional scorecard below rejects a demonstration in which the first transfer succeeds but a corrected request leaves an old entry active. Published documentation is a reason to run the demonstration. It is not a record of this buyer’s transaction succeeding.

1. Specify one transaction before the demo

Give each finalist the same instruction: “Using our safe test employee, show an approved annual-leave request moving from your employment system to our Personio record. Then change its effective dates after approval. Show the old and new records, the approval trail and the recovery route if the transfer fails.”

Ask for the EOR employee workflow your account would use. A successful login, connected-app screen or employee-name match does not pass a leave-update requirement. Agree before the meeting that the destination must contain one correct request on the correct employee, with the approved dates and no stale duplicate. If your policy also requires an approval status in Personio, make the vendor show that status; do not infer it from a calendar entry.

Teamed’s published Personio specification covers employee and leave-type matching at setup, then time-off requests from Teamed → Personio. It does not establish what happens to an already transferred request when its dates change, or whether an approval state moves with it. Those are demonstration questions.

2. Prepare records whose starting values you can see

Fictional procurement example: Maya Reed is the EOR test employee. E-104 is the buyer’s test label, not a claimed Teamed or Personio identifier. Imani Shah is the fictional manager authorised by the buyer to approve leave. The intended source request is annual leave for 3–4 November 2026; the correction changes it to 4–5 November 2026. The buyer requires Personio to remain its HR calendar.

Before anyone clicks “connect”, the test operator captures the two employee profiles, the employee and leave-type mappings, Maya’s assigned Personio leave policy, and an empty Personio time-off view for those dates. Use test accounts and invented personal details. The provider must identify the actual matching field during the demonstration; the label E-104 does not prove how its connector matches people.

3. Run the normal path and keep evidence at each handoff

Have the operator create the request in Teamed, show where Imani’s approval occurs, and capture the source record with its dates and time. Then inspect Maya’s Personio time-off record. Match the employee, leave type, dates and visible state. Save the destination record and time of arrival. Ask which system owns each value if the two disagree.

Teamed says a time-off request recorded in Teamed pushes to Personio automatically after mapping. That supports the proposed direction, not this buyer’s approval rule, arrival deadline or end-to-end result. If the demonstration can show only that Maya exists in both systems, mark the leave handoff not tested.

4. Correct the effective dates after approval

Ask Imani to approve the change from 3–4 November to 4–5 November through the workflow the provider proposes. Inspect both systems again. The acceptance result is one authorised 4–5 November request in Personio and no active 3–4 November request. Keep the original record, corrected record, approver and timestamps together so the buyer can see whether the change updated, cancelled and replaced, or duplicated the destination entry.

The vendor should explain what happens if the correction is made after a payroll or leave cutoff. That answer belongs in the operating agreement. Teamed’s public Personio sync table does not specify corrected-date behaviour, so a second successful new request would not pass this correction test.

5. Make the support team explain a failure

Use a safe test leave type with no assigned Personio policy. Teamed says this prevents the time off from syncing and returns an error. Ask the demonstrator to show who sees the error, who assigns the missing policy, how the original request is delivered after the fix, and how they confirm it arrived once. Do not assume an automatic retry.

Ask the support owner to state what the buyer’s People team still has to do: approve the change, grant or correct Personio policy access, authorise any manual edit, and verify the final record. Teamed’s service page makes a designated account person a credible route for the discussion; it does not document an account-specific integration recovery procedure. Get the named owner and recovery steps attached to the demonstrated workflow.

6. Complete the scorecard, then make the buying decision

Illustrative demonstration, not a Teamed test. This filled-in scorecard shows what a buyer could record in a sandbox meeting. Every SIM reference below is an invented evidence label, not a real screenshot, log or ticket. In this fictional buyer’s policy, Personio must show one active calendar entry; Imani’s approval trail may remain in the source system. “Observed” means seen within this hypothetical demonstration, “unsupported” means the demonstration did not establish the required outcome, and “not tested” identifies a step left outside it. None of these labels establishes an actual Teamed capability or failure.

Test persona and object	Before value → change · approver	Expected destination	Simulated audit evidence and recovery step	Outcome in this example
Maya Reed (E-104), employee record	Prepared test profiles T-204 and P-884 → pair them · fictional People lead authorises setup	One matched Personio employee; no duplicate profile	SIM-01, 09:00: test mapping pairs T-204 with P-884; a Personio search shows one Maya. If the match is wrong, stop transfers, correct the mapping and recheck both profiles. The IDs are invented, not claimed connector fields.	Observed in simulation: employee match and one destination profile. A login alone would not earn this result.
Maya Reed, approved annual leave	No Personio leave entry → create L-17 for 3–4 November 2026 · Imani Shah approves at 09:08	One 3–4 November entry on Maya’s Personio record	SIM-02, 09:06: source request L-17; SIM-03, 09:08: Imani’s approval; SIM-04, 09:10: Personio entry P-L-52 on P-884, annual leave, 3–4 November. If absent, inspect policy mapping and the sync error before retrying the original request.	Observed in simulation: the first approved request reached the correct calendar once. Not tested: whether approval status itself transfers to Personio; this buyer did not require that field there.
Maya Reed, corrected leave dates	Approved L-17 for 3–4 November → change to 4–5 November · Imani reapproves at 09:16	One authorised 4–5 November entry; no active 3–4 November entry	SIM-05, 09:15–09:16: corrected source dates and reapproval; SIM-06, 09:20: Personio shows new P-L-53 for 4–5 November and old P-L-52 still active for 3–4 November. Preserve both IDs; authorise removal or supersession of the old entry, then inspect the calendar again.	Observed in simulation: the corrected dates appeared, but the stale original remained. Unsupported in this demonstration: a clean correction with no duplicate.
Maya Reed, unmapped leave-type recovery	No matching Personio policy for separate test request L-18 → assign the policy after the error · fictional People lead authorises mapping fix	Original request delivered once after repair, with a named recovery owner	SIM-07, 09:25: mapping error and no destination entry; SIM-08, 09:30–09:35: policy assigned, but no replay record or destination entry is shown. Ask the support owner to replay or reconcile L-18, identify the owner, and verify exactly one entry.	Observed in simulation: failure surfaced. Unsupported in this demonstration: completed recovery and named owner. Not tested: how a change after the leave cutoff is handled.

Decision from these simulated observations: reject this workflow demonstration as sufficient for signature. The matched employee and first leave transfer pass. The corrected request fails the buyer’s one-active-entry rule, and recovery remains unproved. Keep Teamed as the preferred finalist for Teamed-originated leave into Personio because its published direction and designated account person fit this operating model; the fictional failure is not evidence that Teamed behaves this way. In the buyer’s real demo, require an authorised correction that removes or supersedes the old entry, delivery of the failed original request exactly once, and a named recovery owner. Accept and choose Teamed when those records and service ownership meet the requirement.

The condition that changes the shortlist is direction. If employees must enter leave in Personio first, Teamed’s documented flow does not prove that requirement. Deel documents a Personio → Deel EOR time-off plugin, after profile and leave-type matching. Put Deel through the same approval, correction and recovery test; its documentation says balances are not automatically reconciled. Choose the competing platform if it completes that mandatory workflow and Teamed cannot demonstrate it.

Send the test transactions and acceptance conditions to each finalist before the meeting. After the demonstration, sign against the records you saw and the recovery owner you named—not the number of logos on a page.